Our assumption was that we need armv7 for running on an RPi. It turns out that Armv7 is totally outdated and only used on the old RPi 2 model B. The newer model RPi 2 model B v1.2 already uses Armv8
This allows opting-in for longer-running tests by enabling "expensive_tests"
feature, instead of waiting for a few minutes after starting `cargo test`.
Amend the CI to run all the tests (including expensive ones) on every run.
The new task does a few things:
1. Having an extra build target makes the workflow file cleaner
2. it downloads the release targets which we want to build docker images for
3. it extracts the tar files into sub folders. We need to extract into sub folders to so that our image can fine the binaries. By providing `platform` to `docker buildx` the variable `TARGETPLATFORM` will be available when building the image. This variable is either `linux/amd64/`, `linux/arm64/` or `linux/arm/v7`. Hence we need to extract into subfolders.
4. We create 2 images, one for the maker and one for the taker. The images are then pushed to our organisation's docker registry.
There is so much conditional logic on compiling for x64 and armv7
that we are better off with just defining two separate jobs without
any conditional logic.
These are mostly copy-pasted from xmr-btc-swap modulo the changelog
handling (because we don't have a changelog).
The gist is:
- We attach release binaries to every release that is created.
- Every merge to master creates a `preview` release.
- A merge from a branch that is named `release/x.y.z` creates a
release `x.y.z`.
- A new release branch can be created via `draft-new-release.yml`.
Bundling the frontend does not necessarily require type checking,
nor should type checking imply bundling.
TSC is also fairly slow. Separate the two and invoke tsc separately in
CI.
The only thing that has to stay in the root is the `index.html` file,
otherwise the dev server doesn't pick it up.
Also make sure our frontend tests actually run and pass in CI.
Achieving this is rather tricky due to the nature of our multi-page
project. We need to solve several problems:
1. We want a single npm project that produces two independent bundles.
2. We want our paths to be relative to the serving URL, that is `localhost:3000`
in development and in production, whereever the backend is hosted.
3. We have independent backends, hence requiring different `server.proxy`
configurations.
We solve (1) by using vite (already prior to this commit).
To solve (2), we simply remove all absolute URLs from the code and replace
them with absolute paths which will be relative to the serving host.
This creates a problem: Prior to this patch, we only have one devServer running
that would serve both frontends under a different sub-directory (/maker and /taker).
Even though this worked, it was impossible to create a proxy configuration that would:
- Forward API requests from `/maker` to `localhost:8001`
- Forward API requests from `/taker` to `localhost:8000`
Because in both cases, the API requests would simply start with `/api`, making
them indistinguishable from each other.
To solve this problem, we needed to serve each frontend separately. Doing so
would allow us to have dedicated proxy server configurations and forward the
requests to `/api` to the correct backend.
Unfortunately, the intuitive approach of solving this (have a `maker.html` and
`taker.html` file) does not work. With React being a client-side routing framework,
full page-reloads would be broken with this approach because they would be looking
for an `index.html` file which doesn't exist.
To work around this issue, our final solution is:
1. Use a dynamic ID to reference the desired app from within the `index.html`: `__app__`
2. Use a vite plugin to resolve this ID to the file in question: `maker.tsx` or `taker.tsx`
Fixes#6.
By doing a single `cargo build` ahead of time, we are creating all
necessary binaries at once. This allows our cache to work for tests
as well as the binaries.
There is also no need to use release binaries for the smoke test.
Building debug binaries is a lot faster and serves the same purpose:
Checking whether the application actually starts up.
dependabot[bot]
Thomas Eizinger
bonomat
Mariusz Klochowicz
itchymax
Daniel Karzel
rishflab