Fix branch deletion failure when prior PR is merged - #13
Conversation
When `mz_version` input is empty, the workflow now reads level-2 version headings from doc/user/content/releases/_index.md on materialize@main, takes the highest, and compares against the version recorded in the heading of skills/materialize-docs/README.md. It only regenerates when the upstream release is strictly newer, and updates the README heading to the new version after a successful auto-bump. The PR is created non-draft, and explicit `mz_version` invocations still bypass version-checking and leave the README heading alone. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
When the workflow is dispatched on a feature branch via `gh workflow run --ref <branch>`, actions/checkout would otherwise default to that branch's tree. The auto-bump PR then inherits the feature-branch changes (e.g. the workflow file itself). Pin the checkout to the default branch so test runs and production runs both produce auto-bump PRs that contain only generated content. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Branch protection forbids deleting `automated/update-materialize-docs-skill`, so `git push origin --delete` fails on the next run after a PR merges. Instead, reset the branch locally from origin/main and force-push, which overwrites the stale remote ref without needing to delete it. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
def-
left a comment
def-
left a comment
There was a problem hiding this comment.
Most of the changes in this PR seem unrelated to the stated "Fix branch deletion failure when prior PR is merged" title to me, is that intentional? Maybe I'm missing something.
In order to prevent the branch deletion failures couldn't we just use unique branch names or set the repository/user to auto-delete branches of PRs after they are merged?
| git add skills/materialize-docs | ||
| git commit -m "Update materialize-docs skill from materialize@${MZ_REF}" | ||
| git push origin "$BRANCH" | ||
| git push --force origin "$BRANCH" |
There was a problem hiding this comment.
Should always use force-with-lease, otherwise you risk overwriting changes made by someone else
| persist-credentials: false | ||
|
|
||
| - name: Checkout MaterializeInc/materialize @ ${{ inputs.mz_version }} | ||
| - name: Determine target version |
There was a problem hiding this comment.
Seeing this much logic in a github action scares me. Can't this live in a Python script and we just run: that_script.py?
| inputs: | ||
| mz_version: | ||
| description: 'Materialize ref (tag, branch, or commit SHA). Defaults to main.' | ||
| description: 'Materialize ref (tag, branch, or commit SHA). Leave empty to auto-detect the latest release.' |
There was a problem hiding this comment.
It might also be interesting to be able to test-run the docs update before actually having a release out? In my ideal world we would update docs immediately when a PR merges into main, but tag them with the version of Materialize required for this feature.
2 participants
Problem
After a PR on
automated/update-materialize-docs-skillis merged, branch protection prevents deletion of that branch. On the next workflow run, the "Set up branch" step found no open PR and triedgit push origin --delete— which failed withGH013: Cannot delete this branch... push declined due to repository rule violations. Example failure: https://github.com/MaterializeInc/agent-skills/actions/runs/25344850407/job/74311218864Fix
git checkout -B "$BRANCH" origin/main, which resets the local branch from main without touching the remote.git push origin "$BRANCH"togit push --force origin "$BRANCH", which overwrites the stale remote ref without needing to delete it first. Only the workflow writes to this branch, so force-push is safe.Follow-up
After merge, the workflow should be manually re-run (or will trigger on next auto-detect) to regenerate the skill against
v26.22.0.