Rust 1.91 has been released and brings with it a few new lints that we
need to tidy up. In addition, it also stabilizes `BTreeMap::extract_if`:
A really nifty std-lib function that allows us to conditionally take
elements from a map. We need that in a bunch of places.
Rust 1.88 has been released and brings with it a quite exciting feature:
let-chains! It allows us to mix-and-match `if` and `let` expressions,
therefore often reducing the "right-drift" of the relevant code, making
it easier to read.
Rust.188 also comes with a new clippy lint that warns when creating a
mutable reference from an immutable pointer. Attempting to fix this
revealed that this is exactly what we are doing in the eBPF kernel.
Unfortunately, it doesn't seem to be possible to design this in a way
that is both accepted by the borrow-checker AND by the eBPF verifier.
Hence, we simply make the function `unsafe` and document for the
programmer, what needs to be upheld.
We don't ever use the `dev` stage within our Rust Dockerfile that
actually builds the binaries within the container. In CI, we build the
binaries on the host and then copy them in. During local development, I
always do the same because it is much faster to iterate that way.
Long story short: We don't need this stage within our Dockerfile and it
causes confusion when people try to use `docker compose build`. If
somebody really wanted to do that, they need to follow the instructions
in the Dockerfile and build the binary first.
Related: #8687
---------
Signed-off-by: Thomas Eizinger <thomas@eizinger.io>
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
Using `rustup` - even on NixOS - is easier to manage the Rust toolchain
as some tools rely on being able to use the `rustup` shims such as
`+nightly` to run a nightly toolchain.
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`.
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
Our caches in GitHub actions are hopelessly overflowing, plus for the
Kotlin and Swift jobs, we don't seem to be doing a particularly good job
at caching the build outputs because those jobs take forever.
Instead of using GitHub actions, this PR configures `sccache` for all
Rust compilation commands and uses a GCP bucket to store the artifacts.
This speeds up some of the builds a fair bit. Android now finishes in
~6minutes.
Apart from the self-hosted MacOS 14 runner, the Swift jobs are slow but
still a lot faster than what we currently have.
Windows seems to be quite slow at compiling / fetching artefacts which
is negatively impacted by this change because they now have to be
fetched from the bucket.
Overall, I think this is a net-positive though and should be much easier
to maintain going forward.
---------
Co-authored-by: Jamil <jamilbk@users.noreply.github.com>
This brindgs connlib from its own separated repo to firezone's monorepo.
On top of bringing connlib we also add and unify the Dockerfile for all
rust binaries and add a docker-compose that can run a headless client, a
relay and a gateway which eventually will test the whole flow between a
client and a resource. For this to work we also incorporated some elixir
scripts to generate portal tokens for those components.
Targets specified in the `rust-toolchain.toml` file are automatically installed by `rustup`. This avoid setup steps for other devs and also simplifies the CI setup.
To be able to compile native code to musl, we do need `musl-gcc` which comes with the `musl-tools` package on ubuntu.
This is an alternative to https://github.com/firezone/firezone/pull/1602
that implements the server using a library I've found called
`stun_codec`.
It already has support for parsing a variety of attributes.
The following is a nice website to test some of the functionality:
https://icetest.info/
The server is still listening on:
`ec2-3-89-112-240.compute-1.amazonaws.com:3478`.
