|
| 1 | +--- |
| 2 | +name: ci-change |
| 3 | +description: > |
| 4 | + Change or debug RevitDevTool CI and release workflows safely. Use whenever a task |
| 5 | + touches .github/ (ci.yml, release.yml, product-paths.yml, ci-jobs.json), the CI side |
| 6 | + of build/ (Products/CiJobs.cs, ProductPaths.cs, ProjectGraph.cs, Product.cs, |
| 7 | + Cli/Targets.cs), adds, moves, or renames a test or source project, investigates a red |
| 8 | + `ci / result` or a slow or flaky CI job, or plans a release run, even when the |
| 9 | + request only says "the pipeline", "GitHub Actions", or "why did CI fail". |
| 10 | +--- |
| 11 | + |
| 12 | +# CI Change |
| 13 | + |
| 14 | +Facts (flow, jobs, caches, timing) live in `docs/agents/ci.md`; releases in |
| 15 | +`docs/agents/release.md`; policy in ADR 0059. Read `ci.md` first. This skill holds |
| 16 | +the working rules, and each one comes from a CI run that went wrong. |
| 17 | + |
| 18 | +## Rules |
| 19 | + |
| 20 | +- **Logic goes in C#, not YAML.** A choice that depends on products, paths, host |
| 21 | + versions, or the event belongs in `build/` with a test in `tests/Build.Tests`. |
| 22 | + YAML only wires jobs, steps, and keys. Logic in YAML can't be run or tested locally, |
| 23 | + so each mistake costs a CI round. |
| 24 | +- **Generated files come from `build -- paths`.** Never edit `.github/product-paths.yml` |
| 25 | + or `.github/ci-jobs.json` by hand. After you change a project, a `ProjectReference`, |
| 26 | + `Product.cs`, `CiJobs.cs`, or a `Release.Autodesk.*` build type, run |
| 27 | + `dotnet run --project build -- paths` and commit both files. The test stage refuses |
| 28 | + stale copies. |
| 29 | +- **Reproduce locally before you push.** For a red job, read its log |
| 30 | + (`gh run view <id> --log-failed`), find the root cause, and reproduce it locally with the |
| 31 | + same `build` command the job runs (`ci <product>`, `test addin`, |
| 32 | + `compile addin --host-version <v>`). A race may need a loop: run the test until it |
| 33 | + fails. Push once, with that evidence. Pushing a guess spends a 5–10 minute run and |
| 34 | + hides the cause. |
| 35 | +- **Tests stay hermetic.** A test that writes HKCU, `%AppData%`, a fixed pipe name, or a |
| 36 | + shared file can break on a runner, and only by chance. Inject the key or path instead |
| 37 | + (see `docs/agents/test-matrix.md`). Don't make tests run in parallel across projects to |
| 38 | + save time: many still share pipes and AppData. |
| 39 | +- **Respect the cache budget.** Each matrix job owns `nuget-<cache>-<hash>`, and only a |
| 40 | + push saves it. The repository has 10 GB, so don't add a shared or extra cache. A new |
| 41 | + job gets its cache name from `CiJobs.cs`. |
| 42 | +- **Keep `result` the one required check.** A new job goes into `result.needs`, so a |
| 43 | + failure or cancellation still turns `result` red. |
| 44 | +- **Pin actions by SHA** with the version in a comment, as the existing steps do. |
| 45 | + Give each job `permissions:` and the least it needs. zizmor checks both. |
| 46 | +- **Don't add exit-code checks.** The runner's pwsh already exits with the last command's |
| 47 | + code, so `if ($LASTEXITCODE ...)` is noise. |
| 48 | + |
| 49 | +## Before pushing |
| 50 | + |
| 51 | +1. `dotnet run --project build -- paths` if any input of the generated files changed. |
| 52 | +2. `dotnet run --project tests/Build.Tests/Build.Tests.csproj` after a `build/` change. |
| 53 | +3. `docker run --rm -v "${PWD}:/repo" -w /repo rhysd/actionlint:1.7.12 -color` after a |
| 54 | + `.github/` change. If Docker is not running, ask the user to start it; don't push |
| 55 | + unlinted YAML. |
| 56 | +4. For a product failure, the local `build` command that failed on CI now passes. |
| 57 | +5. `pwsh -File scripts/format-lint.ps1` once, at the end. |
| 58 | +6. Fold the fix into the commit it corrects, then push with `--force-with-lease`. |
| 59 | + Commit messages: a subject plus 2–5 bullets. |
| 60 | + |
| 61 | +## After pushing |
| 62 | + |
| 63 | +- Watch with `gh run watch <id> --exit-status`, then list per-job times: |
| 64 | + `gh run view <id> --json jobs --jq '.jobs[] | "\(.name)\t\(.conclusion)\t\(.startedAt)\t\(.completedAt)"'`. |
| 65 | +- A change meant to speed CI up needs a before and after time for the job it targets. |
| 66 | + Update the timing table in `ci.md` when it moves. |
| 67 | +- A "Base … is not in this clone" bump warning right after a force push is expected. |
| 68 | + |
| 69 | +## Release workflow |
| 70 | + |
| 71 | +`release.yml` runs `release <product>` on one runner, then publishes after an |
| 72 | +environment approval (`docs/agents/release.md`). Treat a change there like a CI change, |
| 73 | +and also: |
| 74 | + |
| 75 | +- Secrets reach only `publish` and `channels`. `build` stays secret-free. |
| 76 | +- Check locally with `dotnet run --project build -- release <product> --dry-run`. Ask |
| 77 | + before you start a real release: it publishes outside the repository. |
| 78 | + |
| 79 | +## Update docs |
| 80 | + |
| 81 | +When observable CI behavior changes (jobs, triggers, caches, timing), update |
| 82 | +`docs/agents/ci.md`. Update `release.md` for release steps, and the ADR only for policy. |
0 commit comments