ci: build dev track and PR checks against dependency main #5
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.
check.yml and dev-release.yml now clone bread-ecosystem's main once, run scripts/lint-pins.sh (check.yml only) and scripts/dev-deps.sh to patch bread-onnx and bread-utils (both from bread-ecosystem) to their own main branch, and build without --locked. Cargo.toml stays tag-pinned throughout; nothing is committed back.
rc-release.yml and release.yml are untouched: tag pins plus --locked, no patching, as before.
DEV_DEPS_DIR is left at its default (a true sibling of the checkout): breadarr is a Cargo workspace, so forcing the clone inside the checkout breaks Cargo's workspace-field inheritance (the bug found rolling this out to breadbox). ci/build.sh's pinned rev is bumped to bread-ecosystem's fix for this.
Verified locally end to end: lint-pins, dev-deps.sh with its default sibling DEV_DEPS_DIR, and a dockerized cargo clippy --workspace through ci/build.sh all pass against a real breadarr checkout, clean, with no new warnings.
Note on this PR's own check.yml run:
check / check (push)shows failure, but not from anything in this diff.cargo test --workspacefails because breadarrd's transcode/import tests shell out to a realffmpegbinary to generate test clips, and the shared bread-ci Docker image (breadarr has noci/deps.txtto add packages to it) has never included ffmpeg. Checked breadarr's CI history:check.ymlhas failed on every single run back to 2026-08-05, including plain pushes tomainwith no dev-deps involvement at all, so this is a pre-existing, unrelated gap, not something this PR introduced.check / check (pull_request)also fails instantly (0s) on this repo, again predating this PR: thepull_requesttrigger'sGITHUB_REF_NAMEisn't a real branch name the checkout step'sgit clone --branchcan resolve.dev-release.yml(the actual dev-track build that matters for ECO-38) has no test step and is unaffected by either issue; only reports back to the owner if they want these two CI gaps looked at separately.