@exadev/semantic-release-workspace 3.0.1 → 3.0.2

package/README.md

@@ -76,6 +76,14 @@ Set it via the `--commit-strategy <mode>` CLI flag, the `commitStrategy` field i
 
 `'single'` mode still runs each package's own configured publish plugins afterward (npm publish with provenance, GitHub releases), scoped per package exactly as `'per-package'` mode does — it just runs their `verifyConditions`/`publish`/`success` steps directly against the already-committed-and-tagged repository state, since by that point semantic-release's own top-level orchestrator would misread the tag this mode already created as an existing release. `addChannel` and `fail` are not called in this mode (pre-release channel promotion and posting an automated failure comment/issue, respectively) — a deliberate scope boundary, not a silent gap: raise an issue if your workflow needs them.
 
+### When the release branch moves during a run
+
+Under `commitStrategy: 'per-package'` a release is a sequence of independent pushes, so a commit landing on the release branch mid-run can interrupt it between packages. The orchestrator integrates the new tip and carries on with the packages that have not released yet, and packages already published are never republished, since their tags record them. Where semantic-release declines to release a package while the branch is moving underneath it, which is indistinguishable from that package genuinely having nothing to release, the package is released again against the integrated tip rather than assumed finished; a run that can never establish the answer fails rather than finishing as though the package had nothing, which would leave it and every package after it silently unreleased.
+
+One window is outside this tool's control: semantic-release pushes a package's tag before running its publish plugins, and that push is not atomic, so a rejection there can leave a tag on the remote for a version that never reached npm. Nothing is corrupted and no later release is blocked, but that version number is skipped. If it happens, find the tag with no matching published version (`npm view <name> versions`) and either publish from it by hand or delete the tag locally and on the remote and let the next run recompute it.
+
+If you need a run to be strictly all-or-nothing, use `commitStrategy: 'single'`, which makes one commit and one atomic push before anything publishes, and which retries the whole attempt against the new tip when that push loses a race.
+
 ## Gating publish
 
 `commitStrategy` changes how a release is committed; `gatePublish` changes *when* it gets published relative to being tagged and pushed -- a different, orthogonal axis. With `gatePublish: true`, each due package is tagged and pushed via [@exadev/release-gate](https://www.npmjs.com/package/@exadev/release-gate) (a real dependency of this package -- no separate install needed) but never published: nothing calls `npm publish`, creates a GitHub Release, or runs any other configured publish step, until a separate `resume` step does so explicitly -- from the same process, or a completely different one (a later CI job, once a deploy or smoke test has confirmed the release should actually go out).

package/dist/cli.js

@@ -14,7 +14,7 @@ import { generateNotes } from "@semantic-release/release-notes-generator";
 import semanticRelease from "semantic-release";
 import { pathToFileURL } from "node:url";
 //#region package.json
-var version = "3.0.1";
+var version = "3.0.2";
 //#endregion
 //#region src/errors.ts
 /**
@@ -309,6 +309,14 @@ async function isAncestor(ancestor, descendant, options) {
 		throw error;
 	}
 }
+/** Advances the current branch to `ref`, refusing unless that is a fast-forward. Used where every local commit is already on the remote, so anything that is not a fast-forward means the checkout holds work the remote does not, and stopping is better than the alternative of discarding it. */
+async function fastForwardTo(ref, options) {
+	await git([
+		"merge",
+		"--ff-only",
+		ref
+	], options);
+}
 /** Discards every commit and working-tree change the current attempt made, putting the checkout back on exactly `ref`. */
 async function resetHardTo(ref, options) {
 	await git([
@@ -1333,7 +1341,7 @@ async function runReleaseLoop(graph, order, workspace, dryRun, log, releaseOne)
 		const pkg = mustGet(graph.packages, name, "package");
 		const bumpsForThisPackage = pendingBumps.get(name) ?? [];
 		log(`Releasing ${name} from ${pkg.relativeDirectory}${bumpsForThisPackage.length > 0 ? ` (dependency ranges already bumped: ${bumpsForThisPackage.map((bump) => bump.dependency).join(", ")})` : ""}`);
-		const { released, version, result } = await releaseOne(pkg, bumpsForThisPackage);
+		const { released, version, result } = await releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne);
 		entries.push({
 			name,
 			directory: pkg.directory,
@@ -1430,6 +1438,46 @@ async function bumpDependents(released, version, graph, options) {
 	}
 	return applied;
 }
+/**
+* How many times one package may be re-released after the branch moved underneath its own attempt, before the run gives up loudly.
+*
+* There is no option for this and no derivation from a measured rate, unlike `pushAttempts`, because the shape of the problem is different. Integration happens at most once per package boundary, so the loop is already bounded by the size of the workspace; this only bounds the pathological case where the branch moves during the same package's own attempt over and over. Each round costs one package's analysis, and a branch would have to move during three consecutive attempts at the same package to exhaust it, at which point the run is being starved rather than raced and saying so is more useful than trying again.
+*/
+const MAX_BRANCH_MOVES_PER_PACKAGE = 3;
+/**
+* Brings the checkout up to the release branch's current tip, and reports where that tip is.
+*
+* At a package boundary every commit this run has made is already on the remote (each release commit by `@semantic-release/git`'s own prepare push, each tag by semantic-release's own, each dependency bump by `pushHead`), so advancing onto a moved branch is a fast-forward and loses nothing. `fastForwardTo` refuses anything else rather than discarding local work, which would mean the assumption above had broken.
+*/
+async function integrateBranchTip(workspace, log) {
+	const cwd = workspace.root;
+	const branch = await currentBranch({ cwd });
+	const tip = await fetchBranchTip(branch, { cwd });
+	if (await isAncestor(tip, "HEAD", { cwd })) return tip;
+	if (!await isAncestor("HEAD", tip, { cwd })) throw new WorkspaceStateError(`${packageName}: ${branch} has moved to ${tip}, which this checkout has not and cannot reach by fast-forward, so the two have diverged. A release run expects every commit it has made to already be on the remote at this point; stopping rather than discarding whatever is here.`);
+	await fastForwardTo(tip, { cwd });
+	log(`${packageName}: ${branch} advanced to ${tip} during this run; integrated it before continuing.`);
+	return tip;
+}
+/**
+* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
+*
+* This exists because semantic-release cannot tell the orchestrator the difference between the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
+*
+* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
+*/
+async function releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne) {
+	if (dryRun) return await releaseOne(pkg, bumpsForThisPackage);
+	for (let moves = 0;; moves += 1) {
+		const tipBefore = await integrateBranchTip(workspace, log);
+		const outcome = await releaseOne(pkg, bumpsForThisPackage);
+		if (outcome.released) return outcome;
+		const tipAfter = await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root });
+		if (tipAfter === tipBefore) return outcome;
+		if (moves + 1 >= MAX_BRANCH_MOVES_PER_PACKAGE) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves + 1)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
+		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
+	}
+}
 //#endregion
 //#region src/gate-publish.ts
 /**

package/dist/index.cjs

@@ -316,6 +316,14 @@ async function isAncestor(ancestor, descendant, options) {
 		throw error;
 	}
 }
+/** Advances the current branch to `ref`, refusing unless that is a fast-forward. Used where every local commit is already on the remote, so anything that is not a fast-forward means the checkout holds work the remote does not, and stopping is better than the alternative of discarding it. */
+async function fastForwardTo(ref, options) {
+	await git([
+		"merge",
+		"--ff-only",
+		ref
+	], options);
+}
 /** Discards every commit and working-tree change the current attempt made, putting the checkout back on exactly `ref`. */
 async function resetHardTo(ref, options) {
 	await git([
@@ -1481,7 +1489,7 @@ async function runReleaseLoop(graph, order, workspace, dryRun, log, releaseOne)
 		const pkg = mustGet(graph.packages, name, "package");
 		const bumpsForThisPackage = pendingBumps.get(name) ?? [];
 		log(`Releasing ${name} from ${pkg.relativeDirectory}${bumpsForThisPackage.length > 0 ? ` (dependency ranges already bumped: ${bumpsForThisPackage.map((bump) => bump.dependency).join(", ")})` : ""}`);
-		const { released, version, result } = await releaseOne(pkg, bumpsForThisPackage);
+		const { released, version, result } = await releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne);
 		entries.push({
 			name,
 			directory: pkg.directory,
@@ -1578,6 +1586,46 @@ async function bumpDependents(released, version, graph, options) {
 	}
 	return applied;
 }
+/**
+* How many times one package may be re-released after the branch moved underneath its own attempt, before the run gives up loudly.
+*
+* There is no option for this and no derivation from a measured rate, unlike `pushAttempts`, because the shape of the problem is different. Integration happens at most once per package boundary, so the loop is already bounded by the size of the workspace; this only bounds the pathological case where the branch moves during the same package's own attempt over and over. Each round costs one package's analysis, and a branch would have to move during three consecutive attempts at the same package to exhaust it, at which point the run is being starved rather than raced and saying so is more useful than trying again.
+*/
+const MAX_BRANCH_MOVES_PER_PACKAGE = 3;
+/**
+* Brings the checkout up to the release branch's current tip, and reports where that tip is.
+*
+* At a package boundary every commit this run has made is already on the remote (each release commit by `@semantic-release/git`'s own prepare push, each tag by semantic-release's own, each dependency bump by `pushHead`), so advancing onto a moved branch is a fast-forward and loses nothing. `fastForwardTo` refuses anything else rather than discarding local work, which would mean the assumption above had broken.
+*/
+async function integrateBranchTip(workspace, log) {
+	const cwd = workspace.root;
+	const branch = await currentBranch({ cwd });
+	const tip = await fetchBranchTip(branch, { cwd });
+	if (await isAncestor(tip, "HEAD", { cwd })) return tip;
+	if (!await isAncestor("HEAD", tip, { cwd })) throw new WorkspaceStateError(`${packageName}: ${branch} has moved to ${tip}, which this checkout has not and cannot reach by fast-forward, so the two have diverged. A release run expects every commit it has made to already be on the remote at this point; stopping rather than discarding whatever is here.`);
+	await fastForwardTo(tip, { cwd });
+	log(`${packageName}: ${branch} advanced to ${tip} during this run; integrated it before continuing.`);
+	return tip;
+}
+/**
+* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
+*
+* This exists because semantic-release cannot tell the orchestrator the difference between the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
+*
+* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
+*/
+async function releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne) {
+	if (dryRun) return await releaseOne(pkg, bumpsForThisPackage);
+	for (let moves = 0;; moves += 1) {
+		const tipBefore = await integrateBranchTip(workspace, log);
+		const outcome = await releaseOne(pkg, bumpsForThisPackage);
+		if (outcome.released) return outcome;
+		const tipAfter = await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root });
+		if (tipAfter === tipBefore) return outcome;
+		if (moves + 1 >= MAX_BRANCH_MOVES_PER_PACKAGE) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves + 1)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
+		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
+	}
+}
 //#endregion
 exports.DEFAULT_PUBLISH_PLUGINS = DEFAULT_PUBLISH_PLUGINS;
 exports.DependencyCycleError = DependencyCycleError;

