Add a release-time safety check for silently corrupted versioned install scripts#50
Draft
jnasbyupgrade wants to merge 1 commit into
Draft
Add a release-time safety check for silently corrupted versioned install scripts#50jnasbyupgrade wants to merge 1 commit into
jnasbyupgrade wants to merge 1 commit into
Conversation
…all scripts sql.mk regenerates the current version's sql/cat_tools--<version>.sql.in from sql/cat_tools.sql.in whenever default_version and that source file change, via the $(EXTENSION_VERSION_FILES:.sql=.sql.in) rule (`cp $< $@`). If default_version is ever left pointing at an already-tagged real version rather than the `stable` pseudo-version, a later source edit silently overwrites — and corrupts — that released version's committed install file. Add a new step 1 to RELEASE.md, before the version-bump steps, that has the release manager compare each committed versioned install script's last-touching commit against the git tag for that version, flagging any file touched after its own release as a red flag worth investigating, while noting that a late touch-date can also be a legitimate backfill rather than corruption. Renumber the remaining steps (2-7) and their cross-references accordingly. Checked cat_tools' own history while writing this: default_version has in fact never been the literal string 'stable' in cat_tools.control's git history (it is a real version right now, 0.3.0) — the stable pseudo-version scheme described elsewhere in this doc is still aspirational, not yet implemented. That's outside this change's scope. Also checked both currently-tagged versions (0.2.2, 0.2.3) against this new check: both are clean, no drift found.
|
Important Review skippedAuto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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.
sql.mk regenerates the current version's sql/cat_tools--.sql.in from sql/cat_tools.sql.in whenever default_version and that source file change, via the $(EXTENSION_VERSION_FILES:.sql=.sql.in) rule (
cp $< $@). If default_version is ever left pointing at an already-tagged real version rather than thestablepseudo-version, a later source edit silently overwrites — and corrupts — that released version's committed install file. Add a new step 1 to RELEASE.md, before the version-bump steps, that has the release manager compare each committed versioned install script's last-touching commit against the git tag for that version, flagging any file touched after its own release as a red flag worth investigating, while noting that a late touch-date can also be a legitimate backfill rather than corruption. Renumber the remaining steps (2-7) and their cross-references accordingly.Checked cat_tools' own history while writing this:
default_versionhas in fact never been the literal stringstableincat_tools.control's git history (it's a real version right now,0.3.0) — thestablepseudo-version scheme described elsewhere in this doc is still aspirational, not yet implemented. That's out of scope here; this PR is only the safety-check checklist addition. Also checked both currently-tagged versions (0.2.2,0.2.3) against this new check: both are clean, no drift found.