Right now, draft releases for Gateways and headless-clients are created
on each merge to main. For all other components, we only create those
when we trigger the workflow for a specific commit.
To align this functionality, we split the `_build_artifacts.yml`
workflow into two:
- `_control-plane.yml`
- `_data-plane.yml`
Apart from the `sha` input, all inputs only concern the data-plane,
therefore massively simplifying the control-plane workflow.
Additionally, the control-plane also doesn't have a manual trigger
because its artifacts never get released on GitHub.
Resolves: #10541
Ubuntu 22.04 is over 3 years old and therefore ships with quite an old
kernel. Our production VMs (for relays) all run Ubuntu 24.04 so it makes
sense to build and test them on the same kernel / OS release. For
consistency reasons, we therefore bump all runners to 24.04.
To avoid burning Azure credits, we move the runners back down to the
free tier. Now that caching is properly set up, this should incur only a
minor increase in CI time.
Now that our infra-as-code is moved into another repo, we need a
mechanism to trigger the staging deploy. We can use
`repository_dispatch` for that, which allows us to trigger the staging
workflow by sending an HTTP API request that matches the configuration
of the `repository_dispatch` workflow trigger on that repo.
Related: https://github.com/firezone/infra/pull/36
This moves our current GCP infra to a new firezone/environments repo.
The existing Git history is preserved, and CI config is updated to clone
this submodule before running any terraform jobs.
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.
Bumps
[hashicorp/tfc-workflows-github](https://github.com/hashicorp/tfc-workflows-github)
from 1.3.1 to 1.3.2.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/hashicorp/tfc-workflows-github/releases">hashicorp/tfc-workflows-github's
releases</a>.</em></p>
<blockquote>
<h2>v1.3.2</h2>
<ul>
<li>Bug fixes and enhancements from <a
href="https://github.com/hashicorp/tfc-workflows-tooling/releases/tag/v1.3.2">tfc-workflows-tooling@v1.3.2</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/hashicorp/tfc-workflows-github/blob/main/CHANGELOG.md">hashicorp/tfc-workflows-github's
changelog</a>.</em></p>
<blockquote>
<h1>v1.3.2</h1>
<ul>
<li>Bug fixes and enhancements from <a
href="https://github.com/hashicorp/tfc-workflows-tooling/releases/tag/v1.3.2">tfc-workflows-tooling@v1.3.2</a></li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="8e08d1ba95"><code>8e08d1b</code></a>
Prepare v1.3.2 release (<a
href="https://redirect.github.com/hashicorp/tfc-workflows-github/issues/2981">#2981</a>)</li>
<li><a
href="2a0a556cba"><code>2a0a556</code></a>
[COMPLIANCE] Update MPL-2.0 LICENSE (<a
href="https://redirect.github.com/hashicorp/tfc-workflows-github/issues/2980">#2980</a>)</li>
<li><a
href="b15578fa52"><code>b15578f</code></a>
Merge pull request <a
href="https://redirect.github.com/hashicorp/tfc-workflows-github/issues/2976">#2976</a>
from salilsub/main</li>
<li><a
href="030a2307e5"><code>030a230</code></a>
Adding GITHUB_TOKEN link to README</li>
<li><a
href="833d60e689"><code>833d60e</code></a>
Adding information about setting the GITHUB_TOKEN permissions</li>
<li>See full diff in <a
href="https://github.com/hashicorp/tfc-workflows-github/compare/v1.3.1...v1.3.2">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
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>
This will always build images we can use for last-minute compatibility
tests, even if the merge group was bypassed.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
- Removes version numbers from infra components (elixir/relay)
- Removes version bumping from Rust workspace members that don't get
published
- Splits release publishing into `gateway-`, `headless-client-`, and
`gui-client-`
- Removes auto-deploying new infrastructure when a release is published.
Use the Deploy Production workflow instead.
Fixes#4397
Fixes some issues encountered after the merge of #4049
- Fix performance tests to only run using base_ref and head_ref to avoid
dependence on `main`
- Fixes some typos
- Prevents a catch-22 condition where breaking compatibility meant we
wouldn't be able to deploy production
- 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
Refs #3230
It looks like we need to sign the internal exe before it gets bundled
too. We can use `beforeBundleCommand` to do so.
Soon, Tauri should have native support for this exact scenario:
https://github.com/tauri-apps/tauri/pull/8718
Builds off #3905 and uses the GH actions cache for tauri builds in order
to get around the `crate-type` problem sccache has with Tauri apps.
Fixes#3456
Fixes various small issues, including some of the issues in #3768:
- Clicking "About" or "Settings" no longer toggles a window between
visible and hidden, it always shows and un-minimizes the window. So if
it's minimized, it won't vanish, it will appear
- Log message for vt100 failure is clearer
- The "cancel sign-in" race was coincidentally already working as
intended, but the code and comments are clarified.
- Fix the asset name used to check for auto-updates (this cannot be
end-to-end tested until we cut a new release of the clients on Github,
not just a draft release)
- Fix README to include Ubuntu instructions
This may cause conflicts with all my other PRs but it has to happen.
```[tasklist]
- [ ] Update test names in branch protection (I don't think I have perms for this)
```
The MSI is needed to install WebView2, otherwise the exe will crash, per
#3451 .
We don't have any manual way to install WebView2, and the MSI also makes
sure the exe goes into Program Files as it should, so I don't think
users will need the bare exe.
It'll still be produced in CI runs for devs / superusers to look at if
they really need.
