ci: automated release workflow (semantic-release + OIDC trusted publishing)#46
ci: automated release workflow (semantic-release + OIDC trusted publishing)#46oliverlaz wants to merge 6 commits into
Conversation
Adds a workflow_dispatch-triggered release job that uses semantic-release to publish the package to npm via tokenless Trusted Publishing (OIDC), with automatic provenance. Supports stable (master), beta (prerelease branch), and <major>.x maintenance releases, plus a dry-run mode. - .github/workflows/release.yml: dispatch release job (OIDC, dry-run) - .github/actions/setup-node: composite npm + Node-from-.nvmrc setup - .releaserc.json: semantic-release branches and plugin pipeline - package.json: semantic-release script + devDependencies (lockfile synced)
📝 WalkthroughWalkthroughAdds semantic-release config and a manual Release workflow that uses a new reusable Node setup composite action; updates package.json for semantic-release, switches CI workflows to the local setup action, and updates README badges and install instructions. ChangesRelease Automation and CI updates
Sequence DiagramsequenceDiagram
participant User
participant GitHub as GitHub Actions
participant Checkout as actions/checkout@v6
participant SetupNodeAction as ./.github/actions/setup-node
participant SemanticRelease as semantic-release
participant GitRepo as Git repository
participant NPM as npm registry
User->>GitHub: Trigger workflow_dispatch (dry_run?)
GitHub->>Checkout: Checkout full history & tags
GitHub->>SetupNodeAction: Run setup-node composite action
SetupNodeAction->>SetupNodeAction: Set Node from .nvmrc and npm ci
GitHub->>SemanticRelease: Run npx semantic-release (--dry-run optional)
SemanticRelease->>GitRepo: Update CHANGELOG and package manifests
SemanticRelease->>NPM: Publish package
SemanticRelease->>GitRepo: Create GitHub release
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ 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 |
semantic-release reads GITHUB_TOKEN/GH_TOKEN from the environment to create the GitHub Release and push the changelog/version commit; Actions does not populate it automatically.
- android_ci / ci / ios_ci: use ./.github/actions/setup-node (Node from .nvmrc) instead of inline setup-node@v4 pinned to 22.x; bump actions/checkout to v6 and actions/setup-java to v5 - remove .github/stale.yml
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (2)
.github/workflows/release.yml (1)
21-24: 💤 Low valueConsider pinning actions/checkout to a commit SHA.
Line 22 uses
actions/checkout@v6(tag-based reference). The static analysis tool flags this as unpinned, suggesting commit SHA pinning for supply-chain security (e.g.,actions/checkout@<sha256>). While major-version tags are common practice, SHA pinning provides stronger immutability guarantees.🔐 Pinning example (fetch current SHA)
#!/bin/bash # Get the current SHA for actions/checkout@v6 gh api repos/actions/checkout/git/ref/tags/v6 --jq '.object.sha' 2>/dev/null || \ gh api repos/actions/checkout/commits/v6 --jq '.sha' 2>/dev/null || \ echo "Run: gh api repos/actions/checkout/git/matching-refs/tags/v6"Note: The
persist-credentialswarning is a false positive here—semantic-release requires credentials to push the release commit.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.github/workflows/release.yml around lines 21 - 24, The workflow uses the tag-based action reference "actions/checkout@v6" under the step named "Checkout"; switch this to a pinned commit SHA for supply-chain security by replacing the tag reference with the corresponding full commit SHA for actions/checkout v6 (obtain the SHA via the GitHub API or gh CLI) so the step uses an immutable reference instead of `@v6`.Source: Linters/SAST tools
package.json (1)
3-3: ⚖️ Poor tradeoffBaseline tag setup required before first semantic-release run.
The current version
145.0.0-alpha.8indicates the package is mid-development. Semantic-release needs a baseline tag (e.g.,v145.0.0) pushed to the repository before the first workflow run to correctly detect the current version and generate the next release. Without it, semantic-release may fail or produce an incorrect version bump.Pre-release checklist:
- Decide on the baseline version (e.g.,
145.0.0)- Create and push the tag:
git tag v145.0.0 && git push origin v145.0.0- Update
package.jsonversion to match if needed- Run workflow in dry-run mode first to verify
This aligns with the PR objectives' "Create/push a baseline tag" requirement.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@package.json` at line 3, The repo is missing a baseline git tag for semantic-release given the package.json "version" field set to "145.0.0-alpha.8"; create and push a baseline tag that matches the stable version (e.g., git tag v145.0.0 && git push origin v145.0.0), ensure the package.json "version" value aligns with that baseline if required, and run the semantic-release workflow in dry-run mode first to verify detection and bumping behavior before enabling full releases.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.github/workflows/release.yml:
- Around line 14-19: The branch guard in the package_release job is too
permissive because the conditional uses endsWith(github.ref_name, '.x'); update
the check to only allow numeric maintenance branches that match semantic-release
(e.g., patterns like 1.x or 1.0.x) by replacing the simple endsWith check with a
precise regex test against github.ref_name (or add a validation step in the job
that rejects non-numeric .x branches), and ensure this aligns with the branch
rules defined in .releaserc.json so only branches matching the numeric
maintenance pattern are permitted to run the release.
In @.releaserc.json:
- Around line 12-15: The releaseRules entry for scope "deps" currently overrides
type-based versioning (so commits like feat(deps): ... would be downgraded to
patch); update the releaseRules array to either narrow the rule by adding an
explicit "type" constraint (for example add "type":"chore" alongside
"scope":"deps" and "release":"patch") or remove/replace the scope-only rule and
add a comment/documentation explaining the intended behavior; target the
"releaseRules" array and the rule object with "scope":"deps" when making this
change.
---
Nitpick comments:
In @.github/workflows/release.yml:
- Around line 21-24: The workflow uses the tag-based action reference
"actions/checkout@v6" under the step named "Checkout"; switch this to a pinned
commit SHA for supply-chain security by replacing the tag reference with the
corresponding full commit SHA for actions/checkout v6 (obtain the SHA via the
GitHub API or gh CLI) so the step uses an immutable reference instead of `@v6`.
In `@package.json`:
- Line 3: The repo is missing a baseline git tag for semantic-release given the
package.json "version" field set to "145.0.0-alpha.8"; create and push a
baseline tag that matches the stable version (e.g., git tag v145.0.0 && git push
origin v145.0.0), ensure the package.json "version" value aligns with that
baseline if required, and run the semantic-release workflow in dry-run mode
first to verify detection and bumping behavior before enabling full releases.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: b1400ce8-d1ab-4b05-bc80-9d98d186570a
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
.github/actions/setup-node/action.yml.github/workflows/release.yml.releaserc.jsonpackage.json
| jobs: | ||
| package_release: | ||
| name: Release from "${{ github.ref_name }}" branch | ||
| runs-on: ubuntu-latest | ||
| # GH does not allow limiting branches in workflow_dispatch settings, so guard here. | ||
| if: ${{ inputs.dry_run || github.ref_name == 'master' || github.ref_name == 'beta' || startsWith(github.ref_name, 'release') || endsWith(github.ref_name, '.x') }} |
There was a problem hiding this comment.
Branch guard is more permissive than semantic-release configuration.
Line 19 uses endsWith(github.ref_name, '.x'), which would allow branches like test.x or foo.x. However, .releaserc.json Line 3 expects numeric maintenance branches (1.x, 2.x, 1.0.x). This mismatch could allow releases from unintended branches.
🔒 Proposed fix to align with semantic-release branch patterns
- if: ${{ inputs.dry_run || github.ref_name == 'master' || github.ref_name == 'beta' || startsWith(github.ref_name, 'release') || endsWith(github.ref_name, '.x') }}
+ if: ${{ inputs.dry_run || github.ref_name == 'master' || github.ref_name == 'beta' || startsWith(github.ref_name, 'release/') || contains(github.ref_name, '.x') && contains(github.ref_name, fromJSON('[0-9]')) }}Or use a more precise regex check by adding a validation step before the release.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.github/workflows/release.yml around lines 14 - 19, The branch guard in the
package_release job is too permissive because the conditional uses
endsWith(github.ref_name, '.x'); update the check to only allow numeric
maintenance branches that match semantic-release (e.g., patterns like 1.x or
1.0.x) by replacing the simple endsWith check with a precise regex test against
github.ref_name (or add a validation step in the job that rejects non-numeric .x
branches), and ensure this aligns with the branch rules defined in
.releaserc.json so only branches matching the numeric maintenance pattern are
permitted to run the release.
| "releaseRules": [ | ||
| { "type": "refactor", "release": "patch" }, | ||
| { "scope": "deps", "release": "patch" } | ||
| ] |
There was a problem hiding this comment.
The deps scope rule may override type-based versioning.
Line 14 matches any commit with scope deps regardless of type. This means feat(deps): add feature would trigger a patch release instead of minor, potentially violating semver expectations. Consider adding a type constraint or documenting this intentional override.
📝 Alternative configuration if type-based versioning should be preserved
"releaseRules": [
{ "type": "refactor", "release": "patch" },
- { "scope": "deps", "release": "patch" }
+ { "type": "chore", "scope": "deps", "release": "patch" }
]Or document the current behavior if intentional.
📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| "releaseRules": [ | |
| { "type": "refactor", "release": "patch" }, | |
| { "scope": "deps", "release": "patch" } | |
| ] | |
| "releaseRules": [ | |
| { "type": "refactor", "release": "patch" }, | |
| { "type": "chore", "scope": "deps", "release": "patch" } | |
| ] |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In @.releaserc.json around lines 12 - 15, The releaseRules entry for scope
"deps" currently overrides type-based versioning (so commits like feat(deps):
... would be downgraded to patch); update the releaseRules array to either
narrow the rule by adding an explicit "type" constraint (for example add
"type":"chore" alongside "scope":"deps" and "release":"patch") or remove/replace
the scope-only rule and add a comment/documentation explaining the intended
behavior; target the "releaseRules" array and the rule object with
"scope":"deps" when making this change.
The shared ./.github/actions/setup-node action already runs `npm ci`, so the extra root-level `npm install` in ci/android_ci/ios_ci was a no-op. The example-app installs (examples/GumTestApp/) are kept.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@README.md`:
- Line 37: Update the phrase "Real Time Communication" in README.md to the
hyphenated compound adjective "Real‑Time Communication" wherever it modifies
"Communication" (e.g., the sentence containing "provides a number of packages
which are more than useful when developing Real Time Communication
applications"); replace the unhyphenated occurrence with "Real-Time
Communication" to correct grammar.
- Line 32: The README contains the incorrect phrase "much more broader"; update
that sentence to use a correct comparative such as "much broader" or "a more
comprehensive example with backend included" to remove the double comparative.
Locate the sentence in README.md and replace "much more broader example with
backend included" with one of the suggested alternatives so the grammar is
corrected.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 04f66d05-f064-464b-82da-48fa33f241df
📒 Files selected for processing (6)
.github/stale.yml.github/workflows/android_ci.yml.github/workflows/ci.yml.github/workflows/ios_ci.yml.github/workflows/release.ymlREADME.md
💤 Files with no reviewable changes (1)
- .github/stale.yml
🚧 Files skipped from review as they are similar to previous changes (1)
- .github/workflows/release.yml
| ## Picture-in-Picture (PIP) | ||
|
|
||
| This package does not include a built-in PIP implementation. PIP support is available via [`@stream-io/video-react-native-sdk`](https://github.com/GetStream/stream-video-js). | ||
| Don't worry, there are plans to include a much more broader example with backend included. |
There was a problem hiding this comment.
Fix grammatical error: "much more broader" is incorrect.
The phrase "much more broader" uses a double comparative, which is grammatically incorrect. It should be either "much broader" or "a more comprehensive".
📝 Proposed fix
-Don't worry, there are plans to include a much more broader example with backend included.
+Don't worry, there are plans to include a much broader example with backend included.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| Don't worry, there are plans to include a much more broader example with backend included. | |
| Don't worry, there are plans to include a much broader example with backend included. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` at line 32, The README contains the incorrect phrase "much more
broader"; update that sentence to use a correct comparative such as "much
broader" or "a more comprehensive example with backend included" to remove the
double comparative. Locate the sentence in README.md and replace "much more
broader example with backend included" with one of the suggested alternatives so
the grammar is corrected.
|
|
||
| Looking for extra functionality coverage? | ||
| The [react-native-webrtc](https://github.com/react-native-webrtc) organization provides a number of packages which are more than useful when developing Real Time Communication applications. | ||
| The [react-native-webrtc](https://github.com/react-native-webrtc) organization provides a number of packages which are more than useful when developing Real Time Communication applications. |
There was a problem hiding this comment.
Add hyphen to compound adjective "Real Time Communication".
When "Real Time" modifies "Communication" as a compound adjective, it should be hyphenated as "Real-Time Communication" for correct English grammar.
📝 Proposed fix
-The [react-native-webrtc](https://github.com/react-native-webrtc) organization provides a number of packages which are more than useful when developing Real Time Communication applications.
+The [react-native-webrtc](https://github.com/react-native-webrtc) organization provides a number of packages which are more than useful when developing Real-Time Communication applications.📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| The [react-native-webrtc](https://github.com/react-native-webrtc) organization provides a number of packages which are more than useful when developing Real Time Communication applications. | |
| The [react-native-webrtc](https://github.com/react-native-webrtc) organization provides a number of packages which are more than useful when developing Real-Time Communication applications. |
🧰 Tools
🪛 LanguageTool
[uncategorized] ~37-~37: If this is a compound adjective that modifies the following noun, use a hyphen.
Context: ...ch are more than useful when developing Real Time Communication applications.
(EN_COMPOUND_ADJECTIVE_INTERNAL)
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@README.md` at line 37, Update the phrase "Real Time Communication" in
README.md to the hyphenated compound adjective "Real‑Time Communication"
wherever it modifies "Communication" (e.g., the sentence containing "provides a
number of packages which are more than useful when developing Real Time
Communication applications"); replace the unhyphenated occurrence with
"Real-Time Communication" to correct grammar.
Source: Linters/SAST tools
2 participants
What
Adds an automated,
workflow_dispatch-triggered release for@stream-io/react-native-webrtc, modeled onstream-chat-js'srelease.yml. Uses semantic-release for version computation, changelog, git tag, and GitHub Release, and publishes to npm via tokenless Trusted Publishing (OIDC) with automatic provenance.Replaces the manual flow (
tools/release.sh+ hand-runnpm publish).Files
.github/workflows/release.ymldry_runinput,id-token: write(OIDC), branch safety guard,npx semantic-release.github/actions/setup-node/action.yml.nvmrc(v24) +npm ci.releaserc.jsonpackage.jsonsemantic-releasescript + 4 devDependenciespackage-lock.jsonnpm cisucceedsRelease modes
master→latestdist-tagbetabranch →betadist-tag (e.g.145.1.0-beta.1)<major>.xmaintenance branches (e.g.137.x), selectable in the dispatch UIdry_run: true→semantic-release --dry-run(no publish/tag/push)@stream-io/react-native-webrtcon npmjs.com (Settings → Trusted Publisher → GitHub Actions → this repo +release.yml). Tokenless OIDC publish fails without it.v137.xbut the package is on the145.xline. Create/push av145.0.0tag (or do the first 145 release the old way) so semantic-release continues from the right line.feat:/fix:/BREAKING CHANGE:).GITHUB_TOKENnot passed to the Release step. semantic-release's@semantic-release/github(and thegitpush) readGITHUB_TOKEN/GH_TOKENfrom the env, which Actions does not auto-populate. As written, the GitHub Release/commit step will likely fail with "no GitHub token specified". Recommend adding to theReleasestep:masteris branch-protected, use a bot PAT instead so the release commit can be pushed.)npm install -g npm@lateststep before release.Lockfile note
package-lock.jsongrows by ~408 transitive packages (semantic-release's tree). Only 2 existing deps change — incidental patch bumps (cross-spawn7.0.3→7.0.6,graceful-fs4.2.9→4.2.10). The large deleted-line count is reshuffling of lockfileVersion-2's legacy nesteddependenciesblock, not real dependency changes.Test
Merge, then run the workflow from the Actions tab with
dry_run: trueonmasterto confirm the computed version + release notes without publishing.Summary by CodeRabbit
New Features
Chores
Documentation