PR: Set up GitHub Actions workflows and automation scaffolds #89
Conversation
Add commit-ready workflow scaffolds and automation files: **Workflows:** - quality-gates.yml: Linting, schema validation, and front-matter checks - labeler.yml: Canonical label application for PRs - release-prep.yml: Automated version and changelog prep - collections-indexer.yml: Build and validate collections references - weekly-metrics.yml: Aggregate and commit weekly health reports **Automation:** - Canonical files: labels, repository-categories, repository-names - JSON schemas: frontmatter, version, changelog validation - Scripts: canonical-to-json, validate-frontmatter, validate-version, validate-changelog, build-collections-index **Documentation:** - wordpress/index.md: Domain-specific instructions index - Updated CODEOWNERS with instructions path All scaffolds align with audit specifications and include placeholder implementations for iterative development. No auto-release triggers. Supports systematic quality gates and release automation.
|
Warning Rate limit exceeded@ashleyshaw has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 7 minutes and 41 seconds before requesting another review. ⌛ How to resolve this issue?After the wait time has elapsed, 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 have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📒 Files selected for processing (10)
Note Other AI code review bot(s) detectedCodeRabbit has detected other AI code review bot(s) in this pull request and will avoid duplicating their findings in the review comments. This may lead to a less comprehensive review. Note
|
| Cohort / File(s) | Summary |
|---|---|
Canonical automation data .github/automation/canonical/* .github/automation/canonical/labels.yml, .github/automation/canonical/repository-categories.yml, .github/automation/canonical/repository-names.yml |
Added seed data: canonical labels (area:docs, area:workflows, area:agents, v0.2.0), repository categories (wordpress, community, tooling, data), and a static list of repository names. |
JSON validation schemas .github/automation/schemas/* .github/automation/schemas/changelog.schema.json, .github/automation/schemas/frontmatter.schema.json, .github/automation/schemas/version.schema.json |
Added three JSON Schema files defining changelog, frontmatter, and semantic version validation rules (draft 2020-12). |
GitHub Actions workflows .github/workflows/* .github/workflows/collections-indexer.yml, .github/workflows/labeler.yml, .github/workflows/quality-gates.yml, .github/workflows/release-prep.yml, .github/workflows/weekly-metrics.yml |
Added workflows for collections indexing, PR labeling (scaffold + dry-run), quality gates (linters/validators), weekly release prep, and weekly metrics seeding/commit. |
Validation & utility scripts scripts/* scripts/build-collections-index.ts, scripts/canonical-to-json.js, scripts/validate-changelog.js, scripts/validate-frontmatter.js, scripts/validate-version.js |
Added scripts: TypeScript placeholder for collection indexer, canonical-to-json.js to convert YAML→JSON, and scaffold validators (changelog/frontmatter/version) with TODOs; frontmatter validator sets up Ajv. |
Docs & ownership .github/instructions/wordpress/index.md, CODEOWNERS |
Added WordPress-specific guidance file and CODEOWNERS entry for .github/instructions/ (assigns ownership). |
Sequence Diagram(s)
sequenceDiagram
autonumber
actor "Pull Request" as PR
participant "Labeler Workflow" as Labeler
participant "Repo Files" as Files
participant "GitHub API" as GH
PR->>Labeler: PR opened/updated (develop)
Labeler->>Files: read `.github/automation/canonical/labels.yml`
Labeler->>Labeler: compute label candidates (TODO mapper)
alt dry-run
Labeler->>Labeler: produce summary (no changes applied)
Labeler->>GH: post PR summary (dry-run)
else apply
Labeler->>GH: create/update labels on PR (planned)
Labeler->>GH: add labels
end
sequenceDiagram
autonumber
actor "Pull Request" as PR
participant "Quality Gates Workflow" as Gates
participant "Repo" as Repo
participant "Validator Scripts" as Validators
PR->>Gates: PR to develop / manual
Gates->>Repo: determine changed files
alt YAML changes
Gates->>Validators: run yamllint
end
alt Markdown changes
Gates->>Validators: run markdownlint
end
Gates->>Validators: run actionlint
Gates->>Validators: run canonical-to-json.js
Gates->>Validators: run validate-frontmatter.js / validate-version.js / validate-changelog.js
Gates->>PR: append summary of validation results
Estimated code review effort
🎯 2 (Simple) | ⏱️ ~12 minutes
- Predominantly declarative/configuration additions and scaffold scripts.
- Areas needing extra attention:
scripts/canonical-to-json.js– I/O and YAML→JSON correctness.scripts/validate-frontmatter.js– Ajv integration and actual front-matter extraction (TODOs).- Workflows (
labeler.yml,quality-gates.yml) – ensure permissions, paths, and step commands are correct for intended runners.
Possibly related issues
- [Workflows/Docs] Canonical labels + org seeding workflow #66 — Adds canonical labels and labeler workflow; strongly related to the new
labels.ymland.github/workflows/labeler.yml.
Possibly related PRs
- Move frontmatter schema to subfolder #58 — Related: implements/extends frontmatter validation with Ajv and tests; intersects with
frontmatter.schema.jsonandvalidate-frontmatter.js. - Create New Feature or Component #72 — Related: frontmatter schema location/refs; may overlap with schema files added here.
- Set up GitHub repo documentation and governance #53 — Related: label automation and canonical labels; overlaps with
labels.ymland labeler workflow.
Suggested labels
documentation, status:needs-review, lang:javascript, js, lang:md, test
Suggested reviewers
- krugazul
Pre-merge checks and finishing touches
✅ Passed checks (3 passed)
| Check name | Status | Explanation |
|---|---|---|
| Title check | ✅ Passed | Title accurately summarizes the main change: setting up GitHub Actions workflows and automation scaffolds, which is the core focus of the changeset. |
| Docstring Coverage | ✅ Passed | No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. |
| Description check | ✅ Passed | The PR description comprehensively follows the required template, includes all essential sections with detailed content, and clearly communicates the scope and intent of the changes. |
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.
Comment @coderabbitai help to get the list of available commands and usage tips.
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 13
🧹 Nitpick comments (13)
.github/automation/schemas/version.schema.json (1)
1-7: Consider stricter validation rules.The schema correctly validates semantic versioning format. However, you may want to consider:
- Adding
"additionalProperties": falseto prevent unexpected fields- Refining the pattern to disallow leading zeros:
^(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)$These changes would make the schema more strict and aligned with semantic versioning specifications.
Apply this diff for stricter validation:
{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Version", "type": "object", - "properties": { "version": { "type": "string", "pattern": "^[0-9]+\\.[0-9]+\\.[0-9]+$" } }, - "required": ["version"] + "properties": { + "version": { + "type": "string", + "pattern": "^(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)\\.(0|[1-9][0-9]*)$" + } + }, + "required": ["version"], + "additionalProperties": false }scripts/validate-version.js (1)
1-3: Placeholder validation script needs implementation.This script is currently a placeholder that always exits successfully. The actual validation logic against
version.schema.jsonneeds to be implemented for the quality gates and release prep workflows to function correctly.Would you like me to generate an implementation that reads version files, validates them against the JSON schema, and provides meaningful error messages? This would involve:
- Reading and parsing the version file
- Loading the version.schema.json schema
- Validating using a JSON schema validator (e.g., ajv)
- Providing clear error output for validation failures
Or would you prefer to track this with a GitHub issue?
scripts/build-collections-index.ts (1)
1-3: Script should handle --validate flag referenced in workflow.The
.github/workflows/collections-indexer.ymlworkflow calls this script with a--validateflag, but the current placeholder implementation doesn't handle command-line arguments. This could cause confusion during iterative development.Consider adding basic argument parsing even in the placeholder:
#!/usr/bin/env -S node --loader ts-node/esm // Build collections index and optionally validate references (placeholder) +const validateMode = process.argv.includes('--validate'); -console.log('Collections index built (placeholder).'); +console.log(`Collections index ${validateMode ? 'validated' : 'built'} (placeholder).`);Would you like me to generate a more complete scaffold that:
- Parses command-line arguments properly
- Outlines the structure for building the collections index
- Includes validation logic when --validate is passed
- Provides proper TypeScript types?
scripts/validate-changelog.js (1)
1-3: Add TODO comment and consider exit behavior.The placeholder implementation exits with success regardless of validation state. While this is acceptable for initial scaffolding, consider:
- Adding a TODO comment similar to other scripts in the PR
- Documenting the expected behavior (validate against changelog.schema.json)
- Potentially exiting with a non-zero code or warning to prevent false positives in CI until fully implemented
Apply this diff to clarify intent:
#!/usr/bin/env node -// Validate changelog fragments against changelog.schema.json (placeholder) +// TODO: Validate changelog fragments against changelog.schema.json +console.log('⚠️ Changelog validation not yet implemented - skipping'); process.exit(0);scripts/canonical-to-json.js (1)
2-4: Consider migrating to ES modules.The script uses CommonJS (
require) but the coding guidelines specify: "Prefer ES modules over CommonJS in JavaScript/TypeScript code". While this works for a build script, consider refactoring to use ES modules for consistency with project standards.As per coding guidelines
Example refactor:
-#!/usr/bin/env node -const fs = require('fs'); -const path = require('path'); -const YAML = require('yaml'); +#!/usr/bin/env node +import fs from 'fs'; +import path from 'path'; +import YAML from 'yaml';Note: This requires adding
"type": "module"to package.json or using.mjsextension..github/workflows/release-prep.yml (1)
7-12: Add concurrency control to prevent overlapping runs.Per coding guidelines: "Use the concurrency key to prevent overlapping runs". For a weekly scheduled job, overlapping runs could cause conflicts when creating PRs.
As per coding guidelines
Apply this diff:
jobs: prep: runs-on: ubuntu-latest + concurrency: + group: release-prep + cancel-in-progress: true permissions: contents: writescripts/validate-frontmatter.js (2)
2-5: Consider migrating to ES modules.The script uses CommonJS (
require) but the coding guidelines specify: "Prefer ES modules over CommonJS in JavaScript/TypeScript code". Consider refactoring to use ES modules for consistency with project standards.As per coding guidelines
Example refactor:
-const Ajv = require('ajv'); -const addFormats = require('ajv-formats'); -const fs = require('fs'); -const glob = require('glob'); +import Ajv from 'ajv'; +import addFormats from 'ajv-formats'; +import fs from 'fs'; +import { globSync } from 'glob';Note: This requires adding
"type": "module"to package.json or using.mjsextension.
16-20: Document placeholder implementation.The script initializes an error counter but never increments it, and the validation loop is empty. Consider adding a warning message similar to validate-changelog.js to clarify this is a scaffold.
Apply this diff:
+console.log('⚠️ Front-matter extraction and validation not yet implemented'); + let errors = 0; for (const f of files) { - // Extract and validate front-matter here (placeholder) + // TODO: Extract YAML front-matter from between --- delimiters + // TODO: Validate extracted data against schema + // TODO: Increment errors counter on validation failure } if (errors > 0) process.exit(1);.github/workflows/quality-gates.yml (2)
7-12: Add concurrency control.Per coding guidelines: "Use the concurrency key to prevent overlapping runs" to prevent multiple PR checks from running simultaneously on the same ref.
As per coding guidelines
Apply this diff:
jobs: gates: runs-on: ubuntu-latest + concurrency: + group: quality-gates-${{ github.ref }} + cancel-in-progress: true permissions: contents: read
25-31: Improve changed files detection logic.The condition
contains(steps.changed.outputs.all_modified_files, '.yml')will match any file containing.ymlin its path (e.g.,my.yml.backup,.ymlfile). Use a more precise check.Apply this diff:
- name: yamllint - if: contains(steps.changed.outputs.all_modified_files, '.yml') || contains(steps.changed.outputs.all_modified_files, '.yaml') + if: | + contains(steps.changed.outputs.all_modified_files, '.yml') || + contains(steps.changed.outputs.all_modified_files, '.yaml') run: yamllint .Consider using tj-actions/changed-files' built-in file filtering:
- name: Get changed YAML files id: changed-yaml uses: tj-actions/changed-files@v45 with: files: | **/*.yml **/*.yaml - name: yamllint if: steps.changed-yaml.outputs.any_changed == 'true' run: yamllint ..github/automation/schemas/changelog.schema.json (1)
8-15: Consider restricting additional properties in the schema.The
sectionsobject doesn't explicitly restrict additional properties beyond Added/Changed/Fixed. For a stricter, more maintainable schema, consider adding"additionalProperties": falseto prevent unintended sections from being added in the future.Apply this diff to restrict the schema:
"sections": { "type": "object", "properties": { "Added": { "type": "array", "items": { "type": "string" } }, "Changed": { "type": "array", "items": { "type": "string" } }, "Fixed": { "type": "array", "items": { "type": "string" } } - } + }, + "additionalProperties": false }Consider also adding
"additionalProperties": falseto the root object (after line 16) for consistency..github/workflows/labeler.yml (2)
7-24: Add a smoke-test job to validate workflow functionality.Per coding guidelines, workflows should include a smoke-test job that performs a minimal build or test to verify end-to-end workflow functionality. Currently, the labeler workflow lacks validation of its core operations.
Add a smoke-test job that validates the canonical labels file exists and is valid YAML:
jobs: + smoke-test: + runs-on: ubuntu-latest + permissions: + contents: read + steps: + - uses: actions/checkout@a5ac7e51b41094c7aa3747d998c24a78a1b6aab2 # v4.1.1 + - name: Validate canonical labels file exists + run: test -f .github/automation/canonical/labels.yml || (echo "Canonical labels file not found" && exit 1) + - name: Validate YAML syntax + run: which yq || (echo "yq not found" && exit 1); yq eval . .github/automation/canonical/labels.yml > /dev/null + label: runs-on: ubuntu-latest
19-24: Replace TODO placeholder with actionable implementation or linked issue.Line 23 contains a TODO comment indicating the labeler implementation is incomplete. Either implement the minimal JavaScript mapper now or create a linked GitHub issue to track the completion of this feature.
Would you like me to:
- Generate a starter implementation of the label-mapping logic in JavaScript?
- Help you create a GitHub issue to track this TODO?
📜 Review details
Configuration used: Path: .coderabbit.yml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (18)
.github/automation/canonical/labels.yml(1 hunks).github/automation/canonical/repository-categories.yml(1 hunks).github/automation/canonical/repository-names.yml(1 hunks).github/automation/schemas/changelog.schema.json(1 hunks).github/automation/schemas/frontmatter.schema.json(1 hunks).github/automation/schemas/version.schema.json(1 hunks).github/instructions/wordpress/index.md(1 hunks).github/workflows/collections-indexer.yml(1 hunks).github/workflows/labeler.yml(1 hunks).github/workflows/quality-gates.yml(1 hunks).github/workflows/release-prep.yml(1 hunks).github/workflows/weekly-metrics.yml(1 hunks)CODEOWNERS(1 hunks)scripts/build-collections-index.ts(1 hunks)scripts/canonical-to-json.js(1 hunks)scripts/validate-changelog.js(1 hunks)scripts/validate-frontmatter.js(1 hunks)scripts/validate-version.js(1 hunks)
🧰 Additional context used
📓 Path-based instructions (15)
.github/workflows/**/*.yml
📄 CodeRabbit inference engine (.github/instructions/design-agents.instructions.md)
Integrate agents into GitHub Actions by triggering them in appropriate jobs (e.g., code review agents on pull requests)
CI must run lint, unit, and E2E tests on pull requests
Files:
.github/workflows/release-prep.yml.github/workflows/quality-gates.yml.github/workflows/collections-indexer.yml.github/workflows/weekly-metrics.yml.github/workflows/labeler.yml
.github/workflows/**/*.{yml,yaml}
📄 CodeRabbit inference engine (.github/instructions/playwright-tests.instructions.md)
.github/workflows/**/*.{yml,yaml}: Ensure CI workflow installs dependencies and runs Playwright tests on pull requests and merges
Integrate Playwright into the CI/CD pipeline (e.g., GitHub Actions)
Files:
.github/workflows/release-prep.yml.github/workflows/quality-gates.yml.github/workflows/collections-indexer.yml.github/workflows/weekly-metrics.yml.github/workflows/labeler.yml
{.github/workflows/**/*.yml,**/playwright.config.@(js|ts)}
📄 CodeRabbit inference engine (.github/instructions/testing.instructions.md)
CI should upload artifacts (videos, traces) for failing E2E runs
Files:
.github/workflows/release-prep.yml.github/workflows/quality-gates.yml.github/workflows/collections-indexer.yml.github/workflows/weekly-metrics.yml.github/workflows/labeler.yml
.github/workflows/**/*.@(yml|yaml)
📄 CodeRabbit inference engine (.github/instructions/workflows.instructions.md)
.github/workflows/**/*.@(yml|yaml): Declare explicit permissions in each workflow using the permissions key; default to contents: read and only elevate when necessary
Use the concurrency key to prevent overlapping runs (e.g., concurrency: { group: '', cancel-in-progress: true })
Provide a manual trigger via workflow_dispatch and use clear, descriptive names for jobs and steps
Validate workflow syntax with actionlint locally or in CI
Include a smoke-test job that performs a minimal build or test to verify end-to-end workflow functionality
Files:
.github/workflows/release-prep.yml.github/workflows/quality-gates.yml.github/workflows/collections-indexer.yml.github/workflows/weekly-metrics.yml.github/workflows/labeler.yml
{.github/workflows/**/*.@(yml|yaml),.github/actions/**/action.@(yml|yaml)}
📄 CodeRabbit inference engine (.github/instructions/workflows.instructions.md)
{.github/workflows/**/*.@(yml|yaml),.github/actions/**/action.@(yml|yaml)}: Do not pass secrets to third-party actions; use GitHub encrypted secrets and limit their scope
Cache dependencies deterministically with actions/cache using a key derived from lockfiles (e.g., package-lock.json, composer.lock)
Pin all actions to a full-length commit SHA instead of a mutable tag
Files:
.github/workflows/release-prep.yml.github/workflows/quality-gates.yml.github/workflows/collections-indexer.yml.github/workflows/weekly-metrics.yml.github/workflows/labeler.yml
**/.github/workflows/*.yml
⚙️ CodeRabbit configuration file
**/.github/workflows/*.yml: Review .github workflows for CI/CD:
- Check for use of reusable workflow templates and matrix strategies.
- Validate secrets and environment variables are handled securely.
- Ensure jobs have clear names and steps are well-commented.
- Ensure workflows enforce linting, testing, and release policies.
- Validate required status checks for merges.
- Check for proper branch and path filters.
- Confirm workflows are documented, maintainable, and DRY.
- Check for agent capabilities, tool integration, and test coverage.
- Ensure agent files reference org-wide standards and indexes.
- Ensure workflows run markdownlint, test jobs, and security checks as required.
Files:
.github/workflows/release-prep.yml.github/workflows/quality-gates.yml.github/workflows/collections-indexer.yml.github/workflows/weekly-metrics.yml.github/workflows/labeler.yml
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.github/instructions/blocks.instructions.md)
Use @wordpress/i18n (e.g., import { __, _x, _n, sprintf } from '@wordpress/i18n') for all translatable strings in JavaScript/TypeScript
**/*.{js,jsx,ts,tsx}: Prefer ES modules over CommonJS in JavaScript/TypeScript code
Keep DOM interactions block‑editor–first and avoid jQuery
Use ES6+ features (arrow functions, destructuring, template literals)
Prefer const and let over var
Use async/await for asynchronous operations
Implement proper error handling with try/catch around async code
Use @wordpress/block-editor components when possible
Implement proper block registration and attributes
Use WordPress data stores for state management
Write descriptive function and variable names
Use JSDoc for function documentation
Minimize bundle size with tree shaking (prefer side‑effect‑free ES modules)
Use dynamic imports for code splitting
Use wp.hooks for the WordPress action/filter system
Integrate with the WordPress REST API when needed
Follow WordPress JavaScript coding standards
Files:
scripts/build-collections-index.tsscripts/canonical-to-json.jsscripts/validate-version.jsscripts/validate-changelog.jsscripts/validate-frontmatter.js
**/*.{js,ts,php,css,scss,sass,html,json,md,yml,yaml,py,sh}
📄 CodeRabbit inference engine (.github/instructions/linting.instructions.md)
Apply linting checks to all supported source and config files (JavaScript, TypeScript, PHP, CSS/SCSS/Sass, HTML, JSON, Markdown, YAML, Python, Shell).
Files:
scripts/build-collections-index.tsscripts/canonical-to-json.jsscripts/validate-version.jsscripts/validate-changelog.jsscripts/validate-frontmatter.js
**/*.{php,js,jsx,ts,tsx}
📄 CodeRabbit inference engine (.github/instructions/wordpress.instructions.md)
**/*.{php,js,jsx,ts,tsx}: Use proper text domain 'ai-block-theme-template' for internationalization
Wrap all user-facing strings in translation functions
Files:
scripts/build-collections-index.tsscripts/canonical-to-json.jsscripts/validate-version.jsscripts/validate-changelog.jsscripts/validate-frontmatter.js
**/*.{js,ts}
⚙️ CodeRabbit configuration file
**/*.{js,ts}: Review JavaScript/TypeScript for WordPress block theme:
- Ensure code is linted and follows project style guides.
- Validate use of ES modules or CommonJS as appropriate.
- Check for dead code, unused variables, and clear function naming.
- Ensure minimal JavaScript usage, following block theme best practices.
- Verify scripts enhance, not replace, native WordPress functionality.
- Check for proper script enqueueing in functions.php or block.json.
- Validate accessibility and performance optimizations.
- Ensure compatibility with WordPress script loading patterns.
- Confirm event handling, DOM manipulation, and editor/frontend compatibility.
- Check for code comments, modularity, and maintainability.
- Ensure tests are isolated and do not depend on external state.
- Check for descriptive test names and clear test structure.
Files:
scripts/build-collections-index.tsscripts/canonical-to-json.jsscripts/validate-version.jsscripts/validate-changelog.jsscripts/validate-frontmatter.js
**/*.{php,html,htm,js}
📄 CodeRabbit inference engine (.github/instructions/wpcs.instructions.md)
Apply LightSpeed WordPress Accessibility rules for markup, ARIA, keyboard interactions, and color contrast
Files:
scripts/canonical-to-json.jsscripts/validate-version.jsscripts/validate-changelog.jsscripts/validate-frontmatter.js
**/*.js
📄 CodeRabbit inference engine (.github/instructions/wpcs.instructions.md)
**/*.js: Adhere to LightSpeed WordPress JavaScript style, naming, formatting, and best practices
Use JSDoc for inline documentation and comments in JavaScript
Files:
scripts/canonical-to-json.jsscripts/validate-version.jsscripts/validate-changelog.jsscripts/validate-frontmatter.js
.github/instructions/**/*.md
📄 CodeRabbit inference engine (.github/instructions/playwright-tests.instructions.md)
All instruction files in .github/instructions must follow LightSpeed organizational guidelines
Files:
.github/instructions/wordpress/index.md
.github/**/*.md
📄 CodeRabbit inference engine (.github/instructions/tagging-and-frontmatter-conventions.instructions.md)
.github/**/*.md: Every asset markdown must include a description field (single-sentence preferred)
If deprecated is true, replacement must be provided and point to the successor file
Choose exactly one domain from the approved taxonomy (wp-core, block-theme, plugin-hardening, perf, a11y, i18n, security, headless, generic)
Use stability with value in {stable, experimental, incubating}
tags must have at most 8 items, use lowercase kebab-case, not repeat the chosen domain, and prefer existing tags
Descriptions should be concise (<= 120 characters)
Files:
.github/instructions/wordpress/index.md
.github/**/!(*.instructions).md
📄 CodeRabbit inference engine (.github/instructions/tagging-and-frontmatter-conventions.instructions.md)
All non-instruction markdown assets must include a file_type discriminator
Files:
.github/instructions/wordpress/index.md
🧬 Code graph analysis (1)
scripts/canonical-to-json.js (1)
scripts/validate-frontmatter.js (1)
fs(4-4)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
- GitHub Check: lychee
🔇 Additional comments (7)
CODEOWNERS (1)
29-29: LGTM!The addition of the instructions path ownership follows the established pattern and aligns with the new WordPress-specific guidance being introduced in this PR.
.github/automation/canonical/repository-categories.yml (1)
1-4: LGTM!The canonical repository categories are clearly defined and will provide a solid foundation for the categorization system used by the canonical-to-json conversion script.
.github/automation/canonical/labels.yml (1)
1-13: LGTM!The canonical label definitions are well-structured with clear descriptions and appropriate color coding. The area: namespace provides good organization, and the version label will support release tracking.
.github/instructions/wordpress/index.md (1)
1-4: Add YAML frontmatter with required metadata to align with repository standards.Instruction index files throughout
.github/instructions/include YAML frontmatter withtitle,description,version,last_updated, andowners. The WordPress index currently lacks this structure. Update it to match the established pattern:--- title: "WordPress Instructions Index" description: "Index of WordPress-specific development guidance and standards for LightSpeed projects." version: "v1.0" last_updated: "2025-10-24" owners: ["LightSpeed Engineering"] --- # Instructions (WordPress Domain) - **Scope:** domain - **Owners:** Docs - **Note:** WordPress-only guidance lives here; root stays community-only.github/automation/canonical/repository-names.yml (1)
1-6: LGTM!The repository names list is well-structured and will be correctly parsed by the canonical-to-json.js script.
.github/automation/schemas/frontmatter.schema.json (1)
1-14: LGTM!The JSON Schema is well-structured and follows JSON Schema Draft 2020-12 standards. The validation rules are appropriate for front-matter metadata.
.github/workflows/labeler.yml (1)
15-18: Verify or ensureyqis available and add error handling.The workflow uses
yqon line 18 without explicit installation. Whileyqis typically available onubuntu-latest, it's safer to either verify its presence or include an explicit installation step. Additionally, add error handling to catch failures in the yq command.Apply this diff to add a verification step before using yq:
- uses: actions/checkout@a5ac7e51b41094c7aa3747d998c24a78a1b6aab2 # v4.1.1 + - name: Verify yq is available + run: which yq || (echo "yq not found" && exit 1) - name: Load canonical labels id: labels - run: | - echo "labels=$(yq -o=json .github/automation/canonical/labels.yml)" >> $GITHUB_OUTPUT + run: | + labels=$(yq -o=json .github/automation/canonical/labels.yml) || exit 1 + echo "labels=$labels" >> $GITHUB_OUTPUT
| index: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
Pin action to commit SHA instead of tag.
The workflow uses actions/checkout@v4 which is a mutable tag. Per coding guidelines: "Pin all actions to a full-length commit SHA instead of a mutable tag" for security and reproducibility.
As per coding guidelines
Find the commit SHA for actions/checkout v4:
Then update:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@<COMMIT_SHA> # v4🏁 Script executed:
#!/bin/bash
# Get the latest commit SHA for actions/checkout v4
gh api repos/actions/checkout/git/refs/tags/v4 --jq '.object.sha'Length of output: 40
🏁 Script executed:
#!/bin/bash
# Inspect the workflow file to verify all issues
cat .github/workflows/collections-indexer.ymlLength of output: 455
Pin action to commit SHA and address critical workflow configuration issues.
The workflow uses actions/checkout@v4 (a mutable tag) and is missing required configuration per coding guidelines:
- Pin action to commit SHA: Replace
@v4with@08eba0b27e820071cde6df949e0beb9ba4906955for security and reproducibility - Add explicit permissions: Declare
permissions:at workflow level (default tocontents: read) - Add concurrency control: Prevent overlapping runs using the
concurrency:key - Setup Node.js: Add
actions/setup-nodestep before running TypeScript—running.tsfiles directly withnoderequires transpilation or a TypeScript runtime
name: Collections Indexer
on:
pull_request:
branches: [ develop ]
paths:
- ".github/collections/**"
- ".github/{prompts,chatmodes,instructions}/**"
workflow_dispatch:
+permissions:
+ contents: read
+
+concurrency:
+ group: collections-indexer
+ cancel-in-progress: true
+
jobs:
index:
runs-on: ubuntu-latest
steps:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 # v4
+ - uses: actions/setup-node@<COMMIT_SHA> # v4
+ with:
+ node-version: '18' # adjust per your requirementsCommittable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
.github/workflows/collections-indexer.yml around line 14: replace the mutable
actions/checkout@v4 with the pinned commit SHA
@08eba0b27e820071cde6df949e0beb9ba4906955; add a workflow-level permissions
block (at minimum permissions: contents: read); add a concurrency: key to
prevent overlapping runs (e.g., concurrency with a unique group and
cancel-in-progress); and ensure a setup step for Node.js (add an
actions/setup-node step before executing TypeScript or transpile .ts to .js) so
TypeScript is run correctly.
| name: Labeler | ||
| on: | ||
| pull_request: | ||
| types: [opened, synchronize, reopened] | ||
| branches: [ develop ] |
There was a problem hiding this comment.
Add missing workflow triggers and concurrency control.
The workflow is missing essential GitHub Actions best practices per coding guidelines: no workflow_dispatch trigger for manual runs, and no concurrency key to prevent overlapping executions. Additionally, the workflow references inputs.dry_run on line 21, but no inputs section is defined.
Apply this diff to add the missing elements:
name: Labeler
on:
pull_request:
types: [opened, synchronize, reopened]
branches: [ develop ]
+ workflow_dispatch:
+ inputs:
+ dry_run:
+ description: "Run in dry-run mode"
+ required: false
+ default: "false"
+ type: string
+
+concurrency:
+ group: labeler-${{ github.ref }}
+ cancel-in-progress: true📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| name: Labeler | |
| on: | |
| pull_request: | |
| types: [opened, synchronize, reopened] | |
| branches: [ develop ] | |
| name: Labeler | |
| on: | |
| pull_request: | |
| types: [opened, synchronize, reopened] | |
| branches: [ develop ] | |
| workflow_dispatch: | |
| inputs: | |
| dry_run: | |
| description: "Run in dry-run mode" | |
| required: false | |
| default: "false" | |
| type: string | |
| concurrency: | |
| group: labeler-${{ github.ref }} | |
| cancel-in-progress: true |
🤖 Prompt for AI Agents
.github/workflows/labeler.yml lines 1-5: the workflow lacks a manual trigger,
concurrency control, and an inputs definition for inputs.dry_run referenced
later; update the top-level "on:" to include workflow_dispatch (with an
inputs.dry_run boolean default), and add a "concurrency:" key (e.g., group:
labeler-${{ github.ref }} and cancel-in-progress: true) to prevent overlapping
runs so the referenced inputs.dry_run exists and simultaneous executions are
avoided.
| pull-requests: write | ||
| contents: read | ||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
Pin action to a full commit SHA instead of mutable tag.
Per coding guidelines, all actions must be pinned to a full-length commit SHA instead of mutable tags (e.g., v4). This ensures reproducibility and prevents unexpected changes if the tag is updated.
Apply this diff to pin the action:
- - uses: actions/checkout@v4
+ - uses: actions/checkout@a5ac7e51b41094c7aa3747d998c24a78a1b6aab2 # v4.1.1Verify the exact commit SHA for the version you intend to use by checking the GitHub Actions checkout repository releases.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| - uses: actions/checkout@v4 | |
| - uses: actions/checkout@a5ac7e51b41094c7aa3747d998c24a78a1b6aab2 # v4.1.1 |
🤖 Prompt for AI Agents
.github/workflows/labeler.yml lines 14-14: the checkout action is pinned to a
mutable tag (`actions/checkout@v4`); replace that tag with the full commit SHA
for the exact release you want to lock to (find and copy the full 40-character
commit SHA from the actions/checkout GitHub releases page), update the workflow
to use `actions/checkout@<full-sha>` and commit the change so the workflow is
pinned to that specific commit.
| permissions: | ||
| contents: read | ||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
🧩 Analysis chain
Pin action to commit SHA instead of tag.
Per coding guidelines: "Pin all actions to a full-length commit SHA instead of a mutable tag" for security and reproducibility.
As per coding guidelines
Find commit SHAs for the actions:
🏁 Script executed:
#!/bin/bash
# Get commit SHAs for actions used in this workflow
echo "actions/checkout v4:"
gh api repos/actions/checkout/git/refs/tags/v4 --jq '.object.sha'
echo "actions/setup-node v4:"
gh api repos/actions/setup-node/git/refs/tags/v4 --jq '.object.sha'
echo "tj-actions/changed-files v45:"
gh api repos/tj-actions/changed-files/git/refs/tags/v45 --jq '.object.sha'Length of output: 196
Pin all actions to full-length commit SHAs for reproducibility and security.
Replace mutable tags with commit SHAs:
- Line 13:
actions/checkout@08eba0b27e820071cde6df949e0beb9ba4906955 - Line 15:
actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 - Line 27:
tj-actions/changed-files@48d8f15b2aaa3d255ca5af3eba4870f807ce6b3c
Per coding guidelines, all actions must be pinned to full-length commit SHAs instead of mutable tags.
| name: Weekly Metrics | ||
| on: | ||
| schedule: [ { cron: "0 7 * * 1" } ] | ||
| workflow_dispatch: | ||
|
|
||
| jobs: | ||
| metrics: | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: write | ||
| steps: |
There was a problem hiding this comment.
Add concurrency control to prevent overlapping runs.
The workflow lacks a concurrency key, which could lead to race conditions if multiple runs execute simultaneously (e.g., manual dispatch during scheduled run).
As per coding guidelines: "Use the concurrency key to prevent overlapping runs."
Apply this diff to add concurrency control:
name: Weekly Metrics
on:
schedule: [ { cron: "0 7 * * 1" } ]
workflow_dispatch:
+concurrency:
+ group: weekly-metrics
+ cancel-in-progress: false
+
jobs:
metrics:
runs-on: ubuntu-latest📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| name: Weekly Metrics | |
| on: | |
| schedule: [ { cron: "0 7 * * 1" } ] | |
| workflow_dispatch: | |
| jobs: | |
| metrics: | |
| runs-on: ubuntu-latest | |
| permissions: | |
| contents: write | |
| steps: | |
| name: Weekly Metrics | |
| on: | |
| schedule: [ { cron: "0 7 * * 1" } ] | |
| workflow_dispatch: | |
| concurrency: | |
| group: weekly-metrics | |
| cancel-in-progress: false | |
| jobs: | |
| metrics: | |
| runs-on: ubuntu-latest | |
| permissions: | |
| contents: write | |
| steps: |
🤖 Prompt for AI Agents
.github/workflows/weekly-metrics.yml lines 1-11: the workflow is missing a
concurrency setting which can allow overlapping runs; add a top-level
concurrency block (directly under the name or on keys) with a stable group name
(e.g., "weekly-metrics-${{ github.ref }}") and cancel-in-progress: true to
ensure a new run cancels any in-progress run and prevents overlaps; update the
YAML accordingly so concurrency is configured for the whole workflow.
| permissions: | ||
| contents: write | ||
| steps: | ||
| - uses: actions/checkout@v4 |
There was a problem hiding this comment.
Pin action to full-length commit SHA.
The action reference uses a mutable tag @v4 instead of a pinned commit SHA.
As per coding guidelines: "Pin all actions to a full-length commit SHA instead of a mutable tag."
What is the current commit SHA for actions/checkout@v4?
🤖 Prompt for AI Agents
.github/workflows/weekly-metrics.yml lines 12-12: the workflow pins the action
using a mutable tag `actions/checkout@v4`; replace it with the full-length
commit SHA for that tag to make the action immutable. Find the current commit
SHA for the v4 tag by visiting the actions/checkout GitHub repo, locating the v4
tag/release and copying its full 40-character commit SHA, then update the
workflow to `uses: actions/checkout@<full-commit-sha>` and commit the change.
ashleyshaw
changed the title
ashleyshaw
requested review from
Copilot
and removed request for
eleshar and
krugazul
There was a problem hiding this comment.
Pull Request Overview
This PR establishes the foundational automation infrastructure for the repository, introducing GitHub Actions workflows for quality assurance, labeling, release management, and metrics collection. The changes add five workflow files, three JSON schemas for validation, four automation scripts, and canonical data files for labels and repository metadata. While the scaffolds provide a solid framework aligned with the audit specifications, most scripts are placeholder implementations requiring further development before the automation becomes fully functional.
Key Changes:
- Quality gates workflow with linting, schema validation, and front-matter checks
- Automated PR labeling system using canonical label definitions
- Release preparation and weekly metrics workflows for systematic version management and health reporting
Reviewed Changes
Copilot reviewed 18 out of 18 changed files in this pull request and generated 25 comments.
Show a summary per file
| File | Description |
|---|---|
.github/workflows/quality-gates.yml |
Comprehensive CI validation including yamllint, markdownlint, actionlint, and custom schema validators |
.github/workflows/labeler.yml |
Automated PR labeling based on canonical labels with dry-run support |
.github/workflows/release-prep.yml |
Scheduled workflow for version bumping and changelog generation |
.github/workflows/weekly-metrics.yml |
Automated weekly health reports with git commit capability |
.github/workflows/collections-indexer.yml |
Build and validation for collections references |
.github/automation/canonical/labels.yml |
Canonical label definitions for area classification and versioning |
.github/automation/canonical/repository-categories.yml |
Repository category taxonomy |
.github/automation/canonical/repository-names.yml |
Approved repository name list |
.github/automation/schemas/changelog.schema.json |
JSON schema for changelog validation following Keep a Changelog format |
.github/automation/schemas/frontmatter.schema.json |
JSON schema for markdown front-matter validation |
.github/automation/schemas/version.schema.json |
JSON schema for semantic version validation |
.github/instructions/wordpress/index.md |
WordPress domain-specific instruction index |
scripts/build-collections-index.ts |
TypeScript placeholder for collections indexing |
scripts/canonical-to-json.js |
YAML to JSON converter for canonical data files |
scripts/validate-frontmatter.js |
AJV-based front-matter validator (incomplete implementation) |
scripts/validate-version.js |
Version file validator placeholder |
scripts/validate-changelog.js |
Changelog validator placeholder |
CODEOWNERS |
Added instructions path ownership |
Comments suppressed due to low confidence (1)
scripts/validate-frontmatter.js:20
- The condition 'errors > 0' is always false.
if (errors > 0) process.exit(1);
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| echo "labels=$(yq -o=json .github/automation/canonical/labels.yml)" >> $GITHUB_OUTPUT | ||
| - name: Apply labels (dry-run supported) | ||
| env: | ||
| DRY_RUN: ${{ inputs.dry_run || 'false' }} |
There was a problem hiding this comment.
The DRY_RUN environment variable is read from inputs.dry_run, but the workflow doesn't define any workflow inputs. The workflow_dispatch trigger should include an inputs section to define this parameter. Without it, inputs.dry_run will always be empty and default to 'false'.
| { | ||
| "$schema": "https://json-schema.org/draft/2020-12/schema", | ||
| "title": "Changelog", | ||
| "type": "object", | ||
| "properties": { | ||
| "version": { "type": "string" }, | ||
| "date": { "type": "string", "format": "date" }, |
There was a problem hiding this comment.
Missing required additionalProperties field in the schema. The pattern should be "additionalProperties": false to enforce strict validation, or explicitly set it to true with documentation explaining why additional properties are allowed. This aligns with JSON Schema best practices for explicit property control.
| - name: actionlint | ||
| run: actionlint | ||
|
|
||
| - name: Build canonicals JSON |
There was a problem hiding this comment.
The .markdownlint.jsonc config file is referenced but is not included in this PR. The markdownlint step will fail if this configuration file doesn't exist in the repository. Either include the config file in this PR or use the default markdownlint configuration by removing the --config flag.
scripts/validate-frontmatter.js
Outdated
| const files = glob.sync('**/*.md', { ignore: ['node_modules/**'] }); | ||
|
|
||
| let errors = 0; | ||
| for (const f of files) { | ||
| // Extract and validate front-matter here (placeholder) | ||
| } | ||
| if (errors > 0) process.exit(1); |
There was a problem hiding this comment.
The validation logic is incomplete - the errors variable is initialized but never incremented when validation fails. The script will always exit with code 0 (success) even if there are validation errors. Add proper error accumulation: if (!validate(frontmatter)) { console.error(f, validate.errors); errors++; }
scripts/validate-frontmatter.js
Outdated
| const files = glob.sync('**/*.md', { ignore: ['node_modules/**'] }); | ||
|
|
||
| let errors = 0; | ||
| for (const f of files) { |
There was a problem hiding this comment.
Unused variable f.
| for (const f of files) { | |
| for (const _ of files) { |
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: Copilot <[email protected]> Signed-off-by: Ash Shaw <[email protected]>
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: Ash Shaw <[email protected]>
ashleyshaw
deleted the
claude/scaffold-github-workflows-011CV5ZbC47wBxTymxvUwGqQ
branch
name: "Pull Request"
about: "General changes, refactors, and maintenance"
title: "PR: Set up GitHub Actions workflows and automation scaffolds"
labels: ["status:needs-review"]
General Pull Request
This PR adds foundational workflow scaffolds, automation scripts, and configuration files to standardize quality gates, labelling, release preparation, and documentation for the repository. The introduced structures follow LightSpeedWP's governance and automation guidelines and provide extensible placeholders for iterative expansion.
Workflows:
quality-gates.yml: Runs markdown/yaml linting, validates schema for changelogs, versions, and frontmatter, and ensures general CI quality on PRs.labeler.yml: Prepares for canonical label application to PRs using org-defined label configuration.release-prep.yml: Schedules and prepares automated next-version and changelog updates (manual trigger or cron).collections-indexer.yml: Indexes and validates collections, prompts, chatmodes, and instructions changes.weekly-metrics.yml: Aggregates and commits seed health reports weekly.Automation & Configuration:
labels.yml,repository-categories.yml,repository-names.ymlunder.github/automation/canonical/.frontmatter,version, andchangelogformats, supporting automated PR checks.canonical-to-json.js,validate-frontmatter.js,validate-version.js,validate-changelog.js, and a seed TypeScript script for building collection indexes.Documentation & Ownership:
instructions/wordpress/index.md.CODEOWNERSto cover automation and instructions directories for better review coverage.All implementations are initial scaffolds—no destructive changes, auto-merge, or release actions are enabled. All automation is preparatory and may be tested safely in isolation.
Linked issues
Closes #
Changelog
Added
quality-gates.yml,labeler.yml,release-prep.yml,collections-indexer.yml,weekly-metrics.yml.github/automation/canonical/labels.yml,repository-categories.yml,repository-names.yml.github/automation/schemas/changelog.schema.json,frontmatter.schema.json,version.schema.jsonfor changelog/frontmatter/version validationscripts/canonical-to-json.js,scripts/validate-frontmatter.js,scripts/validate-version.js,scripts/validate-changelog.js,scripts/build-collections-index.ts.github/instructions/wordpress/index.mdfor WP-specific processCODEOWNERSto cover new automation, config, and documentation pathsChanged
CODEOWNERSto include automation and instructions for better reviewer coverageFixed
Removed
Risk Assessment
Risk Level: Low
Potential Impact:
Mitigation Steps:
How to Test
Prerequisites
developTest Steps
Expected Results
Edge Cases to Verify
Checklist (Global DoD / PR)
References
Summary by CodeRabbit
New Features
Documentation
Chores