Bumps the tauri group in /rust with 1 update:
[tauri](https://github.com/tauri-apps/tauri).
Updates `tauri` from 2.2.3 to 2.2.5
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/tauri-apps/tauri/releases">tauri's
releases</a>.</em></p>
<blockquote>
<h2>tauri-cli v2.2.5</h2>
<!-- raw HTML omitted -->
<pre><code>Updating git repository
`https://github.com/tauri-apps/schemars.git`
Updating crates.io index
Locking 1053 packages to latest compatible versions
Adding apple-codesign v0.27.0 (available: v0.29.0)
Adding axum v0.7.9 (available: v0.8.1)
Adding colored v2.2.0 (available: v3.0.0)
Adding dirs v5.0.1 (available: v6.0.0)
Adding html5ever v0.26.0 (available: v0.29.0)
Adding itertools v0.13.0 (available: v0.14.0)
Adding minisign v0.7.3 (available: v0.7.9)
Adding oxc_allocator v0.36.0 (available: v0.47.0)
Adding oxc_ast v0.36.0 (available: v0.47.0)
Adding oxc_parser v0.36.0 (available: v0.47.0)
Adding oxc_span v0.36.0 (available: v0.47.0)
Adding proc-macro-crate v2.0.0 (available: v2.0.2)
Adding serialize-to-javascript v0.1.1 (available: v0.1.2)
Adding serialize-to-javascript-impl v0.1.1 (available: v0.1.2)
Adding tauri-utils v1.6.0 (available: v1.6.2)
Adding tiny_http v0.11.0 (available: v0.12.0)
Adding webview2-com v0.34.0 (available: v0.35.0)
Adding windows v0.58.0 (available: v0.59.0)
Adding x509-certificate v0.23.1 (available: v0.24.0)
Fetching advisory database from
`https://github.com/RustSec/advisory-db.git`
Loaded 724 security advisories (from /home/runner/.cargo/advisory-db)
Updating crates.io index
Scanning Cargo.lock for vulnerabilities (1078 crate dependencies)
Crate: atk
Version: 0.18.2
Warning: unmaintained
Title: gtk-rs GTK3 bindings - no longer maintained
Date: 2024-03-04
ID: RUSTSEC-2024-0413
URL: https://rustsec.org/advisories/RUSTSEC-2024-0413
Dependency tree:
atk 0.18.2
└── gtk 0.18.2
├── wry 0.48.1
│ └── tauri-runtime-wry 2.3.0
│ └── tauri 2.2.3
│ ├── tauri-plugin-sample 0.1.0
│ │ └── api 0.1.0
│ ├── tauri-plugin-log 2.2.0
│ │ └── api 0.1.0
│ ├── tauri-file-associations-demo 0.1.0
│ ├── tauri 2.2.3
</tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="5a3647bdfe"><code>5a3647b</code></a>
Apply Version Updates From Current Changes (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12515">#12515</a>)</li>
<li><a
href="477e9c0496"><code>477e9c0</code></a>
fix(core): Use safe_block_on in mobile proxy (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12514">#12514</a>)</li>
<li><a
href="82d634f4a9"><code>82d634f</code></a>
Apply Version Updates From Current Changes (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12512">#12512</a>)</li>
<li><a
href="8e9134c4a2"><code>8e9134c</code></a>
fix(cli): Apply --bins flag on build instead of dev (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12511">#12511</a>)</li>
<li><a
href="dc1997b77d"><code>dc1997b</code></a>
apply version updates (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12439">#12439</a>)</li>
<li><a
href="1a86974aa3"><code>1a86974</code></a>
fix(cli): let xcode handle building for <code>ios build --open</code>
(<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12406">#12406</a>)</li>
<li><a
href="fb294af8e3"><code>fb294af</code></a>
fix(tauri-driver): Parse ms:edgeOptions separately (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12383">#12383</a>)</li>
<li><a
href="46c7b16111"><code>46c7b16</code></a>
ci(renovate): Disable oxc_ PRs</li>
<li><a
href="9dac2863af"><code>9dac286</code></a>
fix(bundler): Don't self-sign dmg (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12323">#12323</a>)</li>
<li><a
href="9a9d1205b0"><code>9a9d120</code></a>
chore(deps): update dependency rollup to v4.32.0 (dev) (<a
href="https://redirect.github.com/tauri-apps/tauri/issues/12502">#12502</a>)</li>
<li>Additional commits viewable in <a
href="https://github.com/tauri-apps/tauri/compare/tauri-v2.2.3...tauri-v2.2.5">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 <dependency name> major version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's major version (unless you unignore this specific
dependency's major version or upgrade to it yourself)
- `@dependabot ignore <dependency name> minor version` will close this
group update PR and stop Dependabot creating any more for the specific
dependency's minor version (unless you unignore this specific
dependency's minor version or upgrade to it yourself)
- `@dependabot ignore <dependency name>` will close this group update PR
and stop Dependabot creating any more for the specific dependency
(unless you unignore this specific dependency or upgrade to it yourself)
- `@dependabot unignore <dependency name>` will remove all of the ignore
conditions of the specified dependency
- `@dependabot unignore <dependency name> <ignore condition>` will
remove the ignore condition of the specified dependency and ignore
conditions
</details>
---------
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
#7808 introduced a minor bug that prevented the rust Docker images from
building locally, in `debug` builds. Adding `openssl-dev` to the
builder's container fixes the issue.
```
cargo:warning=Could not find directory of OpenSSL installation, and this `-sys` crate cannot proceed without this knowledge. If OpenSSL is installed and this crate had trouble finding it, you can set the `OPENSSL_DIR` environment variable for the compilation process. See stderr section below for further information.
```
Rust 1.83 comes with a bunch of new lints for elidible lifetimes. Those
also trigger in the generated code of `derivative`. That crate is
actually unmaintained so we replace our usages of it with `derive_more`.
When `snownet` was first being developed, these tests ensured that
hole-punching as well as connectivity via a relayed works correctly. We
have since added extensive tests that ensure connectivity works in many
scenarios via `tunnel_test`. `tunnel_test` does not (yet) have a
simulated NAT so hole-punching itself is not covered by that.
UDP hole-punching is shockingly trivial though because all you need to
do is send UDP packets to the same socket that the other party is
sending from. This isn't done by our own code but rather by str0m's
implement of ICE (as long as we add the correct candidates).
The `snownet-tests` themselves are quite fragile because they need to
set up their own event loop and manually construct an IP packet. They
haven't caught a single bug to my knowledge so I am proposing to delete
them for ease of maintenance.
For example, in
https://github.com/firezone/firezone/actions/runs/10449965474/job/28948590058?pr=6335
the tests fail because we no longer directly force a handshake when the
connection is established. This is unnecessary now because the buffered
intent packet will directly force a handshake from the client to the
gateway. Yet, `snownet-tests` event loop would need adjusting to also do
that.
Without masquerading, packets sent by the gateway through the TUN
interface use the wrong source address (the TUN device's address)
instead of the gateway's actual network interface.
We set this env variable in all our uses of the gateway, thus we might
as well remove it and always perform unconditionally.
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Reactor Scram <ReactorScram@users.noreply.github.com>
Considered using Elixir and Rust to write the tests.
For Elixir, `wallaby` doesn't seem to have a way to attach to an
existing `chromium` instance, launching it each time, which makes it
hard to coordinate with the relay restart.
For Rust we considered `thirtyfour` which would be very nice since we
could test both firefox and chrome but each time it connects to the
instance it launches a new session making it hard to test the DNS cache
behavior.
We also considered `chrome_headless` for Rust it needs a small patch to
prevent it from closing the browser after `Drop` but it still presents a
problem, since it has no easy way to retrieve if loading a page has
succeeded. There are some workarounds such as retrieving the title that
we could have used but after some testing they are quite finnicky and we
don't want that for CI.
So I ended up settling for TypeScript but I'm open to other options, or
a fix for the previous ones!
There are some modifications still incoming for this PR, around the test
name and that sleep in the middle of the test doesn't look good so I
will probably add some retries, but the gist is here, will keep it in
draft until we expect it to be passing.
So feel free to do some initial reviews.
Note: the number of lines changed is greatly exaggerated by
`package.lock`
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil Bou Kheir <jamilbk@users.noreply.github.com>
Co-authored-by: Thomas Eizinger <thomas@eizinger.io>
As part of #4568, we are adding a 2nd relay which showed some
short-comings of the current process state assertions because they were
running outside the docker containers, thus listing all relays as soon
as there are multiple.
These customizations were from before we used `cargo cross` for all
architectures in CI.
1.77.1 has been tested to work with the following clients:
- [x] Apple
- [x] Android
- [x] Windows
- 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
I don't know much about `cargo chef` so I gave this its own PR in case
I'm doing something that'll subtly break it
I've run into this problem on some branches and not others, where it's
trying to build all the Tauri / glib stuff even though the Docker image
won't need it:
https://github.com/firezone/firezone/actions/runs/8012206575/job/21887478015#step:7:1175
This splits off the easy parts from #3605.
- Add quotes around `PHOENIX_SECURE_COOKIES` because my local
`docker-compose` considers unquoted 'false' to be a schema error - Env
vars are strings or numbers, not bools, it says
- Create `test.httpbin.docker.local` container in a new subnet so it can
be used as a DNS resource without the existing CIDR resource picking it
up
- Add resources and policies to `seeds.exs` per #3342
- Fix warning about `CONNLIB_LOG_UPLOAD_INTERVAL_SECS` not being set
- Add `resolv-conf` dep and unit tests to `firezone-tunnel` and
`firezone-linux-client`
- Impl `on_disconnect` in the Linux client with `tracing::error!`
- Add comments
```[tasklist]
- [x] (failed) Confirm that the client container actually does stop faster this way
- [x] Wait for tests to pass
- [x] Mark as ready for review
```
Currently, `firezone-connection` can only handle connections on a LAN.
Via the use of a STUN server, we can discover our public IP and attempt
to direct, hole-punched connection across multiple subnets.
Turns out #3276 was only part of the problem. After that was fixed, the
issue did turn out to be the statically-linked libc runtime. Staging was
using dynamic linking and so didn't hit the issue.
This reverts back to musl which has been tested as @AndrewDryga noted.
When moving from debian to alpine we stopped installing `curl` and it's
needed to get the public ipv4 and ipv6 of the relay in the
`docker-init.sh`
Signed-off-by: Gabi <gabrielalejandro7@gmail.com>
- rebuild and publish gateway and relay binaries to currently drafted
release
- re-tag current relay/gateway images and push to ghcr.io
Stacked on #2341 to prevent conflicts
Fixes#2223Fixes#2205Fixes#2202Fixes#2239
~~Still TODO: `arm64` images and binaries...~~ Edit: added via
`cross-rs`
Copying the `rust-toolchain.toml` file in is one thing but if we want to
avoid repeatedly installing it, we should do that in the same layer too.
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
This patch-set aims to make several improvements to our CI caching:
1. Use of registry as build cache: Pushes a separate image to our docker
registry at GCP that contains the cache layers. This happens for every
PR & main. As a result, we can restore from **both** which should make
repeated runs of CI on an individual PR faster and give us a good
baseline cache for new PRs from `main`. See
https://docs.docker.com/build/ci/github-actions/cache/#registry-cache
for details. As a nice side-effect, this allows us to use the 10 GB we
have on GitHub actions for other jobs.
2. We make better use of `restore-keys` by also attempting to restore
the cache if the fingerprint of our lockfiles doesn't match. This is
useful for CI runs that upgrade dependencies. Those will restore a cache
that is still useful although doesn't quite match. That is better[^1]
than not hitting the cache at all.
3. There were two tiny bugs in our Swift and Android builds:
a. We used `rustup show` in the wrong directory and thus did not
actually install the toolchain properly.
b. We used `shared-key` instead of `key` for the
https://github.com/Swatinem/rust-cache action and thus did not
differentiate between jobs properly.
5. Our Dockerfile for Rust had a bug where it did not copy in the
`rust-toolchain.toml` file in the `chef` layer and thus also did not use
the correctly toolchain.
6. We remove the dedicated gradle cache because the build action already
comes with a cache configuration:
https://github.com/firezone/firezone/actions/runs/6416847209/job/17421412150#step:10:25
[^1]: Over time, this may mean that our caches grow a bit. In an ideal
world, we automatically remove files from the caches that haven't been
used in a while. The cache action we use for Rust does that
automatically:
https://github.com/Swatinem/rust-cache?tab=readme-ov-file#cache-details.
As a workaround, we can just purge all caches every now and then.
---------
Signed-off-by: Jamil <jamilbk@users.noreply.github.com>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