package/dist/index.js

@@ -291,6 +291,14 @@ async function isAncestor(ancestor, descendant, options) {
 		throw error;
 	}
 }
+/** Advances the current branch to `ref`, refusing unless that is a fast-forward. Used where every local commit is already on the remote, so anything that is not a fast-forward means the checkout holds work the remote does not, and stopping is better than the alternative of discarding it. */
+async function fastForwardTo(ref, options) {
+	await git([
+		"merge",
+		"--ff-only",
+		ref
+	], options);
+}
 /** Discards every commit and working-tree change the current attempt made, putting the checkout back on exactly `ref`. */
 async function resetHardTo(ref, options) {
 	await git([
@@ -1456,7 +1464,7 @@ async function runReleaseLoop(graph, order, workspace, dryRun, log, releaseOne)
 		const pkg = mustGet(graph.packages, name, "package");
 		const bumpsForThisPackage = pendingBumps.get(name) ?? [];
 		log(`Releasing ${name} from ${pkg.relativeDirectory}${bumpsForThisPackage.length > 0 ? ` (dependency ranges already bumped: ${bumpsForThisPackage.map((bump) => bump.dependency).join(", ")})` : ""}`);
-		const { released, version, result } = await releaseOne(pkg, bumpsForThisPackage);
+		const { released, version, result } = await releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne);
 		entries.push({
 			name,
 			directory: pkg.directory,
@@ -1553,5 +1561,45 @@ async function bumpDependents(released, version, graph, options) {
 	}
 	return applied;
 }
+/**
+* How many times one package may be re-released after the branch moved underneath its own attempt, before the run gives up loudly.
+*
+* There is no option for this and no derivation from a measured rate, unlike `pushAttempts`, because the shape of the problem is different. Integration happens at most once per package boundary, so the loop is already bounded by the size of the workspace; this only bounds the pathological case where the branch moves during the same package's own attempt over and over. Each round costs one package's analysis, and a branch would have to move during three consecutive attempts at the same package to exhaust it, at which point the run is being starved rather than raced and saying so is more useful than trying again.
+*/
+const MAX_BRANCH_MOVES_PER_PACKAGE = 3;
+/**
+* Brings the checkout up to the release branch's current tip, and reports where that tip is.
+*
+* At a package boundary every commit this run has made is already on the remote (each release commit by `@semantic-release/git`'s own prepare push, each tag by semantic-release's own, each dependency bump by `pushHead`), so advancing onto a moved branch is a fast-forward and loses nothing. `fastForwardTo` refuses anything else rather than discarding local work, which would mean the assumption above had broken.
+*/
+async function integrateBranchTip(workspace, log) {
+	const cwd = workspace.root;
+	const branch = await currentBranch({ cwd });
+	const tip = await fetchBranchTip(branch, { cwd });
+	if (await isAncestor(tip, "HEAD", { cwd })) return tip;
+	if (!await isAncestor("HEAD", tip, { cwd })) throw new WorkspaceStateError(`${packageName}: ${branch} has moved to ${tip}, which this checkout has not and cannot reach by fast-forward, so the two have diverged. A release run expects every commit it has made to already be on the remote at this point; stopping rather than discarding whatever is here.`);
+	await fastForwardTo(tip, { cwd });
+	log(`${packageName}: ${branch} advanced to ${tip} during this run; integrated it before continuing.`);
+	return tip;
+}
+/**
+* Releases one package, integrating the release branch first and again whenever it moves under the attempt.
+*
+* This exists because semantic-release cannot tell the orchestrator the difference between the two reasons it declines to release. When the branch has moved since the run began, its `verifyAuth` fails, `isBranchUpToDate` reports the branch behind, and it returns the same "no release" the orchestrator gets for a package that genuinely had nothing to publish. Taking that at face value is how a run used to finish green having released only the packages that happened to come before the branch moved.
+*
+* The ambiguity is resolved by observation rather than by reading semantic-release's logs: if the branch did not move while the package was being released, "no release" is true. If it did, the answer is not trustworthy, so the branch is integrated and the package is released again against the new tip. That is safe to repeat because a package that really has nothing to release still has nothing after a fast-forward, and a package that does release is recorded by its tag, which every later run reads as the release having happened.
+*/
+async function releasePackageAcrossBranchMoves(name, pkg, bumpsForThisPackage, workspace, dryRun, log, releaseOne) {
+	if (dryRun) return await releaseOne(pkg, bumpsForThisPackage);
+	for (let moves = 0;; moves += 1) {
+		const tipBefore = await integrateBranchTip(workspace, log);
+		const outcome = await releaseOne(pkg, bumpsForThisPackage);
+		if (outcome.released) return outcome;
+		const tipAfter = await fetchBranchTip(await currentBranch({ cwd: workspace.root }), { cwd: workspace.root });
+		if (tipAfter === tipBefore) return outcome;
+		if (moves + 1 >= MAX_BRANCH_MOVES_PER_PACKAGE) throw new WorkspaceStateError(`${packageName}: ${name} reported no release ${String(moves + 1)} times, each time while the release branch was moving underneath it, so whether it had anything to release was never established. Failing rather than finishing the run as though it had nothing, which would leave this package and every one after it silently unreleased. Re-running once the branch is quieter is safe: packages that already released are recorded by their tags and are not released again.`);
+		log(`${name}: reported no release while the branch moved from ${tipBefore} to ${tipAfter}, which is also what a stale branch looks like; integrating and releasing it again.`);
+	}
+}
 //#endregion
 export { DEFAULT_PUBLISH_PLUGINS, DependencyCycleError, GitCommandError, ReleaseConfigurationError, SINGLE_COMMIT_DEFAULT_PUBLISH_PLUGINS, UnsupportedDependencyRangeError, WorkspaceDiscoveryError, WorkspaceReleaseError, WorkspaceStateError, buildDependencyGraph, classifyDependencyRange, createScopedPlugins, discoverWorkspace, filterCommitsToDirectory, orderedPackages, packageName, readManifest, releaseWorkspace, resolvePublishPlugins, resolveWorkspacePublishPlugins, resumeWorkspaceRelease, topologicalOrder, updateDependencyRange, writeDependencyRange };

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@exadev/semantic-release-workspace",
-  "version": "3.0.1",
+  "version": "3.0.2",
   "description": "Independent per-package semantic-release orchestration for pnpm workspaces, without lockstep versioning.",
   "type": "module",
   "repository": {