[necessarylion]

Problem

CI gets the other Dox packages from pub.dev. So a PR that needs a change in another Dox repo fails until that repo is released.

What this changes

• New ci/use-siblings.sh. On a PR or a push to main, it clones these repos next to this one: dox, dox-orm, dox-validation, dox-openapi, ioredis, dox-http-native, dox-postgres-native, dox-mysql-native.
• For each repo it takes the branch with the same name as this PR, if that repo has it (git ls-remote). Else it takes main.
• It writes a root pubspec_overrides.yaml (gitignored) with path overrides. Then CI runs dart pub get.
• ci/use-siblings.sh build builds the native packages with cargo build --release, only for the runner (linux x64), not all 5 release targets. The build hook takes the library from native/target/release. Swatinem/rust-cache caches the Rust dependencies.
• The list also has the Dox repos that our Dox packages use (for example dox-validation for dox_core). Pub needs all of them from the same code. The lists of the clones are not followed, so there is no loop.
• Release: the Release workflow now runs the CI tests first (workflow_call) and publishes only when they pass. On a tag the script does nothing, so the tests use pub.dev only.

How to use it

Give a linked change the same branch name in every repo. The CI of each PR then tests against the other PRs, before anything is released.

CI time

• Before (last green run on main, pub.dev only): 49s.
• After: this PR, first run with a cold Rust cache: test 2m5s. Native build on a cold cache: dox-http-native about 15-22s, dox-postgres-native and dox-mysql-native about 30-38s each. With the Rust cache warm (second run): 8-14s each.

[necessarylion]

Bot review

Verdict: OK to merge. CI is green. No blocking problems.

What I checked:

• Branch lookup. It uses refs/heads/<branch>, so a branch like feat/main does not match main. GITHUB_HEAD_REF is used on a PR, GITHUB_REF_NAME on a push to main. Branch names with slashes work (this PR's run cloned dox on ci/test-against-siblings and the rest on main).
• Release. On a tag the script exits before it clones or writes anything, and the build step and rust-cache are skipped. So the tag tests use pub.dev only. release.yaml runs ci.yaml first and publish has needs: test. ci.yaml only runs on push to main and on PRs, so a tag does not run the tests twice. pubspec_overrides.yaml is in .gitignore. The publish job is a fresh checkout, so it never sees an override.
• Native build. cargo build --release with no --target builds only for the runner. The build hook checks native/target/release before anything else on the host, and a path dependency never downloads before it tries cargo. So the local build is used. set -euo pipefail makes a cargo error fail the job. The rust-cache key includes the clone's Cargo.lock, and the run log shows it saves and restores.
• Security. No pull_request_target, no secrets in ci.yaml. The branch name reaches the shell only as a quoted env var, never through ${{ }}. The test job in release.yaml only gets contents: read (the top-level permissions). id-token: write stays on the publish job.
• Sibling list. It matches the Dox packages this repo uses, including the ones they use in turn.

Optional nits (no need to fix in this PR):

1. The header of release.yaml still says "Wait for CI to be green on main before you push the tag". The workflow now runs the tests itself, so this line can go.
2. A fork PR uses the fork's branch name for the lookup. If dartondox has a branch with the same name, CI tests against that branch. This is rare. A fix: only use GITHUB_HEAD_REF when the PR comes from dartondox.
3. Duplication: the same script is in 10 repos, and only the list is different. I think this is fine for now. It also runs locally, which a shared remote script would not. If it changes again, move it to one composite action in dartondox/dox that takes the list as input.