Add create-labels maintenance operation and compile --json label reporting#24341
Add create-labels maintenance operation and compile --json label reporting#24341
Conversation
… problem-of-the-day Agent-Logs-Url: https://github.com/github/gh-aw/sessions/d6e9d52e-eb6a-46af-a3fd-d3250276d028 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
|
@copilot delete the new action and instead add a new command in the agentic maintenance action workflow "create labels" that compiles all the agentic workflows, collects the labels and generates all the labels.
|
…eporting and agentics-maintenance create_labels operation Agent-Logs-Url: https://github.com/github/gh-aw/sessions/55ecc334-0656-4098-9246-3d7b1c15f4c0 Co-authored-by: pelikhan <4175913+pelikhan@users.noreply.github.com>
Done in b347244. Here's what changed:
Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
There was a problem hiding this comment.
Pull request overview
Integrates a label-creation maintenance operation into the existing agentics maintenance workflow infrastructure, and extends compile --json output to report safe-outputs label references so missing repo labels can be created automatically.
Changes:
- Add
labelstocompile --jsonValidationResultoutput, populated from safe-outputs label references. - Introduce a
create_labelsmaintenance operation/job that compiles workflows and creates any missing repository labels. - Update documentation and label scratchpad to reflect new operation and domain labels.
Reviewed changes
Copilot reviewed 9 out of 9 changed files in this pull request and generated 5 comments.
Show a summary per file
| File | Description |
|---|---|
pkg/cli/compile_config.go |
Extends ValidationResult JSON schema with a labels field. |
pkg/cli/compile_validation.go |
Ensures labels are preserved through JSON sanitization/output. |
pkg/cli/compile_workflow_processor.go |
Extracts safe-outputs label references per workflow for JSON reporting. |
actions/setup/js/create_labels.cjs |
New script to compile workflows, gather label references, and create missing repo labels. |
pkg/workflow/maintenance_workflow.go |
Adds create_labels workflow_dispatch operation and dedicated job. |
pkg/workflow/maintenance_workflow_test.go |
Updates generator tests for new operation/job and pin occurrences. |
.github/workflows/agentics-maintenance.yml |
Recompiled workflow including the new create_labels job. |
.github/aw/github-agentic-workflows.md |
Documents compile --json --no-emit and the new maintenance operation. |
scratchpad/labels.md |
Documents new domain labels and adds them to the taxonomy list. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| // Collect labels from safe-outputs for JSON output (used by create-labels maintenance operation) | ||
| result.validationResult.Labels = extractSafeOutputLabels(workflowData) | ||
|
|
There was a problem hiding this comment.
Labels are only extracted after a successful compilation. If parsing succeeds but compilation fails (e.g., other validation errors), the JSON output for that workflow will omit labels, which defeats the purpose of compile --json as an inventory for create_labels. Consider extracting labels immediately after parsing (once workflowData is available) so they are present regardless of later compilation/validation failures.
| // extractSafeOutputLabels collects all unique labels referenced in safe-outputs configurations. | ||
| // These are labels that should exist in the repository for the workflow to function correctly. | ||
| // Scans: create-issue.labels/allowed-labels, create-discussion.labels/allowed-labels, | ||
| // create-pull-request.labels/allowed-labels, and add-labels.allowed. | ||
| func extractSafeOutputLabels(data *workflow.WorkflowData) []string { |
There was a problem hiding this comment.
extractSafeOutputLabels currently scans only create-issue/create-discussion/create-pull-request and add-labels, but there are additional safe-output configs that reference labels (e.g., remove-labels.allowed in pkg/workflow/remove_labels.go:13, update-discussion allowed-labels, missing-tool/missing-data labels, push-to-pull-request-branch labels). If the intent is “all labels referenced in safe-outputs”, this will miss some and create_labels won’t fully eliminate label-missing warnings. Either broaden the scan to all label-bearing safe-output configs or narrow/update the stated scope accordingly.
| * Generate a deterministic pastel hex color string from a label name. | ||
| * Produces colors in the pastel range (128–191 per channel) for readability. | ||
| * | ||
| * @param {string} name | ||
| * @returns {string} Six-character hex color (no leading #) | ||
| */ | ||
| function deterministicLabelColor(name) { | ||
| let hash = 0; | ||
| for (let i = 0; i < name.length; i++) { | ||
| hash = (hash * 31 + name.charCodeAt(i)) >>> 0; | ||
| } | ||
| // Map to pastel range: 128–223 per channel | ||
| const r = 128 + (hash & 0x3f); | ||
| const g = 128 + ((hash >> 6) & 0x3f); | ||
| const b = 128 + ((hash >> 12) & 0x3f); | ||
| return ((r << 16) | (g << 8) | b).toString(16).padStart(6, "0"); |
There was a problem hiding this comment.
The deterministic color docs are internally inconsistent: the function comment says pastel range is 128–191 per channel, but the inline comment says 128–223. The code uses 0x3f (0–63), so the actual range is 128–191. Please align the comment(s) with the actual range to avoid confusion.
| } catch (err) { | ||
| // 422 means label already exists (race condition) — treat as success | ||
| if (err && typeof err === "object" && /** @type {any} */ err.status === 422) { | ||
| core.info(`ℹ️ Label already exists (concurrent): ${labelName}`); | ||
| skipped++; | ||
| } else { | ||
| core.warning(`Failed to create label '${labelName}': ${getErrorMessage(err)}`); | ||
| } |
There was a problem hiding this comment.
Treating any HTTP 422 from issues.createLabel as “label already exists (race)” is too broad: 422 is also returned for other validation failures (invalid name/color, etc.). Consider checking the error payload/message for an “already exists” condition (e.g., response data errors/code) and only then downgrading to info; otherwise, surface it as a real warning/failure.
| async function main() { | ||
| const cmdPrefixStr = process.env.GH_AW_CMD_PREFIX || "gh aw"; | ||
| const [bin, ...prefixArgs] = cmdPrefixStr.split(" ").filter(Boolean); | ||
|
|
||
| // Run compile --json --no-emit to collect labels without writing lock files. | ||
| // Use ignoreReturnCode because compile exits non-zero when some workflows have errors, | ||
| // but still produces valid JSON output for all (valid and invalid) workflows. | ||
| const compileArgs = [...prefixArgs, "compile", "--json", "--no-emit"]; | ||
| core.info(`Running: ${bin} ${compileArgs.join(" ")}`); | ||
|
|
||
| let compileOutput; | ||
| try { | ||
| const result = await exec.getExecOutput(bin, compileArgs, { ignoreReturnCode: true }); | ||
| compileOutput = result.stdout; | ||
| // Only treat as a fatal error when the exit is non-zero AND there is no stdout at all. | ||
| // A non-zero exit with JSON on stdout means some workflows failed validation but we | ||
| // still have label data from the successfully-parsed ones — continue processing. | ||
| if (result.exitCode !== 0 && !compileOutput.trim()) { | ||
| throw new Error(`${ERR_SYSTEM}: compile exited with code ${result.exitCode}: ${result.stderr}`); | ||
| } | ||
| } catch (err) { | ||
| core.setFailed(`Failed to run compile: ${getErrorMessage(err)}`); | ||
| return; | ||
| } | ||
|
|
||
| // Parse JSON output | ||
| let validationResults; | ||
| try { | ||
| validationResults = JSON.parse(compileOutput); | ||
| } catch (err) { | ||
| core.setFailed(`Failed to parse compile JSON output: ${getErrorMessage(err)}`); | ||
| return; | ||
| } | ||
|
|
||
| // Collect all unique labels across all workflows | ||
| /** @type {Set<string>} */ | ||
| const allLabels = new Set(); | ||
| for (const result of validationResults) { | ||
| if (Array.isArray(result.labels)) { | ||
| for (const label of result.labels) { | ||
| if (typeof label === "string" && label.trim()) { | ||
| allLabels.add(label.trim()); | ||
| } | ||
| } | ||
| } | ||
| } | ||
|
|
||
| if (allLabels.size === 0) { | ||
| core.info("No labels found in safe-outputs configurations — nothing to create"); | ||
| return; | ||
| } | ||
|
|
||
| core.info(`Found ${allLabels.size} unique label(s) in safe-outputs: ${[...allLabels].join(", ")}`); |
There was a problem hiding this comment.
There are extensive unit tests for other actions/setup/js/*.cjs handlers, but create_labels.cjs is currently untested. Adding a focused test file (e.g., for label extraction from compile JSON, deterministic color output, and error handling paths like 422 already-exists vs other 422 validation failures) would reduce regression risk for this new maintenance operation.
- Fix add-wizard incorrectly listed as supporting --create-pull-request in the GHES paragraph (closes #24312) - Document compile --json labels field and create_labels maintenance operation (from #24341) - Document logs --train flag and audit report Agent Event Pattern Analysis section (from #24328) - Document agent_usage.json token artifact in compilation-process reference (from #24315) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- Fix add-wizard incorrectly listed as supporting --create-pull-request in the GHES paragraph (closes #24312) - Document compile --json labels field and create_labels maintenance operation (from #24341) - Document logs --train flag and audit report Agent Event Pattern Analysis section (from #24328) - Document agent_usage.json token artifact in compilation-process reference (from #24315) Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
The
constraint-solving-potdworkflow appliesconstraint-solvingandproblem-of-the-daylabels to discussions, but these labels don't exist in the repo — causing daily warnings in the safe-output health report and discussions being created without labels.Rather than a standalone one-shot workflow, this fix integrates label creation into the existing
agentics-maintenance.ymlinfrastructure so it can be reused for any workflow that references labels in safe-outputs.Changes
pkg/cli/compile_config.go/compile_workflow_processor.go—compile --jsonnow includes alabelsfield in eachValidationResult, populated from all safe-outputs label references (create-issue.labels/allowed-labels,create-discussion.labels/allowed-labels,create-pull-request.labels/allowed-labels,add-labels.allowed).actions/setup/js/create_labels.cjs— New script that runscompile --json --no-emit, collects all unique labels across all workflows, and creates any that are missing from the repository. Uses a deterministic pastel color per label and handles 422 races gracefully.pkg/workflow/maintenance_workflow.go— Addscreate_labelsas a newworkflow_dispatchoperation. A dedicatedcreate_labelsjob (withissues: writepermission) handles this operation; the genericrun_operationjob explicitly excludes it..github/workflows/agentics-maintenance.yml— Recompiled to include the newcreate_labelsjob..github/aw/github-agentic-workflows.md— Documentscompile --json --no-emitand lists all availableagentics-maintenance.ymloperations includingcreate_labels.scratchpad/labels.md— Adds a "Domain Labels" category documenting the new labels and their owning workflow.