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.y
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>
Otherwise we get weird failures like these:
```
clang-11: error: cannot use 'cpp-output' output with multiple -arch options
clang-11: error: invalid argument '-mmacos-version-min=10.12' not allowed with '-miphoneos-version-min=8.0'
clang-11: error: invalid argument '-mmacos-version-min=10.12' not allowed with '-miphoneos-version-min=8.0'
```
Depends on: https://github.com/status-im/status-jenkins-lib/pull/47
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This way the name of the repo makes at least some sense and
matches the `status-desktop` repo naming.
Also updated `status-jenkins-lib` since it also contained
references to `status-react` repo and job names.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This has several benefits:
* Less abuse of `extra-sandbox-paths` Nix option
* Less inputs to the Android release build derivation
* Easier for users to sign the build themselves
* Simplification of `scripts/release-android.sh`
* Preparation for building using Nix Flakes
The only two remaining credentials passed via `extra-sandbox-paths` is
the Infura and OpenSea API keys, and there is no way around that other
than passing them via Nix arguments, but that would cause them to end up
in `/nix/store` as part of `.drv` files.
I'm also renaming `release-fdroid` to `build-fdroid` to be consistent.
Depends on: https://github.com/status-im/status-jenkins-lib/pull/42
Signed-off-by: Jakub Sokołowski <jakub@status.im>
By using just the timestamp we increase the probability of hitting a
race condition with another build due to same filename of sandbox file.
Depends on: https://github.com/status-im/status-jenkins-lib/pull/40
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This is required to also ad GitHub releases to `status-desktop`.
Also renamed `status-react-jenkins` to `status-jenkins-lib` for clarity.
Depends on: https://github.com/status-im/status-react-jenkins/pull/23
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This changes the behavior of mobile combined builds to not publish
the results of `nightly` or `release` builds unless `PUBLISH`
parameter is set to `true`.
It also makes the `BUILD_TYPE` into a dropdown choice field with
pre-defined values, like `manual` or `e2e`.
Changes:
- Add parameter definitions for `BUILD_TYPE` and `PUBLISH`
- Move uploading of `latest.json` to `Publish` stage
- Make `Publish` stage optional based on the `PUBLISH` parameter
Requires: https://github.com/status-im/status-react-jenkins/pull/21
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
Using different temporary keychains does not work if we do not set
`default_keychain=true`, because `codesign` then can't find the cert:
```
error: No signing certificate "iOS Distribution" found: No "iOS Distribution" signing certificate matching team ID
```
But if we set `default_keychain=true` then we cause a race condition
when the keychain is deleted by a parallel job while another is using it
as its default.
For this reason we have to use a static keychain name and keep it
between builds.
I tried disabling `default_keychain=true` in #11378 but it worked only
because the default user keychain already had the cert.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>
This is a new approach to signing the iOS app by using a temporary
Keychain created only for that specific build and unlocked in advance.
By doing it this way we can avoid issues with `errSecInternalComponent`
appearing when there is no UI to open a Keychain password prompt when
running build in CI. I've described this problem in details in:
https://github.com/fastlane/fastlane/issues/15185
Thanks to `codesign:` partition ID being added to key partition list by
Fastlane `match` when importing a Keychain this approach now works:
https://github.com/fastlane/fastlane/pull/17456
Signed-off-by: Jakub Sokołowski <jakub@status.im>
The env variable `INFURA_TOKEN` is used at build time of JS bundle, not
the final APK file. We never passed the `secretsFile` to the
derivation for JS bundle so it never saw the `INFURA_TOKEN`.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
* `status-im-releases` for release builds
* `status-im-nightlies` for nightlies
I want to reserve the `status-im` bucket for use with the site.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
This updates a bunch of things in the Jenkins logic.
For details of that see:
https://github.com/status-im/status-react-jenkins/pull/12
It grew out of the changes I made to make PR builds available in Desktop client:
https://github.com/status-im/nim-status-client/pull/507
Changes:
- Bump `status-react-jenkins` library to newer version, probably `1.2.0`
- Update use of `utils.pkgFilename()` in `ci/Jenkinsfile.combined`
- Make all iOS builds go into the same folder: `status-ios`
- Drop e2e build type, infer it from Android ABIs set to `x86` only
- Simplify logic in `nix/mobile/android/release.nix.`
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Build PR Scheme in PR build
use named parameters, use pr_build boolean
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Enable capabilities
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Add custom app icon
Remove user defined profile
Add PR scheme
Explicit provide provisioning profiles
Fix pr schema
Bump jenkins
Pod bump
Describe pr_build argument
Signed-off-by: Gheorghe Pinzaru <feross95@gmail.com>
This way we can use different token for e2e, release, and devel builds.
Signed-off-by: Jakub Sokołowski <jakub@status.im>
Signed-off-by: Andrea Maria Piana <andrea.maria.piana@gmail.com>