The weekly job cannot commit to git, so it publishes the index instead - #13
Merged
Conversation
…nstead `weekly-sweep.sh` ended by committing `published-runs.json` and pushing. That step could never have worked: `Dockerfile.sweep` ships binaries and scripts, not a checkout, so there is no file to commit into and no push credentials — the job would have failed every week on its last step. Giving an unattended weekly job write access to the source repository, to record a hash, is also a worse trade than typing one command afterwards. So `publish-run.sh` now uploads `runs/index.json` to the bucket, which is what `heartbeat` verifies and what anyone can fetch, and the git commit is a documented human step taken when the week's report is written. Git remains where a hash becomes EVIDENCE — a value in a commit predating any dispute — and a divergence between the bucket and git is visible to anyone comparing them, which is the property that actually matters. One more bug found by thinking about the container: with no local index, `publish-run.sh` started from an empty list, so the upload would have REPLACED the published history with a single entry. Every earlier run would have vanished from the machine-readable index while the archives themselves stayed fine — a silent, confusing loss. It now seeds from the bucket first and appends. Verified: re-publishing an existing run leaves the index byte-identical, and running with no local index at all seeds from the bucket and still ends with all four runs rather than one.
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
1 participant
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.
Two bugs that would have bitten on the first scheduled run.
1. The git step could never have worked.
weekly-sweep.shended by committingpublished-runs.jsonand pushing.Dockerfile.sweepships binaries and scripts, not a checkout — there is no file to commit into and no push credentials. The job would have failed on its last step every week.Giving an unattended weekly job write access to the source repository, to record a hash, is also a worse trade than typing one command afterwards.
publish-run.shnow uploadsruns/index.jsonto the bucket — whatheartbeatverifies and what anyone can fetch — and the commit is a documented human step taken when the week's report is written. Git remains where a hash becomes evidence, and a divergence between bucket and git is visible to anyone comparing them.2. With no local index, the upload would have wiped the history.
publish-run.shstarted from an empty list whenpublished-runs.jsonwas absent, which is exactly the container's situation. The bucket index would have been replaced with a single entry, silently losing every earlier run from the machine-readable index while the archives themselves stayed fine. It now seeds from the bucket first, then appends.Verified