Updating CI pipeline to automatically sync workspace Cargo.lock
This commit is contained in:
parent
9af09e993f
commit
a7c14aefd5
3 changed files with 22 additions and 4 deletions
|
|
@ -121,6 +121,16 @@ jobs:
|
||||||
key: ${{ github.job }}-cargo-${{ hashFiles('**/Cargo.lock', 'rust-toolchain.toml') }}
|
key: ${{ github.job }}-cargo-${{ hashFiles('**/Cargo.lock', 'rust-toolchain.toml') }}
|
||||||
restore-keys: ${{ github.job }}-cargo-
|
restore-keys: ${{ github.job }}-cargo-
|
||||||
|
|
||||||
|
- name: Sync the lockfile to the workspace version
|
||||||
|
# Bumping [workspace.package] version leaves Cargo.lock pinning the old
|
||||||
|
# member versions, and --locked then refuses to build. `cargo update -w`
|
||||||
|
# re-resolves only the workspace members and leaves every third-party pin
|
||||||
|
# alone - it reports the others as "unchanged dependencies behind latest"
|
||||||
|
# rather than bumping them. So --locked below still catches the case that
|
||||||
|
# actually matters: a dependency added or bumped without committing the
|
||||||
|
# lockfile, which this cannot and should not paper over.
|
||||||
|
run: cargo update -w
|
||||||
|
|
||||||
- name: Build
|
- name: Build
|
||||||
run: cargo build --release --locked -p quicksearch-gui
|
run: cargo build --release --locked -p quicksearch-gui
|
||||||
|
|
||||||
|
|
@ -231,6 +241,11 @@ jobs:
|
||||||
key: ${{ github.job }}-cargo-${{ hashFiles('**/Cargo.lock', 'rust-toolchain.toml') }}
|
key: ${{ github.job }}-cargo-${{ hashFiles('**/Cargo.lock', 'rust-toolchain.toml') }}
|
||||||
restore-keys: ${{ github.job }}-cargo-
|
restore-keys: ${{ github.job }}-cargo-
|
||||||
|
|
||||||
|
- name: Sync the lockfile to the workspace version
|
||||||
|
# Same reasoning as the linux job: workspace members only, third-party
|
||||||
|
# pins untouched, so --locked keeps its teeth.
|
||||||
|
run: cargo update -w
|
||||||
|
|
||||||
- name: Build
|
- name: Build
|
||||||
# rust-toolchain.toml already lists the target, so no `rustup target add`.
|
# rust-toolchain.toml already lists the target, so no `rustup target add`.
|
||||||
run: cargo build --release --locked -p quicksearch-gui --target "$TARGET"
|
run: cargo build --release --locked -p quicksearch-gui --target "$TARGET"
|
||||||
|
|
|
||||||
4
Cargo.lock
generated
4
Cargo.lock
generated
|
|
@ -3190,7 +3190,7 @@ dependencies = [
|
||||||
|
|
||||||
[[package]]
|
[[package]]
|
||||||
name = "quicksearch-core"
|
name = "quicksearch-core"
|
||||||
version = "0.9.0"
|
version = "0.9.1"
|
||||||
dependencies = [
|
dependencies = [
|
||||||
"argon2",
|
"argon2",
|
||||||
"chardetng",
|
"chardetng",
|
||||||
|
|
@ -3222,7 +3222,7 @@ dependencies = [
|
||||||
|
|
||||||
[[package]]
|
[[package]]
|
||||||
name = "quicksearch-gui"
|
name = "quicksearch-gui"
|
||||||
version = "0.9.0"
|
version = "0.9.1"
|
||||||
dependencies = [
|
dependencies = [
|
||||||
"chrono",
|
"chrono",
|
||||||
"eframe",
|
"eframe",
|
||||||
|
|
|
||||||
|
|
@ -390,8 +390,11 @@ pagination: the table is virtualized, so a single scroll list capped at
|
||||||
snippet_perf -- --nocapture`: snippet pipeline benchmark.
|
snippet_perf -- --nocapture`: snippet pipeline benchmark.
|
||||||
- `.forgejo/workflows/ci.yml`: builds both platforms on every push to `master`
|
- `.forgejo/workflows/ci.yml`: builds both platforms on every push to `master`
|
||||||
and every pull request. To cut a release, bump `[workspace.package] version`
|
and every pull request. To cut a release, bump `[workspace.package] version`
|
||||||
in `Cargo.toml`, run `cargo update -w` so the lockfile agrees (CI builds with
|
in `Cargo.toml` and push the commit on a branch named `Release...`; CI runs
|
||||||
`--locked`), and push the commit on a branch named `Release...`. Once both
|
`cargo update -w` first, so a lockfile still pinning the old member versions
|
||||||
|
is not something you have to remember. That only re-resolves the workspace
|
||||||
|
crates, so the `--locked` build after it still fails on a dependency added or
|
||||||
|
bumped without committing `Cargo.lock`. Once both
|
||||||
build jobs are green, CI tags that commit `v<version>` and publishes a release
|
build jobs are green, CI tags that commit `v<version>` and publishes a release
|
||||||
with the `.deb`, a Linux tarball and a Windows zip attached; pushing a `v*`
|
with the `.deb`, a Linux tarball and a Windows zip attached; pushing a `v*`
|
||||||
tag by hand does the same thing. The version is never taken from the branch
|
tag by hand does the same thing. The version is never taken from the branch
|
||||||
|
|
|
||||||
Loading…
Add table
Reference in a new issue