Repository navigation
fix(ci): commit scraper proposals before opening a PR - #49
Merged
Merged
Conversation
When the source branch (chore/release-notes-scout or chore/pgdg-cve-scrape) does not exist on origin, peter-evans/create-pull-request stashes the uncommitted proposed-*.json, sees 0 commits ahead of base, and silently logs "Branch is not ahead of base and will not be created". The stash is never popped, the proposed file is discarded, and the workflow is marked success. No PR is opened. This bites every scheduled run after the source branch is deleted. Both source branches were manually cleaned on Sep 9-10 after PRs #42 and #45 merged; the Sep 15, 22, and 29 release-notes-scout runs all hit this path and surfaced 20 real bug proposals each time but opened no PR. data/known_bugs.json has not been refreshed since Sep 7 even though PostgreSQL 15.18/15.19, 16.15, 17.11, and 18.6 release notes have accumulated. Add a Commit proposed * step that runs after the scraper and before peter-evans. It commits the untracked proposed file with the github-actions[bot] identity, so the source branch is non-empty in both the "branch exists" and "branch missing" paths. The peter-evans add-paths and commit-message inputs remain as a belt-and-suspenders for the "branch exists" path. Reproduction and root-cause notes from the Sep 29 run: 01:29:12.202Z git stash push --include-untracked 01:29:12.219Z git fetch origin chore/release-notes-scout 01:29:12.459Z fatal: couldn't find remote ref chore/release-notes-scout 01:29:12.469Z Branch is not ahead of base 'main' and will not be created
PR Summary by QodoCommit scraper proposals before creating pull requests
AI Description
Diagram
High-Level Assessment
Files changed (2)
|
randoneering
added a commit
that referenced
this pull request
Oct 4, 2026
Both scraper workflows have been silently no-oping since PR #45 merged on Sep 9. The proposed-bugs.json and proposed-cves.json files are tracked in the repo, last touched by the scrapers' own commits. Each subsequent scout/scrape run finds the same proposals and writes the same content to the same tracked file. Net diff is zero, so the workflow 'succeeds' but produces no PR and discards nothing — the file just sits there. This bit both the original peter-evans silent-failure path (PR #49 was supposed to fix this) and the new commit-step path I just added. Both paths hinge on there being a real diff to push; with a tracked file holding the exact same JSON the scout produces, there is never a diff. The PR template body for the scraper PRs already says 'Delete proposed-bugs.json before merge' — these are supposed to be transient staging files, not data. Fix: 1. git rm --cached proposed-bugs.json proposed-cves.json 2. Add both to .gitignore so the runner sees them as untracked-and-ignored 3. Switch the workflow's 'git add' to 'git add -f' so the bot can still force-add them despite the ignore After this lands, the scout will write to a truly untracked file, 'git add -f' will stage it, the commit will land, and peter-evans will have a real diff to push. Verified locally: - pytest tools/tests/ + testing/test_workflow_security.py → 65 passed - git status --ignored shows both files under 'Ignored files' - 'git ls-files | grep proposed' returns empty after the rm Verified in CI via workflow_dispatch on the fix branch: - Scout run exits 1, file written, 'git add -f' stages, 'git commit' succeeds, peter-evans opens PR. Repro from failed run 37175188174 (after the first attempted fix): 03:50:17.111Z scout exit code: 1 03:50:17.124Z nothing to commit, working tree clean 03:50:17.125Z ##[error]Process completed with exit code 1.
1 of 6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Pull Request Summary
The two weekly scraper workflows have been failing silently since Sep 9. They run every Monday, exit green, but no PR ever lands. The bug is in how peter-evans/create-pull-request handles the case where the source branch is gone from origin: it stashes the uncommitted proposal, sees zero commits ahead of base, and walks away. No error, no warning, just nothing.
Both source branches got cleaned up by hand on Sep 9 and 10 after PRs #42 and #45 merged. Since then,
release-notes-scouthas been finding 20 real bug proposals every week and throwing them away.data/known_bugs.jsonhasn't been touched since Sep 7 even though PG 15.18, 15.19, 16.15, 17.11, and 18.6 release notes have piled up since.This PR fixes it by committing the proposal file before peter-evans runs, so the source branch is non-empty in both the "branch exists" and "branch missing" paths.
Type of Change
Related Issues
No GitHub issue filed. Follows from PR #45, which was the last successful scraper run.
Testing
Ran locally before opening:
uv run pytest -q tools/tests/→ 55 passed (covers both scraper scripts and their HTML fixtures)uv run pytest -q testing/test_workflow_security.py→ 10 passed (covers the workflow-security regression suite)yaml.safe_load; both jobs now have 7 steps (was 6)git rev-list --right-only --count main..HEADreturns1after the commit, proving the source branch is no longer emptyPostgreSQL Version Compatibility
N/A. This PR only edits GitHub Actions YAML. No SQL, no Python runtime change.
Managed Database Platforms
N/A. Same reason.
Additional Notes
Why peter-evans silently fails
From the Sep 29 run logs:
The action stashes uncommitted work, fails to find the source branch, creates a new branch at HEAD, runs
git rev-list --right-only --count main...branch, sees0, and bails. The stash never gets popped, the proposal file gets discarded, and the run is marked success because no command exited non-zero.Fix shape
- name: Run scraper (CI mode) ... if [ $rc -eq 1 ]; then echo "needs_pr=true" >> "$GITHUB_OUTPUT" echo "$PROPOSED" > proposed-cves.json ... + - name: Commit proposed additions + if: steps.scrape.outputs.needs_pr == 'true' + run: | + git config user.name "github-actions[bot]" + git config user.email "41898282+github-actions[bot]@users.noreply.github.com" + git add proposed-cves.json + git commit -m "chore: scrape PGDG for new CVEs" + - name: Open PR with proposed additions if: steps.scrape.outputs.needs_pr == 'true'Same shape in
release-notes-scout.ymlforproposed-bugs.jsonwith commit messagechore: scout release notes for new bug fixes. The peter-evansadd-pathsandcommit-messageinputs stay as-is for the existing-branch path.Follow-up after merge
I held off on triggering
workflow_dispatchuntil this lands. After merge, dispatchingrelease-notes-scout.ymlshould open a PR with the 20 accumulated proposals so they can get curated intodata/known_bugs.json.