This task publishes artifacts needed by consumers to use the nightly,
including:
- maven.json: where were the maven packages published?
- swift-components.zip: generated swift files + xcframework
- nimbus-fml.zip / nimbus-fml.sha256: nimbus-fml binary
Currently, nightly builds use a different maven group id
(org.mozilla.appservices.nightly) to separate them from "real" builds,
although this may change based on feedback from the Android team
Don't try to publish maven packages using the nightly repos. The
Android team prefers them in the regular repos.
Small fix to make exceptions print out correctly for NimbusGradlePlugin.
I was seeing a lot of download errors when testing this.
Building swift-components.zip required building on a mac worker, which
required some extra work/hacking
- Added a `run-commands` job implementation that works on
`generic-worker`.
- The ios tests are not working yet, so I just commented them out.
- For now the entire build happens in one task. Eventually we should
split it up, maybe into toolchain task and a separate build/test
task for Fenix/Focus.
- Updated several of our scripts to use env vars rather than
hardcoding things based on the docker-worker.
Updates protobuf to version 3.21.2 and the gradle plugin to version 0.8.18.
Upstream protobuf also has native M1 Mac support now, so remove a hack which
isn't needed anymore.
Co-authored-by: Tarik Eshaq <teshaq@mozilla.com>
Added code that copies data from `local.properties` to the gradle
instance, like android-components does.
If `branchBuild.application-services.version` is set in
`local.properties`, then we set the app-services version to that exact
string.
Updated `substitute-local-appservices.gradle` to also support that
property (in this case it's set in the `android-components` directory).
The plan is to use this feature to build/test fenix using a particular
checkout of application-services, with the version set to the git commit
ID.
This uses the new, cleaner factoring of our Android config from #4194
as an excuse to update some of our Android dependencies to bring them
inline with what's used in current android-components. It was much
easier than it has been in the past!
Prior to this commit, the `build.gradle` for each individual
project contained copy-pasted logic for configuring Android
and protobuf. Some of them were even using slightly different
versions of the same dependencies.
With this commit, there are two new gradle scripts that encapsulate
this shared logic:
* ./build-scripts/component-common.gradle, for basic Android
and Kotlin setup.
* ./build-scripts/protobuf-common.gradle, for configuration specific
to the protobuf plugin.
Hopefully this will make the logic easier to maintain going forward.
Directly executing `cargo` from inside of an XCode build doesn't
seem to work quite right, e.g. on Big Sur it isn't able to properly
build any `build.rs` due to problems with library paths in the linker
This copies the same technique that we already use for running `cargo`
to build a universal binary, but as a re-useable cargo wrapper rather
than a specific command.
Our docs currently recommend two ways of building consuming apps against
local changes to this repo: an automated-but-perpetually-buggy composite build
workflow, and a reliable-but-tedious manual workflow of publishing to a local
maven repo.
This commit removes them both and replaces them with something similar to
the workflow used by android-components: some scripting to automate publishing
to and consuming from a local maven repo.
James Hugman
Mark Hammond
Ben Dean-Kawamura
Ryan VanderMeulen
Ryan VanderMeulen
Sammy Khamis
Jan-Erik Rediger
Ryan Kelly
Ryan Kelly
Thom Chiovoloni
Edouard Oger
Thom Chiovoloni