Refresh the catalogues on a schedule, and republish when they change

Mondays 05:23 UTC: re-run the ETL cold against the live archives, and if the
output differs by a byte, gate it on the unit suite and a production build,
commit it to main, and dispatch the Pages deploy. If nothing changed, say so
in the run summary and touch nothing.

The gates run inside this workflow because they cannot run after it: a push
made with GITHUB_TOKEN fires no push workflows at all — GitHub's recursion
guard — so an unguarded push would deploy nothing and be checked by nothing.
The same guard is why the deploy and a visible CI record are dispatched
explicitly afterwards; dispatch events do go through where push events do
not. ci.yml gains a workflow_dispatch trigger for exactly that call.

Also corrects pages.yml's claim that configure-pages enables Pages on first
run. It cannot: the action's `enablement` input requires an admin-scoped
token, which GITHUB_TOKEN is not. If the site has never been enabled, the
first deploy fails at that step and the one-time fix is Settings → Pages →
Source: GitHub Actions.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WaySiNst4HhDXBHnMy8p5G

This commit is contained in:

Claude

2026-08-17 14:05:42 +00:00

parent 9a5e41495b

commit 8e55964b14

3 changed files with 96 additions and 1 deletions

									
										.github/workflows/ci.yml
									
		+3
		
												View File
												
				@@ -8,6 +8,9 @@ on:

				  push:

				    branches: [main, develop]

				  pull_request:

				  # For the data-refresh workflow: its bot push to main fires no `push` events (GitHub's

				  # recursion guard), so it dispatches CI here explicitly to put checks on the new commit.

				  workflow_dispatch:

				# A second push to the same branch makes the first run's answer irrelevant.

				concurrency: