Repository navigation
install-labels: Install the agent labels on every pipeline repository - #126
Merged
Merged
Conversation
install-labels.yml has to inline the label list because gh aw add copies it into consumer repositories without the script, so the two copies are kept in sync by hand. Nothing checked that, and the pipeline-wide installer coming next applies the install-labels.js copy to every repository running the pipeline, so drift between the two would go unnoticed. Also document agent/flake-tracker, which the scripts README list was missing. Prep for installing labels on every pipeline repository. Generated-by: AI Signed-off-by: Colin Walters <walters@verbum.org>
installLabels() blindly PATCHed every label it found and only created one after a getLabel 404, which means a request per label per run even when nothing changed, and no way to see what a run would do. Split it into a pure planLabelChanges() over the repository's current labels and a small apply step behind a transport interface, so the planned diff is unit tested, can be printed as a dry run, and the upcoming multi-repository installer can reuse the same code with the gh CLI instead of carrying its own copy of the create/update logic. Labels are matched case-insensitively like GitHub does, so a label that differs only in case is renamed rather than failing to create a duplicate. Prep for installing labels on every pipeline repository. Generated-by: AI Signed-off-by: Colin Walters <walters@verbum.org>
Each repository running the pipeline installs its labels from its own copy of install-labels.yml, which only changes when that repository runs gh aw update, so a new or renamed label can take a long time to arrive: bcvk still lacks agent/drafter-working after the rename, and its drafter silently skips setting its working label because gh issue edit --add-label refuses unknown labels. Add install-labels-org.yml, run on every push to main, that applies LABELS to every bootc-dev repository containing any of drafter.lock.yml, review.lock.yml or fix.lock.yml, the compiled workflows gh aw add installs, so a repository that adopted only part of the pipeline still counts. Today that is bootc, bcvk, infra and gh-agentic-workflows; the other 17 repositories don't run the pipeline and have no use for agent/* labels, so they are skipped rather than cluttered. With --installation it only considers repositories the pipeline's App is installed on, so an adopter the App doesn't cover yet is not tried (and failed) on every run. It runs as a postsubmit rather than on a schedule: label changes land here, so a push is when there is something to apply, and syncing on every push rather than only label changes also repairs drift (labels edited by hand, or reverted by a repository's outdated install-labels.yml) without polling, for one label listing per pipeline repository when nothing changed. bootc-dev/infra already syncs labels.toml to every bootc-dev and composefs repository. Putting the agent labels there was considered, but that sync is unconditional, so it would need a per-label repository filter it doesn't have, and it would add a third copy of LABELS in a different repository with nothing checking it against the two here that gh aw add distributes. Keeping the agent labels here means one repository owns their definition, distribution and sync, while infra keeps owning org-wide labels; the two sets don't overlap. Nothing here runs against the live organization in PR CI; the dry run is available locally or by dispatching the workflow with dry-run. Closes: bootc-dev#104 Generated-by: AI Signed-off-by: Colin Walters <walters@verbum.org>
cgwalters
enabled auto-merge (squash)
October 2, 2026 20:28
cgwalters
approved these changes
Oct 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Each repository that runs the agent pipeline installs its labels from its own copy of
install-labels.yml, and that copy only changes when the repository runsgh aw update. So new or renamed labels can take a long time to arrive. For example bcvk still lacksagent/drafter-workingafter the rename, and its drafter silently skips setting the label becausegh issue edit --add-labelrefuses unknown labels.This adds
install-labels-org.yml, a postsubmit workflow (every push tomain, plus manual dispatch) that appliesLABELSfromscripts/install-labels.jsto every bootc-dev repository that runs the pipeline, meaning it has any ofdrafter.lock.yml,review.lock.ymlorfix.lock.yml. It uses the pipeline's App token and, with--installation, only considers repositories that App is installed on. It creates missing labels and fixes color, description and name case, but never deletes a label.About the scope: #104 says "org wide", but only 4 of the 21 bootc-dev repositories run the pipeline today (bootc, bcvk, infra, and this one), and the rest have no use for
agent/*labels. Labels that every repository should have are already synced org-wide by bootc-dev/infra'slabels.toml. Putting the agent labels there would need a per-repository filter that sync doesn't have, and it would add a third copy ofLABELSwith nothing checking it against the other two. So this repository keeps owning the agent labels and infra keeps owning the org-wide ones; the two sets don't overlap.The commits:
LABELScopy ininstall-labels.yml(whichgh aw adddistributes without the script) matchesinstall-labels.js. It also documentsagent/flake-tracker, which was missing from the README.installLabels()into a pureplanLabelChanges()and a small apply step, so the plan is unit tested and can be printed as a dry run, and one repository with no changes costs one list call instead of a PATCH per label. Labels are matched case-insensitively like GitHub does.Caveat: until a repository runs
gh aw update, its own weeklyinstall-labels.ymlstill has the oldLABELS. So after a color or description change here, that copy reverts the label weekly (and recreates a renamed label's old name) until that repository updates, and the next push tomainhere fixes it again. The README says so.Testing:
node --test tests/*.test.jspassed 20/20 under node 20 (the runner's default) on a 16-core devspace, and again 20/20 under node 22 on a 4-core devspace after dropping the weekly schedule (that rework only changed the workflow trigger and docs). A read-only dry run against the live org with the bot's token (node scripts/install-labels.js --org bootc-dev --dry-run) found 4 pipeline repositories and 1 change: createagent/drafter-workingon bcvk. It skipped the other 17. The write path was tested earlier against the bot's own fork. actionlint only complains that it doesn't knowcreate-github-app-token'sclient-idinput, which the other workflows here already use. PR CI never touches the live org.Not tested: the App installation-token path (
--installation, which lists repositories throughinstallation/repositories) has never run, because the bot has no installation token. The dry run above listed the org's repositories instead.After merging, note that the push trigger runs a live sync (not a dry run) right away, so bcvk gets
agent/drafter-workingimmediately. Before merging, it would be good to confirm that the App is installed on bcvk; otherwise--installationskips it. Manual dispatches default to a dry run, so a dispatch right after merge is a cheap way to check the installation-token path and see the plan.Closes #104
The
Signed-off-by: Colin Walters <walters@verbum.org>on these commits was added on cgwalters's approval of the review draft: cgwalters-forge#1 (review)Generated-by: https://github.com/cgwalters/#llms