Otherwise it fails with:
```
performing a single-user installation of Nix...
directory /nix does not exist; creating it by running 'mkdir -m 0755 /nix && chown jenkins /nix' using sudo
sudo: a terminal is required to read the password; either use the -S option to read from standard input or configure an askpass helper
/tmp/nix-binary-tarball-unpack.roliyEDk9X/unpack/nix-2.19.3-x86_64-linux/install: please manually run 'mkdir -m 0755 /nix && chown jenkins /nix' as root to create /nix
```
Related to:
https://github.com/status-im/status-go/pull/4388
Signed-off-by: Alexis Pentori <alexis@status.im>
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Had to be changed to `PLATFORM` due to conflict of `TARGET` with our Nix
shell setup in `status-mobile` and `status-go`.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
If we don't we regularly get weird Git failures on Windows like:
```
fatal: Unable to find current revision in submodule path 'vendor/qzxing/tests/resources'
fatal: Failed to recurse into submodule path 'vendor/qzxing'
```
Or
```
stderr: fatal: Unable to create '.../.git/index.lock': File exists.
```
Which are very annoying and require manual workspace purge by infra team.
Many of you will get annoyed with resulting slower checkouts
on subsequent builds, but that's a price I'm willing to pay.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This way it actually reflects the purpose accurately and allows us to
build without debug symbols in CI without pulling in release credentials.
https://github.com/status-im/status-desktop/issues/13079
The only utility for `RELEASE` parameter is inheriting it
from the parent meta-job(`ci/Jenkinsfile.combined`).
Signed-off-by: Jakub Sokołowski <jakub@status.im>
- Necessary env variables to build the app:
STATUS_BUILD_INFURA_TOKEN
STATUS_BUILD_INFURA_TOKEN_SECRET
STATUS_BUILD_POKT_TOKEN
STATUS_BUILD_OPENSEA_API_KEY
STATUS_BUILD_ALCHEMY_ETHEREUM_MAINNET_TOKEN
STATUS_BUILD_ALCHEMY_ETHEREUM_GOERLI_TOKEN
STATUS_BUILD_ALCHEMY_ARBITRUM_MAINNET_TOKEN
STATUS_BUILD_ALCHEMY_ARBITRUM_GOERLI_TOKEN
STATUS_BUILD_ALCHEMY_OPTIMISM_MAINNET_TOKEN
STATUS_BUILD_ALCHEMY_OPTIMISM_GOERLI_TOKEN
- The list of available env variables as well as CL arguments can be seen running
the app providing `--help` argument. All env vars are prefixed with `STATUS_RUNTIME_`.
It will default to `true` for Linux builds except release ones.
This setting can always be overriden manually for any build.
Resolves:
https://github.com/status-im/status-desktop/issues/12412
Signed-off-by: Jakub Sokołowski <jakub@status.im>
The symlinks are temporary to avoid issues in PRs that won't be rebased
right away. We can remove them later.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Possible fix for slow upload speeds and failures caused by most probably
hitting per-bucket rate limits of DigitalOcean:
>- 500 total operations per second to any individual bucket.
>- 300 combined PUT, POST, COPY, DELETE, and LIST operations per second
> to any individual Space. We may further limit LIST operations if
> necessary under periods of high load.
https://docs.digitalocean.com/products/spaces/details/limits/#rate-limits
Depends on: https://github.com/status-im/status-jenkins-lib/pull/52
Signed-off-by: Jakub Sokołowski <jakub@status.im>
It needs to be separate script, because once the submodules are broken
and the `variables.mk` file is not available from `nimbus-build-system`
then we cannot even call `make clean-git` successfully because it will
be caught by the `if` clause that checks for `variables.mk`.
Possible fix for issues with submodules not being updated in some
windows release builds.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This was added to fix some build issues to Linux:
https://github.com/status-im/status-desktop/pull/8233
But other 2 platforms also have had the cleanup stage change which could
have cause these submodules update issues.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This is a continuation of attempts to fix provlems with Windows CI hosts
getting into a broken state due to `.git` directory becoming a file for
random submodules for unknown reason.
Instead of relying on Jenkins functionality of `cleanWs()` function
provided by the [Workspace Cleanup Plugin](https://plugins.jenkins.io/ws-cleanup)
we use Git which should be more reliable, and possibly also speed up the
initial checkout of the repo and submodules.
A nice side-effect is that the repo checkout on all builds after the first
one takes ~1 minute instead of ~5 minutes.
Previous issues:
- https://github.com/status-im/status-desktop/pull/7968
- https://github.com/status-im/status-desktop/pull/8046
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This is a continuation of a fix done in:
https://github.com/status-im/status-desktop/pull/7968
This adds `deleteDirs` option to delete the whole workspace:
>When deferred wipeout is disabled, the old implementation of
>filesystem content deletion is used. If you want the same
>behavior as with deferred wipeout, you have to set the plugin
>attribute `deleteDirs` to true as well.
https://github.com/jenkinsci/ws-cleanup-plugin#deferred-wipeout
Because otherwise the `vendor` folder remains and causes
issues when `.git` is a file.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
A potential partial fix found for an issue found in:
https://github.com/status-im/status-desktop/pull/7789
Where an incomplete broken checkout of a `vendor` module which crated a
`.git` file instead of a directory in `vendor/nimPNG` caused the error:
```
$ git submodule update --init --recursive vendor/nimPNG
fatal: Needed a single revision
Unable to find current revision in submodule path '../nimPNG'
```
Which then was not correctly cleaned up and in turn caused error:
```
org.jenkinsci.plugins.workflow.steps.MissingContextVariableException: Required context class hudson.FilePath is missing
Perhaps you forgot to surround the code with a step that provides this, such as: node, dockerNode
...
```
The last known successful CI build for that PR showed in logs:
```
00:05:13 [WS-CLEANUP] Deleting project workspace...
00:05:13 [WS-CLEANUP] Deferred wipeout is used...
00:05:13 [WS-CLEANUP] done
```
Which means the `Workspace Cleanup` plugin uses the `Resource Disposer`
plugin to wipe the workspaace in the background, which could potentially fail:
https://plugins.jenkins.io/ws-cleanup/#plugin-content-deferred-wipeout
Signed-off-by: Jakub Sokołowski <jakub@status.im>
By using `s3cmd` through PowerShell instead of Git Bash we improve
upload speeds on Windows slightly, as described here:
https://github.com/status-im/infra-ci/issues/40
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Upgrade of Jenkins to `2.343` has introduced a security fix that breaks
caching plugin when it's configured to store cache on Master host:
https://issues.jenkins.io/browse/JENKINS-67173
Sine the [Caching plugin](https://plugins.jenkins.io/jobcacher/) hasn't
been upgraded in 5 years the only good temporary workaround is just drop
caching of dependencies like Nim compiler entirely.
In the future we can try some other caching methods.
Related: https://github.com/status-im/nimbus-eth2/pull/3594
Signed-off-by: Jakub Sokołowski <jakub@status.im>
It appears this was some leftover from ancient times and wasn't being used.
On the other hand the `RELEASE` environment variable controls if Nim builds
of the client binary include debug symbols:
ba7a6d5d34/Makefile (L177-L184)
The shorthand `?:` symbol means that if this is changed for a given job it stays changed.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Siddarth Kumar
Jakub Sokołowski
Anton Iakimov
Dario Gabriel Lipicar
Sale Djenic
Jonathan Rainville
Anthony Laibe
Alex Jbanca
Andrei Smirnov