feat(governance): canonical issue fields + metadata backfill automation#433
Conversation
|
Warning Review limit reached
More reviews will be available in 40 minutes and 3 seconds. Learn how PR review limits work. Your organization has run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yml Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (1)
📒 Files selected for processing (12)
Note
|
github-actions
Bot
added
area:ci
🔍 Reviewer Summary for PR #433CI Status: ✅ Recommendations
|
github-actions
Bot
added
priority:normal
…a backfill support
ashleyshaw
force-pushed
the
codex/issue-fields-governance-rollout
branch
from
5f13eac to
3d0047c
Compare
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a canonical issue and PR field model along with supporting automation, audits, and documentation. Key additions include the .github/issue-fields.yml configuration, a documentation guide in docs/ISSUE-FIELDS.md, a script to derive project fields from labels, and a validation script to ensure consistency between the configuration and documentation. Feedback from the review highlights several improvement opportunities: the validation script and documentation currently omit Type labels, which should be added to ensure complete coverage. Additionally, robust defensive checks should be added to both derive-project-fields.cjs and validate-issue-fields.cjs to prevent potential runtime TypeError exceptions when parsing empty or invalid YAML configurations.
| ...collectKeys(fieldMappings.Status), | ||
| ...collectKeys(fieldMappings.Priority), |
There was a problem hiding this comment.
The validation script currently checks for the presence of canonical Status and Priority labels in docs/ISSUE-FIELDS.md, but it completely omits the Type labels (e.g., type:bug, type:feature, etc.). To ensure complete documentation coverage, we should add ...collectKeys(fieldMappings.Type) to canonicalDocAnchors. Note that you will also need to update docs/ISSUE-FIELDS.md to document these canonical Type mappings so the validation passes.
...collectKeys(fieldMappings.Status),
...collectKeys(fieldMappings.Priority),
...collectKeys(fieldMappings.Type),
| Canonical `Priority` label mappings: | ||
|
|
||
| - `priority:critical` -> `Critical` | ||
| - `priority:important` -> `Important` | ||
| - `priority:normal` -> `Normal` | ||
| - `priority:minor` -> `Minor` | ||
|
|
There was a problem hiding this comment.
The documentation lists the canonical mappings for Status and Priority, but it completely omits the mappings for Type (e.g., type:bug -> Bug, type:feature -> Feature, etc.), even though Type is listed as a synced field. Please add the canonical Type mappings to this document to keep it aligned with .github/issue-fields.yml and to support the validation script once Type validation is enabled.
Canonical `Priority` label mappings:
- `priority:critical` -> `Critical`
- `priority:important` -> `Important`
- `priority:normal` -> `Normal`
- `priority:minor` -> `Minor`
Canonical `Type` label mappings:
- `type:bug` -> `Bug`
- `type:feature` -> `Feature`
- `type:documentation` -> `Documentation`
- `type:task` -> `Task`
- `type:chore` -> `Task`
- `type:test` -> `Task`
- `type:maintenance` -> `Task`
- `type:security` -> `Task`
- `type:performance` -> `Task`
- `type:a11y` -> `Task`
- `type:design` -> `Task`
- `type:integration` -> `Task`
- `type:release` -> `Task`
- `type:automation` -> `Task`
- `type:qa` -> `Task`
- `type:ai-ops` -> `Task`
- `type:audit` -> `Task`
- `type:research` -> `Task`
- `type:compatibility` -> `Task`
- `type:epic` -> `Task`
- `type:question` -> `Task`
- `type:support` -> `Task`
- `type:content-modelling` -> `Task`
- `type:story` -> `Task`
- `type:improve` -> `Task`
- `type:review` -> `Task`
| ? path.resolve(process.env.ISSUE_FIELDS_CONFIG) | ||
| : path.resolve(".github/issue-fields.yml"); | ||
|
|
||
| const cfg = readConfig(configPath); |
There was a problem hiding this comment.
If the configuration file .github/issue-fields.yml is empty or invalid, yaml.load(raw) can return null or undefined. In that case, accessing cfg.project_field_mappings on line 37 will throw a TypeError: Cannot read properties of null. We should add a defensive check to ensure cfg is a valid object before proceeding.
const cfg = readConfig(configPath);
if (!cfg || typeof cfg !== "object") {
console.error("Error: Invalid or empty configuration file.");
process.exit(1);
}
| const cfg = parseYaml(cfgRaw); | ||
| if (!cfg) return; |
There was a problem hiding this comment.
If .github/issue-fields.yml contains a non-object value (like a plain string or number), parseYaml will return that value. The check if (!cfg) return; will pass, but the subsequent 'version' in cfg check on line 51 will throw a TypeError: Cannot use 'in' operator to search for 'version' in .... We should strengthen the defensive check to ensure cfg is a plain object and not an array.
const cfg = parseYaml(cfgRaw);
if (!cfg || typeof cfg !== 'object' || Array.isArray(cfg)) {
fail('Configuration must be a YAML object');
return;
}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 5f13eacf97
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| type:task: Task | ||
| type:chore: Task | ||
| type:test: Task |
There was a problem hiding this comment.
For build/* or ci/* PRs, the unified labeler applies type:build from .github/labeler.yml, and derive-project-fields.cjs now only emits a project Type when the label exists in this canonical Type mapping. Because type:build is omitted here, those PRs produce an empty type= and update-project-fields receives a blank Type value, regressing the previous workflow logic that mapped build/* branches to Task. Please include type:build in the canonical mapping so build/CI PRs keep a project Type.
Useful? React with 👍 / 👎.
🔍 Reviewer Summary for PR #433CI Status: ✅ Recommendations
|
🔍 Reviewer Summary for PR #433CI Status: ✅ Recommendations
|
🔍 Reviewer Summary for PR #433CI Status: ✅ Recommendations
|
🔍 Reviewer Summary for PR #433CI Status: ✅ Recommendations
|
1 participant
Summary\n- add canonical .github/issue-fields.yml values and docs/ISSUE-FIELDS.md\n- wire project-meta-sync to derive project fields from canonical config\n- add validate-issue-fields CI check and labeling workflow guardrail\n- backfill metadata governance support with audit artefacts for issues/PRs #300+\n\n## Linked issue\n- Closes #431\n\n## Validation\n- npm run validate:issue-fields\n- npm run validate:workflows\n