Fix prep release and release

[andrew-fleming]

prepare-release

• Change version in package.json with node instead of yarn:
  • Yarn 4 redesigned the version command for a "deferred versioning" workflow. The prior checkout is a shallow clone of the release branch, so yarn can't find main and it results in an error (see failing action)
  • The proposed node script is a simpler approach that edits the json file directly, bypassing yarn's versioning workflow.
• Add pattern to omit suffixes from versioning. Otherwise, the suffix will remain on version bumps

release

• Remove NPM_CONFIG_PROVENANCE: true because it's redundant. The --provenance flag does the same thing
• Add npm token for publishing. npm needs this to verify permissions to publish packages

@0xisk @emnul can you confirm everything is set up on our end so we don't need the npm token? I'll remove the token if so. Also, AFAICT we only need one provenance: either the flag or the env. LMK if I'm missing something and we need both

[coderabbitai]

Important

Review skipped

Auto incremental reviews are disabled on this repository.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Walkthrough

Updates GitHub Actions release workflows to enhance version handling by tolerating prerelease and build suffixes in version strings, and switches npm authentication from provenance-based configuration to token-based authentication using NODE_AUTH_TOKEN.

Changes

Cohort / File(s)	Summary
Release Workflow Version Handling .github/workflows/prepare-release.yml	Replaces manual Yarn workspace version update with Node.js one-liner for contracts/package.json. Introduces VERSION_SUFFIX pattern to capture optional prerelease and build suffixes. Updates all sed substitutions to use extended regex (-Ei) with suffix tolerance. Adds standardized "Bump version to ..." commit message.
Release Workflow Authentication .github/workflows/release.yml	Switches npm authentication from NPM_CONFIG_PROVENANCE configuration to NODE_AUTH_TOKEN environment variable for the "Publish to npm" step.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Prepare-release.yml: Verify VERSION_SUFFIX regex pattern correctly captures all prerelease and build suffix formats; confirm sed substitutions work correctly across contracts/src and docs directories.
• Release.yml: Ensure NODE_AUTH_TOKEN is properly configured in secrets and review implications of removing provenance-based authentication.

Possibly related PRs

• Update contracts package name #309: Modifies the same prepare-release workflow's package version update mechanism to handle different workspace package names.
• fix(gh-actions): release PR requisted changes #284: Updates the same GitHub Actions release workflows (prepare-release.yml and release.yml) with earlier version-handling and npm authentication configuration changes.

Suggested reviewers

• 0xisk

Poem

🐰 Versions hop with suffixes in tow,
Regex patterns help them flow,
Token auth now leads the way,
Provenance bids its fond goodbye today! 🔐

Pre-merge checks and finishing touches

❌ Failed checks (1 inconclusive)

Check name	Status	Explanation	Resolution
Title check	❓ Inconclusive	The title 'Fix prep release and release' is vague and generic, using non-descriptive language that doesn't clearly convey what specific issues are being fixed or what the main changes accomplish.	Consider a more descriptive title that specifies the actual fixes, such as 'Replace Yarn version update with Node script and fix npm publishing' or 'Fix prepare-release and add npm token authentication'.

✅ Passed checks (2 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

📜 Review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b446091 and a610f9d.

📒 Files selected for processing (2)

• .github/workflows/prepare-release.yml (1 hunks)
• .github/workflows/release.yml (1 hunks)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)

• GitHub Check: Run Test Suite
• GitHub Check: semgrep-cloud-platform/scan

🔇 Additional comments (3)

.github/workflows/release.yml (1)

29-34: Version validation may not account for all suffix scenarios.

The strict equality check at line 31 compares the release tag against package.json version. Given that prepare-release.yml now handles prerelease and build suffixes, confirm that:

1. Git tags always include the suffix (e.g., v1.2.3-alpha.1) when a suffix exists in package.json
2. The prepare-release workflow consistently maintains suffixes in package.json while stripping them from other files

If there's any mismatch in how suffixes are handled between these workflows, the validation will fail.

.github/workflows/prepare-release.yml (2)

68-75: LGTM! Node.js JSON approach is more reliable than yarn version.

Direct JSON manipulation is cleaner and avoids the yarn version command issues in shallow clones (as noted in PR objectives). The script correctly preserves package.json formatting with 2-space indentation and trailing newline.

---

81-82: I encountered a repository access issue. Let me analyze the review comment based on the pattern itself and the semver specification context.

The review comment raises a legitimate concern about the VERSION_SUFFIX pattern (-[A-Za-z0-9.]+)?(\+[A-Za-z0-9.]+)?. Let me verify the validity of this concern logically:

Pattern Analysis:

• Pattern requires dots (.) as separators: [A-Za-z0-9.]
• This means formats like 1.2.3-alpha.1 would match ✓
• But formats like 1.2.3-alpha-1 would NOT match (hyphen between "alpha" and "1") ✗
• The semver spec (https://semver.org/) allows hyphens within prerelease identifiers separated by dots

Key finding: The review comment's concern is technically valid. The pattern is indeed more restrictive than the full semver spec because it prohibits consecutive hyphens like alpha-1.

However, without access to the actual codebase to verify:

1. Whether the project actually uses such formats
2. What versions exist in contracts/src/ and docs/
3. Whether the sed replacements on lines 86 and 90 handle this correctly

I cannot definitively confirm if this is a critical issue for this specific project.

---

Actual version formats used by OpenZeppelin projects typically follow 1.2.3-alpha.1 (dot-separated) rather than 1.2.3-alpha-1 (hyphen-separated), which would be matched by the pattern.

The review comment is valid but cannot be fully verified without codebase access. The concern stands as written and remains actionable for the developer.

[emnul]

@andrew-fleming don't we need to remove "private": true in our package.json files?

[andrew-fleming]

don't we need to remove "private": true in our package.json files?

@emnul we're only going to be publishing the contracts/ package and it's removed in that manifest. Good thing you brought this up though, we have to fix the version there

[emnul]

Suggested change

	env:
	NPM_CONFIG_PROVENANCE: true

I don't think this is required since npm automatically generates and publishes provenance attestations for packages that use trusted publishers eg GitHub Actions w/ GitHub-hosted runners. However, I can see how it improves code clarity by making it explicit. Up to you if we should keep it

[andrew-fleming]

You mean either the flag or env, right? Personally, I prefer the flag but no strong opinions. I'm good with it as-is so long as it works haha

[emnul]

I'm pretty sure neither are required if trusted publishing is configured in NPM, but I don't have access so I can't tell if it's been configured by IT or not sooooo if it works right now probably best to leave as is.

[andrew-fleming]

Mmmm yes, you are correct. Agreed, we can improve this in another PR

[emnul]

Good eye on the version change!