mirror of
https://github.com/kevinveenbirkenbach/computer-playbook.git
synced 2026-11-08 03:38:23 +00:00
kevinveenbirkenbachandClaude Opus 5.5
5bd4f778c3
9850d5afa0disabled the job-level deploy group because it blocked the queue and kept jobs from being cancelled. Both causes are addressed: - Cancelling: the chunks that call this workflow guarded with always(), so a cancelled run kept its deploy jobs alive and they kept holding their groups. Sincea5f00ca777the chunks guard with !cancelled() and die with the run, which releases the group. - Blocking: the key held only mode, tor, apps and variant, so rows that differ in distro or filesystem waited on each other across branches. The key now carries every axis the matrix generator emits, the same set artifact_slug identifies a deployment by: mode, tor, distro, filesystem, apps and variant. Two runs now only meet on an exactly identical deployment. A sample matrix of eighteen rows had every axis set and no duplicate key within the run. queue: max keeps the second identical row queued instead of replacing the waiting one; GitHub accepted the key in all 200 runs of August, and scripts/lint/action.sh already ignores actionlint's unknown-key report for it. No resource shared per row was found in the deploy path: jobs push no images, write nothing through the API and use no actions/cache, and hosted runners are isolated. The serialization is the cross-branch orderingae9d7c2fd3introduced, not the protection of a resource. A TODO asks a CI deploy to confirm that a cancel drops queued jobs from the group and that an identical row of a second run queues behind it. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>