ci: build dev track and PR checks against dependency main #29
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "feature/dev-deps-main"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Part of ECO-38. Depends on Breadway/bread-ecosystem#39 merging first: dev-release.yml and check.yml both fetch scripts/dev-deps.sh (and check.yml also scripts/lint-pins.sh) from bread-ecosystem's main branch, which doesn't have those scripts until that PR lands. Until then, this branch's own check.yml run is expected to fail at the "resolve dev dependencies to main" / "lint git.breadway.dev dependency pins" steps with a missing-file error, not a real failure of this change.
dev-release.yml now clones bread-ecosystem main once (reused for both dev-deps.sh and the existing regenerate-index step, which used to clone it a second time), runs scripts/dev-deps.sh to patch bread-theme, bread-utils, bread-screenshots, bread-launcher (from bread-ecosystem) and bread-shared (from bread) to their own main branches, and builds without --locked. The dependency SHA record dev-deps.sh writes (dev-deps.lock.txt) now ships alongside the binary in /srv/breadway-dl/dev/breadbar//.
check.yml gets the same treatment for feature/fix branch pushes, plus a new pin-lint step (bread-ecosystem's scripts/lint-pins.sh) so a Cargo.toml regression away from tag pins fails fast. The existing "guard against a committed patched Cargo.lock" step stays, checked before dev-deps.sh runs (it inspects the Cargo.lock as committed, not the one dev-deps.sh deliberately rewrites for this job).
rc-release.yml and release.yml are untouched: tag pins plus --locked, no patching, as before.
One non-obvious detail: DEV_DEPS_DIR is pointed inside the checkout (src/.dev-deps) rather than dev-deps.sh's sibling-directory default. ci/build.sh's docker wrapper only bind-mounts the checkout root (REPO_ROOT -> /workspace) into the container that actually runs cargo, so a true sibling clone outside src would be invisible to the containerized build/clippy/test steps. Keeping the clone and the generated .cargo/config.toml's relative paths inside src makes them resolve identically on the host (where dev-deps.sh runs cargo update) and inside the container.
Tested locally end to end (see the ECO-38 progress comment): a full cargo build --release of breadbar against both bread-ecosystem main and bread main via the patches actually compiled and linked, and a clean clone with no .cargo/config.toml still does cargo build --release --locked against the tagged v0.7.11/v0.8.0 pins.