Recently, we changed that we only upload binaries to the draft releases
when we actively call the workflow. This means that we may potentially
have a drift between:
- The commit that gets tagged as the release.
- The commit from which the binaries got built.
To ensure that this doesn't drift, we only update the draft releases
whenever we actually uploaded new binaries to them. In addition, we
instruct `release-drafter` to set the target of the release to the
commit SHA from when it was triggered. As a result, it is much less
error prone that these may drift apart. I believe the only race
condition here could be if somebody publishes a release between the time
the binaries get uploaded and we update the release draft, i.e. when
GitHub hasn't fully finished CI yet.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Similar to the Apple and Android clients, this PR updates the Linux and
Windows GUI clients to upload to the GitHub drafted release on manual
workflow triggers only.
This should save a few minutes off `main` builds as the extra package
testing steps will now be skipped there.
Notably, the Gateway and Headless Client workflows are unchanged because
(a) they are much faster to build / test and (b) we use the release
builds for performance testing connlib, so we need them to run on
`main`.
To improve supply-chain security, reference all GitHub actions using the
hash of the released tag. GitHub recommends to do this for third-party
actions
(https://docs.github.com/en/actions/security-for-github-actions/security-guides/security-hardening-for-github-actions#using-third-party-actions).
In order to make our CI more deterministic, I opted to do it for all our
actions. This means any change to our workflow configuration requires a
source code change and thus passing CI on our end.
Dependabot will automatically issue PRs for these actions and update the
comment with the new version next to them.
Resolves: #2497.
`sentry-cli debug-files upload` offers no option to exclude certain
files or directories when recursively searching the given path. Thus, we
need to remove this staging directory to prevent it from recursively
walking the directory and inevitably erroring out when it hits a path it
doesn't have access to.
Unfortunately Apple's API doesn't expect to be hit this frequently and
also doesn't respond with obvious errors when we ask too much of it.
Because of this, we move the App Store connect upload back to manual
trigger only, and update the standalone upload to GitHub releases to the
same because it needs to hit Apple's notary service API.
- Attaching the standalone client needs to happen on `main` runs, like
the other clients
- GitHub can't seem to find the release. I suspect the
`GITHUB_REPOSITORY` var is unneeded.
The CI swift workflow needs to be updated to accommodate the macOS
standalone build. This required a decent amount of refactoring to make
the Apple build process more maintainable.
Unfortunately this PR ended up being a giant ball of yarn where pulling
on one thread tended to unravel things elsewhere, since building the
Apple artifacts involve multiple interconnected systems. Combined with
the slow iteration of running in CI, I wasn't able to split this PR into
easier to digest commits, so I've annotated the PR as much as I can to
explain what's changed.
The good news is that Apple release artifacts can now be easily built
from a developer's machine with simply
`scripts/build/macos-standalone.sh`. The only thing needed is the proper
provisioning profiles and signing certs installed.
Since this PR is so big already, I'll save the swift/apple/README.md
updates for another PR.
Standalone distribution requires using a different signing identity
(certificate), set of provisioning profiles, and (annoyingly) requires
the `-systemextension` suffix for our network extension capabilities.
This PR prepares the Xcode environment for building a Standalone app in
CI that will be notarized by matching certificates and provisioning
profiles in our Apple Developer account.
This ensure that we run prettier across all supported filetypes to check
for any formatting / style inconsistencies. Previously, it was only run
for files in the website/ directory using a deprecated pre-commit
plugin.
The benefit to keeping this in our pre-commit config is that devs can
optionally run these checks locally with `pre-commit run --config
.github/pre-commit-config.yaml`.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
In the Rust code, we use `git describe` to determine the current version
of the code. This only works if tags are actually checked out. To save
time, the `actions/checkout` action by default only does a shallow-clone
of depth 1 without any tags. Due to that, all events in Sentry just show
up as a commit hash.
Closes#5481
With this, I can connect to the staging portal without a build.rs or any
extra env var setup
<img width="387" alt="image"
src="https://github.com/firezone/firezone/assets/13400041/9c080b36-3a76-49c7-b706-20723697edc7">
```[tasklist]
### Next steps
- [x] Split out a refactor PR for `ConnectArgs` (#5488)
- [x] Try doing this for other Clients
- [x] Check Gateway
- [x] Check Tauri Client
- [x] Change to `app_version`
- [x] Open for review
- [ ] Use `option_env` so that `FIREZONE_PACKAGE_VERSION` can still override the Cargo.toml version for local testing
- [ ] Check Android Client
- [ ] Check Apple Client
```
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
- Runs release asset builds simultaneously with `deploy-staging`. Those
don't depend on each other.
- Prevents running some build workflows in CD because they're run
already in the PR and in the merge group, and the risk of semantic
conflict is negligible
- Run `release` assets in staging
- Adds `compatibility_tests`: **To successfully introduce a breaking
change in the control / data plane APIs, you must now "Merge as
Administrator"**
- Since `CI` is no longer run on `main`, caching needed to be refactored
to make sense again
- Since `CI` is no longer run on `main`, the Elixir
`migrations_and_seeds_test` had to be rewritten. This now tests
migrations using `git checkout` instead of importing `main`'s DB dump.
- Move tauri builds to its own workflow so we can trigger Linux and
Windows builds manually on an adhoc basis like we do for the Swift and
Kotlin builds
- Add a new `hotfix` workflow that will run `compatibility_tests` with
the latest published images
- Add `workflow_dispatch` to trigger `CD` manually for testing purposes
(cc @ReactorScram)
Refs #3995
This should be faster than the Intel runners. Seems to be at least twice
as fast for uncached builds compared to `ubuntu-22.04`.
- [x] ~~Move elixir checks to `macos-14`~~ can't; Depends on `docker`
and `erlef/setup-beam`
- [x] Add macOS targets to rust checks
- [x] Move swift build to macos-14
- [x] Move kotlin build to macos-14
- [x] Name all jobs that are required for merge group to not depend on
job config
- [x] Update PR branch protection rules
We're uploading dupe builds of the client on macOS and iOS because we're
testing the build on Xcode 14 and 15.
Since Xcode 15 is stable now, builds for 14 can be removed.
Unfortunately the label-based method of distributing app builds was
flawed because it was trigger on `push: main` which doesn't include the
PR label metadata in the event.
Instead, we can (and probably should) distribute new app builds to
testers whenever the patch version changes. This PR aims to do that.
What this means:
- We'll want to bump the patch version to distribute new app builds to
Test Flight and Play Console. I think this is ok, because once the build
goes to Test Flight or Play Console for distribution, it should be
potentially publishable. This is the assumption both Google and Apple
make throughout their publishing workflow (and why we got temporarily
banned by AppStore Connect).
- Day to day development and testing requires building locally, which I
think is OK since it's relatively easy to do so.
## Changelog
- Updates connlib parameter API_URL (formerly known under different
names as `CONTROL_PLANE_URL`, `PORTAL_URL`, `PORTAL_WS_URL`, and
friends) to be configured as an "advanced" or "hidden" feature at
runtime so that we can test production builds on both staging and
production.
- Makes `AUTH_BASE_URL` configurable at runtime too
- Moves `CONNLIB_LOG_FILTER_STRING` to be configured like this as well
and simplifies its naming
- Fixes a timing attack bug on Android when comparing the `csrf` token
- Adds proper account ID validation to Android to prevent invalid URL
parameter strings from being saved and used
- Cleans up a number of UI / view issues on Android regarding typos,
consistency, etc
- Hides vars from from the `relay` CLI we may not want to expose just
yet
- `get_device_id()` is flawed for connlib components -- SMBios is rarely
available. Data plane components now require a `FIREZONE_ID` now instead
to use for upserting.
Fixes#2482Fixes#2471
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Gabi <gabrielalejandro7@gmail.com>
