The `expires_at` column on the `flows` table was never used outside of
the context in which the flow was created in the Client Channel. This
ephemeral state, which is created in the `Domain.Flows.authorize_flow/4`
function, is never read from the DB in any meaningful capacity, so it
can be safely removed.
The `expire_flows_for` family of functions now simply reads the needed
fields from the flows table in order to broadcast `{:expire_flow,
flow_id, client_id, resource_id}` directly to the subscribed entities.
This PR is step 1 in removing the reliance on `Flows` to manage
ephemeral access state. In a subsequent PR we will actually change the
structure of what state is kept in the channel PIDs such that reliance
on this Flows table will no longer be necessary.
Additionally, in a few places, we were referencing a Flows.Show view
that was never available in production, so this dead code has been
removed.
Lastly, the `flows` table subscription and associated hook processing
has been completely removed as it is no longer needed. We've implemented
in #9667 logic to remove publications from removed table subscriptions,
so we can expect to get a couple ingest warnings when we deploy this as
the `Hooks.Flows` processor no longer exists, and the WAL data may have
lingering flows records in the queue. These can be safely ignored.
[`actionlint`](https://github.com/rhysd/actionlint) is a static analysis
tool for GitHub workflows and actions. It detects various issues ahead
of time and runs shellcheck on all `run` blocks. It is worth noting that
this does **not** lint the contents of composite actions so we still
need to be vigilant when working with those.
This has been disabled for several releases now and is not causing any
problems in production. We can therefore safely remove it.
It is about time we do this because our tests are actually still testing
the variant without the feature flag and therefore deviate from what we
do in production. We therefore have to convert the tests as well. Doing
so uncovered a minor problem in our ICMP error parsing code: We
attempted to parse the payload of an ICMP error as a fully-valid layer 4
header (e.g. TCP header or UDP header). However, per the RFC a node only
needs to embed the first 8 bytes of the original packet in an ICMPv4
error. That is not enough to parse a valid TCP header as those are at
least 20 bytes.
I don't expect this to be a huge problem in production right now though.
We only use this code to parse ICMP errors arriving on the Gateway and I
_think_ most devices actually include more than 8 bytes. This only
surfaced because we are very strict with only embedding exactly 8 bytes
when we generate an ICMP error.
Additionally, we change our ICMP errors to be sent from the resource IP
rather than the Gateway's TUN device. Given that we perform NAT on these
IPs anyway, I think this can still be argued to be RFC conform. The
_proxy_ IP which we are trying to contact can be reached but it cannot
be routed further. Therefore the destination is unreachable, yet the
source of this error is the proxy IP itself. I think this is actually
more correct than sending the packets from the Gateway's TUN device
because the TUN device itself is not a routing hop per-se: its IP won't
ever show up in the routing path.
This wasn't the issue - the issue was that @firezone-bot needed access
to the firezone/winget-pkgs repo.
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
To make releases even more smoother, this PR creates a bit of automation
that automatically bumps the versions in the `scripts/bump-versions.sh`
script and opens a PR for it.
When working on the Swift codebase, I noticed that running the formatter
produced a massive diff. This PR re-formats the Swift code with `swift
format . --recursive --in-place` and adds a CI check to enforce it going
forward.
Resolves: #9534
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
- Adds a timeout to the required_checks workflow
- Expects all jobs to run, exiting the script early for main branch runs
- Adds `set -xe` so we catch script errors going forward
This CI run is running for over an hour, not sure which job it's waiting
on:
https://github.com/firezone/firezone/actions/runs/15565464294
When a CI job is running as part of a merge group, it's possible the
base ref is a few commits away if the merge queue has items in it. So we
update the fetch depth to 20.
We don't need to rebuild the Tauri clients every time we change Rust
code but we almost certainly want to rebuild them if we change any code
in the client itself so we can smoke test them.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
When evaluating the status of all required checks, we currently only look at the very first one. This is error prone and may result in `required-check` to be marked as successful too early. Instead of iterating through the list of jobs we have scheduled, we now instead look at all jobs that are running as part of the CI run. The idea here is:
- Any job that got started need to complete (one way or another)
- If _any_ job fails, we fail the required check
- If all jobs complete without a single failure, we pass the check
This plays well with "skipped" jobs which we sometimes have as part of CI.
This PR optimises our CI pipeline to only run workflows when certain
files change. To achieve this, we introduce a top-level `planner` job
that all other jobs primarily depend on. The `planner` job then computes
which other jobs to run and creates an output with a list of those.
Running only certain jobs is only the first half of the problem. The
second half is creating a dedicated job that we can mark as "required"
in GitHub. Without such a "required" check, the merge queue wouldn't
know, when a PR is good to be merged.
Jobs cannot have dynamic dependencies on other jobs. We therefore need
to emulate this by creating a polling loop that hits the GitHub API
every 10s and evaluates, whether all "required" jobs, i.e. the ones we
planned to run, have finished successfully.
---------
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Bumps
[taiki-e/install-action](https://github.com/taiki-e/install-action) from
2.52.4 to 2.52.6.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/releases">taiki-e/install-action's
releases</a>.</em></p>
<blockquote>
<h2>2.52.6</h2>
<ul>
<li>
<p>Update <code>cargo-udeps@latest</code> to 0.1.56.</p>
</li>
<li>
<p>Update <code>git-cliff@latest</code> to 2.9.1.</p>
</li>
</ul>
<h2>2.52.5</h2>
<ul>
<li>
<p>Update <code>typos@latest</code> to 1.33.1.</p>
</li>
<li>
<p>Update <code>git-cliff@latest</code> to 2.9.0.</p>
</li>
<li>
<p>Update <code>cargo-shear@latest</code> to 1.3.1.</p>
</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/taiki-e/install-action/blob/main/CHANGELOG.md">taiki-e/install-action's
changelog</a>.</em></p>
<blockquote>
<h1>Changelog</h1>
<p>All notable changes to this project will be documented in this
file.</p>
<p>This project adheres to <a href="https://semver.org">Semantic
Versioning</a>.</p>
<!-- raw HTML omitted -->
<h2>[Unreleased]</h2>
<h2>[2.52.6] - 2025-06-04</h2>
<ul>
<li>
<p>Update <code>cargo-udeps@latest</code> to 0.1.56.</p>
</li>
<li>
<p>Update <code>git-cliff@latest</code> to 2.9.1.</p>
</li>
</ul>
<h2>[2.52.5] - 2025-06-03</h2>
<ul>
<li>
<p>Update <code>typos@latest</code> to 1.33.1.</p>
</li>
<li>
<p>Update <code>git-cliff@latest</code> to 2.9.0.</p>
</li>
<li>
<p>Update <code>cargo-shear@latest</code> to 1.3.1.</p>
</li>
</ul>
<h2>[2.52.4] - 2025-05-31</h2>
<ul>
<li>
<p>Update <code>cargo-binstall@latest</code> to 1.12.6.</p>
</li>
<li>
<p>Update <code>wash@latest</code> to 0.42.0.</p>
</li>
</ul>
<h2>[2.52.3] - 2025-05-30</h2>
<ul>
<li>
<p>Update <code>cargo-nextest@latest</code> to 0.9.97.</p>
</li>
<li>
<p>Update <code>trivy@latest</code> to 0.63.0.</p>
</li>
<li>
<p>Update <code>protoc@latest</code> to 3.31.1.</p>
</li>
</ul>
<h2>[2.52.2] - 2025-05-27</h2>
<ul>
<li>Update <code>mdbook@latest</code> to 0.4.51.</li>
</ul>
<h2>[2.52.1] - 2025-05-25</h2>
<ul>
<li>
<p>Update <code>taplo@latest</code> to 0.10.0.</p>
</li>
<li>
<p>Update <code>mdbook@latest</code> to 0.4.50.</p>
</li>
</ul>
<!-- raw HTML omitted -->
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="1cefd1553b"><code>1cefd15</code></a>
Release 2.52.6</li>
<li><a
href="6741c847f5"><code>6741c84</code></a>
Update <code>cargo-udeps@latest</code> to 0.1.56</li>
<li><a
href="821228b8ca"><code>821228b</code></a>
Update <code>git-cliff@latest</code> to 2.9.1</li>
<li><a
href="7bf3bbf310"><code>7bf3bbf</code></a>
Release 2.52.5</li>
<li><a
href="fcb7f36651"><code>fcb7f36</code></a>
Update <code>typos@latest</code> to 1.33.1</li>
<li><a
href="84dd63d16a"><code>84dd63d</code></a>
Update <code>git-cliff@latest</code> to 2.9.0</li>
<li><a
href="4871b28862"><code>4871b28</code></a>
Update <code>cargo-shear@latest</code> to 1.3.1</li>
<li>See full diff in <a
href="735e593394...1cefd1553b">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>
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
