2024-02-24 23:55:58 +00:00
|
|
|
name: nix
|
2022-02-20 20:48:51 +00:00
|
|
|
|
|
|
|
|
on:
|
|
|
|
|
push:
|
|
|
|
|
branches:
|
github: don't run build workflows twice on push to `main`
The new `merge_group` event will already attach all the CI events from the
various workflows where it applies. If the merge queue is drained and merges to
`main`, having `push` on these workflows will cause them to be run again, doubling
the number of CI checks. We don't need `push` anymore, basically.
Also, because checks can be cancelled now, the current double running can
probably lead to an awkward setup like:
- Merge Queue merges A to main, starts `push` workflows
- Merge Queue then merges B and C to main, starts `push` workflows
- `A`'s workflows get cancelled if it's not yet done
- This makes it look like `A` has failing tests somehow, but it doesn't
Therefore, just removing the double builds is the first step to cut down on the
CI times for our repo.
We also run the build workflows on all pushes to NOT main, because that will
help people who want to run CI before opening an actual PR.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2025-01-08 21:48:14 +00:00
|
|
|
- '**'
|
2025-01-10 01:14:42 +00:00
|
|
|
# Disable builds on these branches, because they will become a pull
|
|
|
|
|
# request, and be handled by merge_group below.
|
|
|
|
|
- '!dependabot/**'
|
|
|
|
|
# `main` and `gh-readonly-queue` are handled by merge_group specifically.
|
|
|
|
|
- '!gh-readonly-queue/**'
|
|
|
|
|
- '!main'
|
2022-02-20 20:48:51 +00:00
|
|
|
pull_request:
|
2025-01-08 02:46:21 +00:00
|
|
|
merge_group:
|
2022-02-20 20:48:51 +00:00
|
|
|
|
2024-11-06 05:34:59 +00:00
|
|
|
concurrency:
|
|
|
|
|
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.ref }}
|
2025-01-08 22:00:31 +00:00
|
|
|
cancel-in-progress: ${{ github.ref != 'refs/heads/main' }}
|
2024-11-06 05:34:59 +00:00
|
|
|
|
2022-03-16 19:18:01 +00:00
|
|
|
permissions: read-all
|
|
|
|
|
|
2022-02-20 20:48:51 +00:00
|
|
|
jobs:
|
|
|
|
|
nix:
|
2024-02-24 23:55:58 +00:00
|
|
|
strategy:
|
|
|
|
|
fail-fast: false
|
|
|
|
|
matrix:
|
2025-01-06 23:12:36 +00:00
|
|
|
os: [ubuntu-24.04, macos-14]
|
2024-02-24 23:55:58 +00:00
|
|
|
runs-on: ${{ matrix.os }}
|
2024-02-23 07:20:19 +00:00
|
|
|
timeout-minutes: 15 # NOTE (aseipp): keep in-sync with the build.yml timeout limit
|
2024-02-24 23:55:58 +00:00
|
|
|
|
|
|
|
|
name: flake check
|
2022-02-20 20:48:51 +00:00
|
|
|
steps:
|
2024-10-23 15:56:10 +00:00
|
|
|
- uses: actions/checkout@11bd71901bbe5b1630ceea73d27597364c9af683
|
2022-02-20 20:48:51 +00:00
|
|
|
with:
|
|
|
|
|
fetch-depth: 0
|
2024-11-15 15:45:32 +00:00
|
|
|
- uses: DeterminateSystems/nix-installer-action@e50d5f73bfe71c2dd0aa4218de8f4afa59f8f81d
|
2025-01-22 15:45:04 +00:00
|
|
|
- uses: DeterminateSystems/magic-nix-cache-action@6221693898146dc97e38ad0e013488a16477a4c4
|
github(nix): don't build everything twice
When running the `nix build`, the `buildRustPackage` function -- which builds
the `jj` crates -- calls `cargo build --release` with flags like `HOST_CXX`
set. This is called the `buildPhase`. Then, it runs the `checkPhase`, which
calls `cargo nextest`, in our case. However, it does not set `HOST_CXX`, for
some reason.
The intent of `buildRustPackage` is that the `buildPhase` and `checkPhase`
have their compilation options fully aligned so that they reuse the local cargo
`target/` cache directory, avoiding a full recompilation. However, the lack
of `HOST_CXX` above among others causes a cache miss, and a bunch of cascading
recompilations. The net impact is that we compile all of the codebase once in
`buildPhase`, then again in `checkPhase`, making the Nix CI build 2x slower on
average than the other Linux runners; 2-3 minutes versus 7 minutes, on average.
Instead, re-introduce a 'check' into the Flake directly, which overrides the
`jujustsu` package, but stubs out the `buildPhase`. This means it will only run
`checkPhase`, which is what we want. Then, modify the CI to run `nix flake check`
again, like it used to in the past.
Unfortunately, this doesn't fix the cache miss when running `nix build`
yourself, it recompiles from scratch in both phases still. That needs to be
fixed in the future, but it's tolerable for now.
This reverts most of 71a3045032f512.
Signed-off-by: Austin Seipp <aseipp@pobox.com>
2024-02-22 01:50:47 +00:00
|
|
|
- run: nix flake check -L --show-trace
|
