feat(ci): sync GitVersion schema to SchemaStore on new schema releases - #5018
Conversation
There was a problem hiding this comment.
Pull request overview
This PR introduces a new GitHub Actions workflow to automate opening a PR against SchemaStore/schemastore when GitVersion publishes a new JSON schema version, addressing the manual update process described in #5017.
Changes:
- Adds
.github/workflows/schemastore.ymlto detect newly-added schema versions and open a SchemaStore PR viagh+jq. - Supports both automatic triggering (intended on
gh-pagesschema updates) and manual reruns viaworkflow_dispatchwith aversioninput.
… error in homebrew.yml - schemastore.yml: pass github context/inputs through env vars instead of interpolating them directly into the run block (Sonar S7630). - homebrew.yml: remove a stray `--fork-org gittools` line missing its line continuation, which broke the brew bump-formula-pr command and tripped shellcheck SC2215.
gh-pages has no .github/workflows directory, so a push-based trigger on that branch would never fire — GitHub Actions resolves branch-scoped event filters using the workflow file as it exists on the pushed ref. Switch to workflow_run keyed off docs.yml completing, which is evaluated from the default branch. Detect the new version by diffing HEAD~1..HEAD on gh-pages instead of the push event's before/after SHAs.
|
Good catches, thanks — both fixed in 91fa2c3:
|
Revert the workflow_run approach: docs.yml's PublishDocs task now copies schemastore.yml into the gh-pages commit it publishes, so the branch actually has the workflow file GitHub needs to resolve a push-triggered event on gh-pages itself. Also widen checkout to fetch-depth: 0 so the before/after diff is always valid, regardless of how many commits a gh-pages push contains.
|
Update: reverted to a pure To make the push trigger actually work, |
|
|
Thank you @arturcic for your contribution! |
Summary
Adds
.github/workflows/schemastore.yml, which automates opening a PR against SchemaStore/schemastore whenever a new GitVersion schema version is published, per #5017.How it works
gh-pagesthat touchschemas/**(i.e. right afterdocs.ymlpublishes docs and the generated schema for the release), orworkflow_dispatchwith aversioninput for manual re-runs.before/afterongh-pagesfor newly addedschemas/*/GitVersion.configuration.jsonfiles and derives the version from the folder name. If nothing new was added (e.g. a patch release with no new schema), the job no-ops. On manual trigger, the providedversioninput is used directly instead.gittools/cicd/github-creds(same mechanism ashomebrew.ymluses for opening PRs againsthomebrew-core) for both pushing to the GitTools/schemastore fork and opening the PR against the upstream repo. A GitHub App token was considered (as used ingittools-actions.yml), but App installation tokens are scoped to repos the app is installed on and can't open a PR againstSchemaStore/schemastore, which GitTools doesn't control — so a single PAT-based identity (like homebrew.yml) is the correct fit here.gh repo syncbrings theGitTools/schemastorefork'smasterup to date with upstream.gitversion-schema-<version>.jqto bump the GitVersion entry'surl, add the newversionsmap entry insrc/api/json/catalog.json, and update the$refinsrc/schemas/json/gitversion.json— matching SchemaStore/schemastore#5485.gh pr create --repo SchemaStore/schemastore.Test plan
actionlintpasses on the new workflow (verified locally).workflow_dispatchwith a real historical version (e.g.6.7) against a test fork to confirm thejqedits and PR creation work end-to-end, since this can't be exercised from a local sandbox (needsOP_SERVICE_ACCOUNT_TOKENand push access toGitTools/schemastore).