putitoutthere 0.2.37 → 0.2.38

package/CHANGELOG.md

@@ -16,6 +16,7 @@ are prefixed `**BREAKING**` and link to the matching section in
 
 ### Fixed
 
+- Fixed: the reusable workflow's `Create GitHub Release(s) for new tag(s)` step no longer fails a fully successful publish when another tag in the consumer's repo moves mid-run. The step opened with a blanket, un-forced `git fetch --tags origin`, which made it depend on every tag in the repo — including moving major tags it never uses — so a consumer's promotion automation force-moving its floating `v0` between checkout and this step failed the job with `! [rejected] v0 -> v0 (would clobber existing tag)` after all registries were published and all per-package tags pushed (observed twice in two days on thekevinscott/testing-conventions; timelines in #436). A failed publish job is what consumer automation gates on, so the release was published but never promoted, and the job-level rerun then hard-failed on an empty plan. The fetch is dropped (checkout's `fetch-depth: 0` already fetched every remote tag, and the tags the step iterates were created locally by the engine in the same job), and each tag is now pushed ref-scoped and idempotently (`git push origin "refs/tags/$tag"`) before `gh release create` — which also completes the engine's deliberately warn-only tag push (#407) in the same run instead of hard-failing on it one step later (`tag ... exists locally but has not been pushed`, the 2026-07-08 variant). The step's inputs are now only refs it owns, so concurrent movement of any other tag cannot fail it. See [MIGRATIONS.md](./MIGRATIONS.md#github-release-creation-touches-only-the-releases-own-tags). #436. (verified by: unit/ubuntu-latest)
 - Fixed: `kind = "npm"` `build = "napi"` releases now bake the planned release version into the compiled `.node`. `_matrix.yml` (and its e2e mirror `e2e-fixture-job.yml`) run a `write-crate-version` step on each per-triple napi row before `npm run build`, so `napi build` compiles the addon with the right `CARGO_PKG_VERSION` — matching the maturin `write-version` (#276) and bundled-cli `write-crate-version` (#366) pre-build bumps. Previously napi had no pre-build bump: the synthesized per-platform `package.json` carried `matrix.version`, but the `.node` inside it embedded whatever literal sat in the crate's `Cargo.toml`, so a library re-exposing the Rust core's `version()` through napi reported a version diverging from the published npm package. The bump targets `matrix.path` and runs only when a `Cargo.toml` is colocated there (the napi-rs single-crate default — the shape template-lib and the `js-napi` fixture use), resolving `version.workspace = true` to the workspace root via #428. A multi-mode package (`build = ["napi", "bundled-cli"]`) or one whose napi crate lives elsewhere has no `Cargo.toml` at the package path and is skipped with a `::notice::` — there is no per-napi `crate_path` config to point at a non-colocated crate yet, so that `.node` still embeds its on-disk version. The noarch `main` row is excluded (it compiles no `.node`). See [MIGRATIONS.md](./MIGRATIONS.md#napi-node-embeds-the-release-version). #429. (verified by: unit/ubuntu-latest)
 - Fixed: `putitoutthere`'s pre-build version rewrite now follows Cargo **workspace version inheritance** — a crate that sources its version from `[workspace.package].version` via `version.workspace = true` (the idiomatic polyglot layout: one Rust core wrapped by a PyO3 wheel and a napi addon) is now bumped correctly instead of failing the release. The maturin `write-version` (#276) and npm/pypi bundled-cli `write-crate-version` (#366) steps both rewrote only a literal `[package].version` and threw `Cargo.toml: no [package].version field found` on an inheriting member, because the inherited version lives in a different file — the workspace root — that neither step read. So a release for that layout was blocked, not merely mis-versioned. The rewrite path now resolves the manifest first: a literal `[package].version` is bumped in place byte-for-byte as before, while an inheriting member walks up to the nearest ancestor `[workspace]` `Cargo.toml` and rewrites its `[workspace.package].version`. Unparseable or version-less manifests fall through to the prior literal-only path (`replaceCargoVersion`'s existing error), so single-crate layouts are byte-for-byte unchanged. New `src/find-workspace-root.ts`, `src/replace-workspace-package-version.ts`, and `src/write-resolved-cargo-version.ts`; `write-version.ts` / `write-crate-version.ts` now delegate to the resolver. See [MIGRATIONS.md](./MIGRATIONS.md#version-bump-follows-cargo-workspace-inheritance). #428. (verified by: unit/ubuntu-latest)
 - Fixed: `putitoutthere publish` now writes a package's git tag when that version is already live on the registry but untagged, instead of skipping it silently. The publish loop's already-published branch (`isPublished` → true) returned *before* the tag-creation step, so a version that reached the registry on a half-failed run (the run died after publishing but before tagging — e.g. a cancelled downstream job) was left published-but-untagged and never self-healed: piot derives "last released version" from git tags, so on every later run the package looked unreleased, fell back to `first_version` (already live), skipped again, and stayed stuck forever — while its dependents kept bumping and publishing, opening unflagged version skew. The skip branch now calls a shared, idempotent `ensureTag` (new `src/ensure-tag.ts`; a no-op when the tag already exists, and reused by the normal post-publish tag step), so a stuck package self-heals on its next release run. See [MIGRATIONS.md](./MIGRATIONS.md#publish-path-auto-heal-missing-tags). #407. (verified by: integration, unit/ubuntu-latest)

package/MIGRATIONS.md

@@ -21,6 +21,52 @@ Each section covers five things, in order:
 
 ## Unreleased
 
+### GitHub Release creation touches only the release's own tags
+
+**Summary.** The reusable workflow's `Create GitHub Release(s) for new
+tag(s)` step no longer runs a blanket `git fetch --tags origin`, and now
+pushes each of the release's tags ref-scoped (`git push origin
+"refs/tags/$tag"`, idempotent) before `gh release create`. Previously the
+un-forced fetch coupled the step to the state of **every** tag in the
+consumer's repo: a floating major tag (e.g. `v0`) force-moved mid-run by
+the consumer's own promotion automation failed the publish job with
+`! [rejected] v0 -> v0 (would clobber existing tag)` *after* every
+registry publish and per-package tag push had succeeded — and because
+consumer automation gates promotion on this job's conclusion, the release
+was published but never promoted, with no safe job-level rerun (the
+replayed publish re-plans against the already-pushed tags and hard-fails
+on an empty plan). Observed twice in two days on
+thekevinscott/testing-conventions (#436). The ref-scoped push also
+completes the engine's deliberately warn-only tag push (#407) within the
+same run, closing the second observed variant (`tag ... exists locally
+but has not been pushed`).
+
+**Required changes.** None. The step is workflow-internal; no config,
+input, or consumer-side YAML changes.
+
+**Deprecations removed.** None.
+
+**Behavior changes without code changes.**
+
+- A publish run no longer fails when any tag it does not own (a floating
+  major tag, another run's tags) moves between checkout and Release
+  creation.
+- A per-package tag that the engine created but could not push (its push
+  is warn-only, #407) is now pushed by this step in the same run, so the
+  GitHub Release is cut instead of the job failing one step later.
+- A genuine conflict — the same version tag already on the remote at a
+  *different* commit — still fails loudly at the ref-scoped push. That
+  means two runs released the same version, which the
+  `putitoutthere-release-*` concurrency group exists to prevent.
+
+**Verification.** Land two release-triggering pushes to `main` a few
+minutes apart in a repo whose promotion automation force-moves a floating
+major tag on release success (the thekevinscott/testing-conventions
+shape): the second run's publish job completes green and its GitHub
+Releases exist, where it previously failed at `Create GitHub Release(s)
+for new tag(s)`. On any release run's log, the step shows a per-tag
+`git push origin "refs/tags/<tag>"` and no `git fetch`.
+
 ### napi `.node` embeds the release version
 
 **Summary.** `kind = "npm"` `build = "napi"` releases now rewrite the napi

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "putitoutthere",
-  "version": "0.2.37",
+  "version": "0.2.38",
   "description": "Polyglot release orchestrator for crates.io, PyPI, and npm",
   "license": "MIT",
   "repository": {