feat(#5187): provision pipeline labels during enrollment - #5564
feat(#5187): provision pipeline labels during enrollment#5564fullsend-ai-coder[bot] wants to merge 1 commit into
Conversation
Each harness YAML now declares the labels its post-scripts require via a new `labels` field. During `fullsend admin install`, the install flow reads these declarations from the embedded scaffold and creates them in the target repo using `CreateLabel` (idempotent — existing labels are left unchanged). This ensures that newly enrolled repos have all pipeline-critical labels (ready-for-review, ready-for-merge, requires-manual-review, ready-to-code, triaged, rejected, needs-human, fullsend-fix, fullsend-no-fix) from the start, rather than relying on post-scripts to create them reactively. The approach is agent-driven — adding a new agent with new label requirements only requires updating that agent's harness YAML. Changes: - Add LabelDef struct and labels field to harness.Harness - Add CreateLabel to forge.Client interface (GitHub + GitLab impls) - Add scaffold.CollectHarnessLabels() to extract labels from embedded harness YAML files - Add label provisioning step to repos.Install() between scaffold commit and variable writes - Add label declarations to code, review, triage, and fix harnesses - Add tests for label collection and install-time provisioning Closes #5187
|
🤖 Finished Review · ✅ Success · Started 9:57 AM UTC · Completed 10:13 AM UTC |
Site previewPreview: https://a8585b1c-site.fullsend-ai.workers.dev Commit: |
Codecov Report❌ Patch coverage is 📢 Thoughts on this report? Let us know! |
ReviewFindingsLow
Labels: PR adds label provisioning to the repos install flow and extends the harness schema with a labels field |
![fullsend-ai-review[bot]](https://avatars.githubusercontent.com/in/3478501?s=60&v=4){kind=small}
| if len(harnessLabels) > 0 { | ||
| progress(repoFullName, "labels", fmt.Sprintf("Provisioned %d pipeline labels", len(harnessLabels))) | ||
| } | ||
|
|
There was a problem hiding this comment.
[low] stale-reference
Duplicate step number after insertion. The PR inserts a new Step 6 (labels) and renumbers the old Step 6 (vars) to Step 7, but does not renumber the existing Step 7 (secrets) to Step 8. After merge there will be two comments reading '// Step 7'.
Suggested fix: Renumber '// Step 7: Write repository secrets.' to '// Step 8: Write repository secrets.'
| @@ -233,6 +238,10 @@ type FakeClient struct { | |||
| // Annotations for GetWorkflowRunAnnotations. | |||
There was a problem hiding this comment.
[low] field-ordering-and-comments
CreatedLabels field is positioned before the '// Call recorders' section but logically belongs within it (all other Created*/Deleted*/Updated* fields appear after that comment). Additionally, the field has a misleading two-line comment: the first line describes the type rather than the field, duplicating the type's own godoc.
Suggested fix: Move CreatedLabels into the '// Call recorders' block alongside other Created* fields. Remove the duplicate type-description comment.
fullsend-ai-review
Bot
added
ready-for-merge
|
Harnesses will be removed from here, remove their changes (left for @maruiz93 to do as assignee, feel free to use the fix agent). |
|
As per the discussion we had yesterday on our meeting, we can close this until we decide the refactor the thing. |
|
🤖 Finished Retro · ✅ Success · Started 7:26 AM UTC · Completed 7:49 AM UTC |
Retro: PR #5564 — provision pipeline labels during enrollmentOutcome: PR closed without merge after human reviewer identified an architectural conflict with ongoing harness extraction work. Timeline
Total wasted cost: ~$14.44 ($9.23 code + $5.21 review) on a PR that was architecturally misaligned with a planned refactoring documented 22 days earlier. Root causeNeither the code agent nor the review agent discovered Evidence for existing issues (not filing new proposals)
Proposals filed |
2 participants
Summary
Add label provisioning during enrollment so newly enrolled repos have all pipeline-critical labels from the start. Each harness YAML now declares the labels its post-scripts require, and the install flow creates them idempotently in the target repo.
Related Issue
Fixes #5187
Changes
LabelDefstruct andlabelsfield toharness.Harness— each agent can declare required labelsCreateLabeltoforge.Clientinterface with GitHub and GitLab implementations (idempotent — existing labels are not modified)scaffold.CollectHarnessLabels()to extract and deduplicate labels from embedded harness YAML filesrepos.Install()(runs between scaffold commit and variable writes)FakeClient.CreateLabelfor testingTestCollectHarnessLabels,TestInstall_ProvisionLabels,TestInstall_LabelCreateErrorTesting
go build ./...passesgo vetpasses on affected packagesgo testpasses on all affected packages (scaffold, repos, forge, harness)scan-secretspasses on all changed filesChecklist
Closes #5187
Post-script verification
agent/5187-provision-labels)1863fc6d4268946ee035cac06ced81e173e14a6a..HEAD)