Generate and backfill release checksums - #92
Merged
Conversation
This repository has committed a checksums directory since 0.1.0, but the shared release workflow made checksums opt-in and defaulted them off, so every release after adopting it published without one.
0.1.3, 0.1.4 and 0.1.5 never had one; 0.1.13 and 0.1.14 lost theirs when the release workflow stopped generating them. Each is the SHA512 of the gem published to RubyGems, which is the same artifact the release task would have hashed. Verified by recomputing 0.1.12 from its published gem and matching the checksum already committed.
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.
Why
This repository has committed a
checksums/directory since 0.1.0, so consumers can verify a published gem against a hash recorded in source control.That stopped working. Reissue's shared release workflow made checksum generation an opt-in input defaulting to off — deliberately, so repositories adopting the workflow don't start committing a
checksums/directory they never asked for:This repo had asked for it, but adopted the shared workflow (
6f3f3ae, 2026-01-30) without setting the input. So 0.1.13 and 0.1.14 published with no checksum, and nobody noticed because nothing fails.Summary
generate_checksum: trueinrelease.yml, so future releases record one again.All 15 published versions now have a checksum.
How the backfilled values were derived
Each is
Digest::SHA512.file(gem).hexdigestof the gem published to RubyGems — the same artifact and the same computation Bundler'sbuild:checksumtask performs (bundler/gem_helper.rb:105-114), matching the existing files byte for byte at 129 bytes.Rather than assume a fetched gem reproduces the published hash, that was verified against a known-good version first:
0.1.12 was re-fetched from RubyGems and its SHA512 recomputed; it matches the checksum already in the repository. The same procedure produced the five backfills.
Notes
No other input from the shared workflow is needed here:
ruby_versionauto-detects from.tool-versions(4.0.2),working_directorydefaults to., anddry_runis a manual testing flag.reissue/gem.rbalready listschecksumsamong the paths reissue commits, so a newly generated checksum lands in the post-release version-bump PR without further configuration.