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>
In #7795, we optimised our CI pipeline to only test the installation of
the GUI client whenever we actually upload to the draft release. This
trigger has been moved to `workflow_dispatch`, meaning no CI builds
neither from PRs nor `main` perform these steps.
This makes it difficult to test GUI client binaries from PRs because
they also no longer get uploaded to the artifacts of the CI run on the
PR.
To fix this, we split the testing away from the rename script and
unconditionally run the rename script, which allows us to also always
upload the binaries to the CI artifacts.
Finally, uploading to the draft releases is only done when we explicitly
trigger the workflow from `main`. This is a defense-in-depth measure: We
should never publish a code to a release that hasn't been merged to
`main`.
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.
In order to release the new control protocol to users, we need to bump
the versions of the clients to 1.4.0. The portal has a version gate to
only select gateways with version >= 1.4.0 for clients >= 1.4.0. Thus,
bumping these versions can only happen once testing has completed and
the gateway has actually been released as 1.4.0.
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
In order to display better stacktraces when Firezone crashes, Sentry
needs debug symbols for our binaries. Debug symbols on Sentry are
retained for 90 days after they have been last used [0]. We can thus
simply upload them every time we build a binary on `main`.
For the moment, this only uploads them for the GUI client. Debug symbols
for the Android and Apple clients will be done in separate PRs.
[0]:
https://docs.sentry.io/platforms/native/data-management/debug-files/#retention-policy
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Refs #6145
This bundles aarch64 and x86_64 RPMs in CI and CD.
We'll need a 2nd PR to add everything to the changelog and knowledge
base, after the first release with RPMs is cut.
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#4883
Refs #7005
Adds support for Ubuntu 24.04, drops support for Ubuntu 20.04
Known issues:
- On Ubuntu 22.04, sometimes GNOME shows the wrong tray icon
- On Ubuntu 24.04, the first time you open the tray menu, GNOME takes a
long time to open the menu.
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
`SENTRY_ENVIRONMENT` is only read at run time, not at build time, and we
override the environment in our code anyway, so this env var was doing
nothing.
Closes#6854
- Sets release version from the GUI Client / Headless Client version
instead of the `firezone-telemetry` version
- Set environment to "production" and "staging" for well-known API URLs,
and "self-hosted" for others, since environments in Sentry can't have
slashes in them
- Sets API URL as a tag
- Sets release to `unit test` for unit testing `firezone-telemetry`
itself, since it has no good version number
<img width="398" alt="image"
src="https://github.com/user-attachments/assets/86f71193-2511-45c1-8304-413db8e5ef90">
This happens because the smoke test is stubbed out for release builds,
so any `use` statements that are only used in the smoke tests will cause
a warning in `--release` builds, including when we make release bundles.
This publishes the 1.3.0 clients and gateways so that Internet Resources
will work.
The feature is still disabled for the Stripe plans until we publish the
launch post. Select customers have the feature enabled.
Closes#2667
- No known issues from the knowledge base were fixed
- I confirmed on the Windows laptop that the fix for #6469 is in this
MSI.
- The changelog looks good in the Vercel preview
---------
Signed-off-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Currently, `connlib` can only handle "simple" DNS wildcards where `*`
matches any number of subdomains, including zero and `?` matches a
single subdomain.
With this PR, we expand `connlib'`s capabilities to allow for a much
more complex matching of domains that more closely resembles glob
patterns:
- `**` matches any number of subdomains. This supersedes the previous
`*` operator.
- `*` matches a single subdomain. This supersedes the previous `?`
operator.
- `?` matches a single character. This wasn't possible before.
- Additionally, any of these can be combined. Previously, only `*` or
`?` was allowed and they were only accepted at the front of the domain
name pattern.
Resolves: #5056.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
I started a playbook for publishing GUI releases, I didn't see any other
one around.
I think there's a middle step I'm not clear on:
1. Open this PR and get it approved
2. Do something? Publish the draft release maybe? Run a special CI
workflow?
3. Merge this PR to update the changelog and bump the versions in Git
```[tasklist]
### Tasks
```
This would make it a little easier to replicate prod issues on old
releases
```[tasklist]
### Tasks
- [x] Add comment to changelog
- [x] Check Vercel preview
- [x] Request review
- [x] Update arches link
- [x] `apt-get update`
- [x] Re-request review
```
