Weekly harvest workflow that opens a pull request #9

Activity

1. larnsce

   self-assigned this

   on Jul 8, 2026
2. larnsce commented on Jul 18, 2026

   

   larnsce

   on Jul 18, 2026 – with Claude

   ContributorAuthor

   More actions

   Premortem findings for this issue (advisory, non-blocking)

   From the 2026-07-18 premortem (report in docs/ on branch claude/implementation-premortem-jd5udn):

   The gate is schema tests, and schema tests assert names, types, and non-emptiness, never values. NA is a valid entry, so a run that half-parses several packages into blank DOIs and wrong tiers passes the gate, commits to main, and publishes to the site. The failure-surfacing path (auto-opened harvest-failure issues) only works if a human sees the issue; in a repo with one part-time maintainer that is not guaranteed, and the org PAT for the registry sync expires silently.

   Suggestions:

   • Add content-level checks to the gate: fail or at least alert on week-over-week increases in problems-tibble rows, NA rates in doi, tier, or description columns, and unexplained tier changes.
   • Route harvest failures to a channel a human actually reads (an email step, or GitHub notification settings verified for the harvest-failure label), and treat a harvest-failure issue that is open more than 14 days with only bot comments as its own alarm.
   • Put the PAT expiry date on a calendar, or replace the PAT with a GitHub App installation token.
   • After the sync step, assert the registry repo's packages.json equals the harvester's copy; a non-empty diff for more than a week means the sync is broken.

   ---

   Generated by Claude Code
3. larnsce

   changed the title [-]Automate the weekly harvest[/-] [+]Weekly harvest workflow that opens a pull request[/+] on Sep 4, 2026
4. larnsce

   added a commit that references this issue on Sep 9, 2026

   Merge pull request #19 from openwashdata/harvest-core

   ...

   9920f94
5. larnsce

   closed this as completedin #19on Sep 9, 2026
6. larnsce commented on Sep 9, 2026

   

   larnsce

   on Sep 9, 2026

   ContributorAuthor

   More actions

   First workflow_dispatch run after the merge: run 34355264180.

   Everything the issue specifies worked, except one organisation setting.

   What passed

   • The harvest ran on the runner against the GitHub backend
   • roxygen2::roxygenise() regenerated the documentation
   • testthat::test_local(stop_on_failure = TRUE) passed as the gate, inside the job, which is where it has to run because a pull request opened with the built-in token triggers no pull_request workflows
   • The harvest branch was pushed, one commit ahead of main, touching only DESCRIPTION, R/sysdata.rda and data-raw/harvest_report.md
   • main was not touched. It is still the merge commit of Parsers, harvest, catalog and the weekly workflow (#3, #4, #5, #6, #9) #19. That is the change this issue asked for over the original workflow, which pushed generated data straight to main

   What failed

   ##[error]GitHub Actions is not permitted to create or approve pull requests.
   

   The organisation does not allow Actions to open pull requests. The workflow declares pull-requests: write and the repository default is write, but the organisation switch overrides both.

   Fix, which needs an organisation owner: Settings, Actions, General, Workflow permissions, tick Allow GitHub Actions to create and approve pull requests. Then re-run the workflow; the branch it needs is already pushed.

   A note on the diff

   The run harvested the same data that was committed three hours earlier, so the expectation was "no changes". The branch is one commit ahead anyway, because the version bump and the harvest report changed. inst/extdata/ is absent from the diff, meaning the three CSVs are byte identical and the catalogue itself did not move. The change detection is behaving as designed: it bumps on a real difference in the generated files, not on a re-run alone.