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>
QA needs easier access to public URLs from DigitalOcean spaces, and when
this meta-job fails the URLs are buried within child jobs and hard to access.
This not only sets the description if build fails, it sets it after
every single child build finishes.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
The method of triggering new E2E builds from the Linux build makes sense
for PRs, but doesn't make as much sense for nightly or release builds.
By triggering it this way we will see the result as part of the whole
build that includes all platforms and all tests.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Since getProjectName() is not available for all types returned from
utils.parentOrCurrentBuild(), which can result in a crash.
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_`.
Runs all tests from Storybook directory via ctest:
- tests for Storybook itself
- UI unit tests using the same stubs mechanism as Storybook pages
- PagesValidator checking if SB pages are compilable
Closes: #12213Closes: #12437
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>
Because the environment variable name is far too generic and barely
means anything. It needs to clearly indicate that it's supposed to be
used at runtime and it changes how the Status app behaves.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
After a LOT of work from @jrainville bisecting the release branch he
identified the issue to be this commit:
https://github.com/status-im/status-desktop/commit/dad8e453
ci: bump client build retries to 20
Which actually was poorly squashed by @iurimatias and contains the
commit that also adds the retries in the first place:
https://github.com/status-im/status-desktop/commit/a5ba2537
ci: retry nim_status_client build 3 times
The reason why that's an issue is because normally it was caled by `make
tgz-linux` target which included this setting:
```
override RESOURCES_LAYOUT := $(PRODUCTION_PARAMETERS)
```
Which caused `NIM_PARAMS` to use `-d:development` instead of `-d:production`.
The result was the app trying to write config file changes to the read-only
filesystem of the AppImage.
Resolves: https://github.com/status-im/status-desktop/issues/11295
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Ubuntu 18.04 LTS support has ended on the 31st of May 2023. It's about
time we upgraded to 20.04, which uses Glibc `2.31` instead of `2.27`.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This is a temporary stop-gap fix for a known linux build issue:
https://github.com/status-im/infra-ci/issues/88
Since currently this issue is very hard to reproduce and there is no
good solution in sight this should minimize the pain caused by it.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This way we prevent situation in which a developer or QA engineer runs a
custom job with adjusted parameters, and then all following jobs use
those modified parameters implicitly. The more sane behavior is to
always revert to defaults for PR builds, but remember last used
parameters for non-PR builds.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Useful for tracking down which commit introduced a breaking change.
I'm lowering `maxConcurrentTotal` limit for e2e parallel build since the
release builds on `ci.infra.status.im` do not share the same throttling
limits across Jenkins instances, so we can hit a licenses usage limit.
Also increasing number of builds to keep to 30.
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>
We're using a base ubuntu:18.04 Docker image and install Qt5.15.2 on top using aqt installer and linuxdeplyqt.
Upgrade of ubuntu_build_setup.sh is left to a separate PR due to Squish being tied to old Qt.
Fixes#9210
Adds the `TEST_ENVIRONMENT` that stops banners from showing and touch id to be activated (needs to be tested by someone on Mac).
Also improves the waiting time on verifying screens. Will undo that change if it becomes flaky.
To make sure your local tests still work well and hide the banner as well, make sure to put `TEST_ENVIRONMENT=1` in the suite settings' env vars
Otherwise we get failures when notarizing the app:
```json
{
"message": "Unable to upload your app for notarization.",
"userInfo": {
"NSLocalizedDescription": "Unable to upload your app for notarization.",
"NSLocalizedFailureReason": "--team-id DTX7Z4U3YA is not valid for the user name specified. Use --list-providers."
},
"code": -1027
}
```
Related: https://github.com/status-im/status-mobile/pull/14411
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Please do not run 20 different things in a single stage.
It makes debugging much harder than it needs to be, since now you can
see at a glance the startup of which container fails easily.
Changes:
- Starting of Ganache and Nim-Waku containers extracted to separate stages
- Cleanup of containers moved to `cleanup` step after tests are executed
- Many variables moved to `enrivonment` section for job and some stages
- The `throttle` effect narrowed down just to the `Tests` stage and not whole job
- RPC API is used to get the Multiaddress of Nim-Waku node instead of hardcoding key
- Removed no longer necessary `status-go` history node related files
- `Jenkinsfile.uitests` was renamed to `Jenkinsfile.e2e` to match CI job names
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>