Repository navigation
Plugin index stopped regenerating: main rejects direct push #50
Description
Problem
When a plugin changes on main, the plugin index does not update, so index.yaml falls behind the plugins it lists. The Regenerate index.yaml workflow has failed on every run since 9 September. The last success was 1 July.
The workflow commits index.yaml straight to main with GITHUB_TOKEN, and main does not accept direct commits:
- From September to 31 October, branch protection required a pull request:
protected branch 'main' check failed: Changes must be made through a pull request. - Since 2 November, the
required-ciruleset also requires theci / Build and testcheck:Repository rule violations found. Required status check "ci / Build and test" is expected.
The comment at the top of generate-index.yaml still says main is unprotected.
Fix
Have the workflow open or update a pull request with the regenerated index.yaml and arm auto-merge on it, rather than pushing to main. A GITHUB_TOKEN pull request does not trigger CI, so use the org's GitHub App token, or the required check never runs.
Done when
A plugin change on main produces a merged index.yaml update with no manual step.
Activity
0xmc commentedon Nov 3, 2026
#52 takes the fix proposed above. The workflow opens the regenerate pull request with the catalog's GitHub App token and turns on auto-merge, so CI runs on it and it merges once checks pass.
One manual step remains. Every pull request here, bot ones included, waits on an approving review, so each regenerate pull request needs one approval before auto-merge lands it.
Dropping that second review means carrying the regenerated index in the plugin pull request itself, with a drift check that fails when the two disagree. That needs two changes to the
update-plugin-indexaction in datum-cloud/actions:index.yamltoo.index.yamlnext to the manifest when looking for an open update pull request to reuse. Today the action fails the release when that branch touches any other file.Until both ship, a required drift check would fail every release pull request, so #52 keeps the pull request after merge.