[Release] Refresh Maven checksum sidecars after the publication merge - #36
Merged
Conversation
jar --update changes the JVM JAR bytes and the module metadata rewrite changes the .module file, but the staged repository's checksum sidecars still described the pre-merge contents, so a checksum-verifying consumer or a Central upload would reject the merged publication. Recompute the four sidecars for both mutated files; verified with a synthetic staged repository. Found while porting this script to tex-core. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
PR performance and binary-size diff
Baseline: exact PR base Performance
Binary size
Size deltas are deterministic for identical build inputs. Performance deltas compare separate hosted runners and should be treated as directional evidence, not a pass/fail threshold. |
DongyuZhao
added a commit
that referenced
this pull request
Jul 27, 2026
## Summary - The template's embedded `bootstrap-repository.sh` now pins the merge policy: squash-only (`allow_merge_commit=false`, `allow_rebase_merge=false`) with `squash_merge_commit_title=PR_TITLE` + `squash_merge_commit_message=PR_BODY`, so both direct merges and merge-queue commits land as `title (#N)` + PR description. The `PATCH` sits between the default-branch validation and the ruleset upserts, matching the tex-core placement, and the re-run stays idempotent. - Ported from tex-core (nouprax/tex-core#20), the same direction as #36/#37. tex-core changed both its checked-in `scripts/bootstrap-repository.sh` and its template's embedded copy; markdown-core carries the script only as the embedded copy in `docs/repository-setup-template.md`, so this PR touches that one spot. - No CHANGELOG entry: markdown-core's changelog records release changes only (no Unreleased section), matching #36/#37. ## Verification `shellcheck` clean on the extracted embedded script; `audit:repository` and `audit:ci` green. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
DongyuZhao
added a commit
that referenced
this pull request
Jul 28, 2026
…leset downgrades (#65) ## Summary - The template's embedded `bootstrap-repository.sh` now defaults to the mature-repository shape: `RULESET_ENFORCEMENT=active` and `MAIN_ADMIN_BYPASS=false`, so a maintenance re-run with only the required inputs converges on full protection instead of silently re-weakening it. Initial bootstrap of a fresh repository can still opt into `RULESET_ENFORCEMENT=evaluate` explicitly while CI stabilizes, exactly as the migration runbook already does. - `upsert_ruleset` now fails closed when updating an existing ruleset: downgrading enforcement from `active` to `evaluate`/`disabled`, or adding bypass actors beyond the current set, aborts with an explanation unless `ALLOW_PROTECTION_DOWNGRADE=true` is passed deliberately. - A short note after the migration examples documents the new defaults and the override variable. - Ported from tex-core (nouprax/tex-core#70), the same direction as #36/#37/#39. markdown-core carries the bootstrap script only as the embedded copy in `docs/repository-setup-template.md`, so this PR touches that one spot (same as #39). - No CHANGELOG entry: markdown-core's changelog records release changes only, matching #36/#37/#39. ## Verification `shellcheck` clean and `bash -n` on the extracted embedded script; `audit:repository` and `audit:ci` green. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
DongyuZhao
added a commit
that referenced
this pull request
Jul 28, 2026
## Summary - Every `uses:` reference across the five workflows (`ci`, `codeql`, `release`, `release-dry-run`, `pr-metrics-comment`) is now pinned to a full commit SHA with the release version recorded in a trailing comment. A movable major tag lets a tag replacement change the code that CI and release jobs execute without a reviewed diff; the SHA makes the executed bytes part of the reviewed history. - `audit-ci-policy.sh` (run as `audit:ci` in the repository health check) now rejects any workflow action reference that is not a 40-hex commit SHA, so a future workflow edit cannot quietly reintroduce a movable ref. Local `uses: ./…` references stay exempt. - Every SHA↔version pair was verified against the GitHub API (`repos/<action>/commits/<tag>`) before landing; the pins match the ones tex-core reviewed. - Ported from tex-core (nouprax/tex-core#70), the same direction as #36/#37/#39/#65. - No CHANGELOG entry: markdown-core's changelog records release changes only, matching the previous mirrors. ## Verification `audit:ci` green on the pinned tree; negative test confirmed the new check fails with a pointed message when a single ref is reverted to `@v7`. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
DongyuZhao
added a commit
that referenced
this pull request
Jul 28, 2026
## Summary - The repo-managed Python tool venvs now install from hash-locked requirements files (`pip --require-hashes`): `scripts/requirements/clang-format.txt` for the clang-format venv in `init-environment.sh`, and `scripts/requirements/cmakelang.txt` (cmakelang + PyYAML + the transitive six) for the cmake-format venv in `format-cmake.sh`, which is where markdown-core builds that venv. Every distribution PyPI publishes for the pinned versions is enumerated, so an index-side replacement cannot change the bytes the tools run. - `install_emscripten` now pins the emsdk manager itself to `EMSCRIPTEN_COMMIT` — the immutable commit of the `4.0.23` release tag, kept in lockstep with `EMSCRIPTEN_VERSION` — and verifies the checkout, so a moved tag or new default-branch commit can never change the installer bytes it executes. - `audit-ci-policy.sh` (`audit:ci`) now enforces all of this: it fails if `init-environment.sh` loses the emsdk commit pin or `--require-hashes`, or if `format-cmake.sh` loses `--require-hashes`. - Ported from tex-core (nouprax/tex-core#70), the same direction as #36/#37/#39/#65/#66. Adapted where the repos differ: markdown-core installs cmakelang via `format-cmake.sh` rather than inline in `init-environment.sh`, so the requirements file is wired (and audited) there. The emsdk commit was verified against the GitHub API to be the `4.0.23` tag commit. - No CHANGELOG entry: markdown-core's changelog records release changes only, matching the previous mirrors. ## Verification `audit:ci` green with the new checks active; both requirements files installed for real with `--require-hashes` into fresh venvs on macOS arm64 (`cmake-format 0.6.13`, `clang-format 22.1.8`); the modified `format-cmake.sh --check` ran end-to-end against the repo with a fresh tool dir; `shellcheck` reports nothing new on either script. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
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.
merge-maven-publications.mjsmutates two files in the staged repository —jar --updaterewrites the JVM JAR and the Gradle module metadata gets re-hashed — but the Maven checksum sidecars (.md5/.sha1/.sha256/.sha512) next to both files still described the pre-merge bytes. A checksum-verifying consumer, or a Central upload that validates repository checksums, would reject the merged Kotlin publication.The merge now recomputes the four sidecars in place for both mutated files. Verified with a synthetic staged repository (jar + module + sidecars + the macOS payload jar): post-merge, every sidecar matches the mutated bytes, and the existing native-payload assertions still pass.
Found while porting this script to tex-core (nouprax/tex-core#9, where the same fix landed); flagged there by review.
🤖 Generated with Claude Code