This is just asking for failure since we try to pin the trybuild output
to the newer rust version.
Updated `tests.py` to handle this and switched to using that in the
CircleCI config. Ironically, it looks like we switched away from
`tests.py` because it was running too many tests in a previous Rust
upgrade. Hopefully the new system is easy enough to tune the next time
this bites us.
I use pyenv to manage Python versions locally, so the `python3`
executable in my `PATH` is a shim that's different from the system
`python3`. This change ensures that running the Taskcluster scripts
locally uses the `python3` shims in my `PATH`.
This is needed in order to add application-services to Shipit, which
expects a `version.txt` file at the repository root. Rather than have
this duplicated both here and `.buildconfig-android.yml`, this patch
refactors automation to use `version.txt` instead.
Bug: 1842897
Updated/added scripts to handle releases.
Renamed `cut-an-new-release.md` to `releases.md` and updated the
contents.
Removed CHANGES_UNRELEASED. The new release system is simple enough
that we can just write entries directly to the changelog.
sync-test was removed from the workspace some time ago, which meant it
was never built or checked, so it went quite stale, particularly with
respect to logins changes.
We not keep it in the workspace but as an "excluded" item, which means
you can run it from its directory. To prevent it going stale again, CI
runs clippy on it.
Also needed a few misc tweaks to some other crates.
Currently on iOS, Nimbus and Glean are always compiled together as
part of the same Swift module in the iOS megazord. This means that
Nimbus can see and use many of Glean's internal helper functions,
which in fact it does.
When we switch to distributing via Swift packages, we'll need to
be more careful about inter-module hygiene. I think ideally the
Nimbus Swift code would consume Glean as an ordinary Swift dependency
via `import Glean`.
To make that work while also preserving the current behaviour for
current consumers, I have:
* Added a conditional import of Glean, which gets ignored in the
existing megazord but makes Glean available in a Swift package build.
* Copied the internal helper modules that we were using from Glean
into the `nimbus/ios` directory, so that this directory can be
compiled as a standalone Swift module using only public Glean
APIs.
Importantly, I have *not* included the copied utility files in the
iOS megazord Xcode project. That build already uses the ones from
Glean and would error out if we included duplicates.
All in all, this doesn't seem like a sustainable setup, but perhaps
it can be the first step towards something cleaner. Maybe we could
make a shared utility module that both Glean and Nimbus can depend
on? Maybe Glean could commit to making these utilities part of its
public API surface?
Suggestions welcome! What I know is that this helps unblock the work
on publishing as a Swift package in the meantime. Fixes#4308.
- Removed the ErrorHandling enum, we decided to always return failure
- Removed the DatabaseLocation enum, we can use ":memory:" to open
memory DB.
- Removed the START_VERSION. This was redundant because the upgrade
functions are going to list which versions they support in the match
statement.
- In the autofill::schema code, make the schema functions top-level and
put them after the MigrationLogic code.
Couple other cleanups:
- Updated tests.py to not run the megazord tests if just the dependency
files change.
- Replaced Jira link with Github
Don't call strip() on the command output, it altered the git status
output and made the script think that `rust fmt` didn't make any changes
when it did.