fix(ci): gate the Built-stamp repair on its own variable #151

Merged

pat-s merged 1 commit from fix/repair-pipeline-gate-var into main

2026-08-07 09:41:54 +00:00

pat-s commented

2026-08-07 09:39:09 +00:00

Owner

Problem

repair-built-stamp.yaml gated on target_arch:

when:
  - event: manual
    evaluate: 'target_arch == "${ARCH}"'

That is the same variable build-all-versions.yaml and build-all-versions-install-deps.yaml gate on. A manual run passing target_arch=arm64 to reach the repair therefore matched all three, so triggering a dry-run repair also queued a full arm64 rebuild.

I hit this triggering the alpine 3.22 dry run (pipeline 10706), which I killed. crow pipeline ps renders empty states on this version, so I could not confirm from the CLI whether the rebuild workflows started before the kill or only sat queued behind the running cron jobs; no output was attributable to them.

Change

Gate on repair_built_stamp instead. Every other pipeline here already gates on a variable named after itself (process_cran_updates, weekly_audit_missing, weekly_rebuild_missing), and target_arch was the odd one out being shared by two.

The header now records the collision and the exact invocation, so the next pipeline added here does not repeat it.

Verification

crow lint passes; prek clean.

Grep of every trigger condition in .crow/ confirms repair_built_stamp is unique and that no other pipeline gates on OS, OS_VERSION, R_VERSION or dry_run alone:

archive-missed-packages.yaml:  task == "archive-missed-packages"
build-all-versions.yaml:       target_arch == "${ARCH}"
build-all-versions-install-deps.yaml: target_arch == "${ARCH}"
weekly-audit-missing.yaml:     weekly_audit_missing == ...
repair-built-stamp.yaml:       repair_built_stamp == "${ARCH}"
process-updates.yaml:          process_cran_updates == ...
weekly-rebuild-missing.yaml:   weekly_rebuild_missing == ...

Note for whoever runs it

crow pipeline create against this instance returned HTTP 504 while still creating the pipeline. Retrying on that error duplicates the run: I created four before noticing. Verify with pipeline ls rather than trusting the exit status.

## Problem `repair-built-stamp.yaml` gated on `target_arch`: ```yaml when: - event: manual evaluate: 'target_arch == "${ARCH}"' ``` That is the same variable `build-all-versions.yaml` and `build-all-versions-install-deps.yaml` gate on. A manual run passing `target_arch=arm64` to reach the repair therefore matched all three, so triggering a dry-run repair also queued a full arm64 rebuild. I hit this triggering the alpine 3.22 dry run (pipeline 10706), which I killed. `crow pipeline ps` renders empty states on this version, so I could not confirm from the CLI whether the rebuild workflows started before the kill or only sat queued behind the running cron jobs; no output was attributable to them. ## Change Gate on `repair_built_stamp` instead. Every other pipeline here already gates on a variable named after itself (`process_cran_updates`, `weekly_audit_missing`, `weekly_rebuild_missing`), and `target_arch` was the odd one out being shared by two. The header now records the collision and the exact invocation, so the next pipeline added here does not repeat it. ## Verification `crow lint` passes; `prek` clean. Grep of every trigger condition in `.crow/` confirms `repair_built_stamp` is unique and that no other pipeline gates on `OS`, `OS_VERSION`, `R_VERSION` or `dry_run` alone: ``` archive-missed-packages.yaml: task == "archive-missed-packages" build-all-versions.yaml: target_arch == "${ARCH}" build-all-versions-install-deps.yaml: target_arch == "${ARCH}" weekly-audit-missing.yaml: weekly_audit_missing == ... repair-built-stamp.yaml: repair_built_stamp == "${ARCH}" process-updates.yaml: process_cran_updates == ... weekly-rebuild-missing.yaml: weekly_rebuild_missing == ... ``` ## Note for whoever runs it `crow pipeline create` against this instance returned HTTP 504 while still creating the pipeline. Retrying on that error duplicates the run: I created four before noticing. Verify with `pipeline ls` rather than trusting the exit status.

pat-s added 1 commit

2026-08-07 09:39:09 +00:00

fix(ci): gate the Built-stamp repair on its own variable 283476ed1a

The pipeline gated on `target_arch`, which is the same variable
build-all-versions and build-all-versions-install-deps gate on. A manual run
passing `target_arch=arm64` to reach the repair therefore also matched both of
those and started a full arm64 rebuild alongside it.

Every other pipeline here gates on a variable named after itself
(`process_cran_updates`, `weekly_audit_missing`, `weekly_rebuild_missing`), so
follow that and gate on `repair_built_stamp`. Record the collision and the exact
invocation in the header so the next pipeline added here does not repeat it.

pat-s merged commit 77ce1d212d into main

2026-08-07 09:41:54 +00:00

pat-s deleted branch fix/repair-pipeline-gate-var

2026-08-07 09:41:54 +00:00

pat-s referenced this pull request from a commit

2026-08-07 09:41:55 +00:00

fix(ci): gate the Built-stamp repair on its own variable (#151)