ci: automated release workflow (semantic-release + OIDC trusted publishing) - #46
Merged
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 configuration and a manual release workflow using a reusable Node setup action. CI workflows now share the action, package tooling includes semantic-release scripts and plugins, and README branding and documentation are updated. ChangesRelease Automation and CI updates
Estimated code review effort: 3 (Moderate) | ~20 minutes Sequence Diagram(s)sequenceDiagram
participant User
participant GitHubActions
participant Checkout
participant SetupNode
participant SemanticRelease
participant Npm
User->>GitHubActions: Trigger release workflow with dry_run input
GitHubActions->>Checkout: Checkout full history and tags
GitHubActions->>SetupNode: Configure Node and run npm ci
GitHubActions->>SemanticRelease: Run semantic-release with optional --dry-run
SemanticRelease->>Npm: Publish package when not dry-running
Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 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
Comment on lines
+14
to
+19
| 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.
Comment on lines
+12
to
+15
| "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.
Suggested change
| "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.
santhoshvai
approved these changes
Jun 11, 2026
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.
Suggested change
| 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.
Suggested change
| 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
Conflict resolutions: - .github/workflows/ios_ci.yml: keep master's Xcode-versioned Pods cache and 'Get Xcode version' step, keep this branch's checkout@v6 + shared ./.github/actions/setup-node composite (which already runs npm ci at the root, so master's separate 'Install node modules' step stays dropped). - package.json: take master's react-native-builder-bob ^0.43.0, keep this branch's semantic-release ^25.0.3. - package-lock.json: regenerated from master's lock plus the new semantic-release devDependencies (398 packages added, 0 removed, 0 version changes).
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 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/ios_ci.yml:
- Line 20: Update the actions/checkout step in the iOS build job to set
persist-credentials to false, ensuring the checkout token is not retained for
subsequent npm, CocoaPods, or Xcode commands. Do not add authenticated Git
operations or other workflow changes.
🪄 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 Plus
Run ID: 2a851afa-2460-44c6-92c5-32fa3c634e39
⛔ Files ignored due to path filters (1)
package-lock.jsonis excluded by!**/package-lock.json
📒 Files selected for processing (4)
.github/workflows/android_ci.yml.github/workflows/ci.yml.github/workflows/ios_ci.ymlpackage.json
🚧 Files skipped from review as they are similar to previous changes (3)
- .github/workflows/ci.yml
- .github/workflows/android_ci.yml
- package.json
| node-version: '22.x' | ||
| cache: 'npm' | ||
| cache-dependency-path: '**/package-lock.json' | ||
| - uses: actions/checkout@v6 |
There was a problem hiding this comment.
🔒 Security & Privacy | 🟠 Major | ⚡ Quick win
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== workflow files =="
git ls-files '.github/workflows/*' | sed -n '1,120p'
echo
echo "== ios_ci.yml with line numbers =="
if [ -f .github/workflows/ios_ci.yml ]; then
nl -ba .github/workflows/ios_ci.yml | sed -n '1,220p'
fi
echo
echo "== checkout persist-credentials/default usage across workflows =="
rg -n --hidden --glob '!node_modules/**' --glob '!dist/**' --glob '!build/**' 'actions/checkout|persist-credentials|permissions:|GITHUB_TOKEN|git ' .github/workflows || true
echo
echo "== local composite actions mentioning checkout/default credentials =="
fd -e yml -e yaml . .github -d 3 -x sh -c 'echo "--- $1"; rg -n "actions/checkout|persist-credentials|permissions|GITHUB_TOKEN|git " "$1" || true' sh {}Repository: GetStream/react-native-webrtc
Length of output: 382
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== ios_ci.yml with awk line numbers =="
awk '{printf "%6d %s\n", NR, $0}' .github/workflows/ios_ci.yml | sed -n '1,240p'
echo
echo "== relevant permissions and checkout usage across workflows =="
python3 - <<'PY'
from pathlib import Path
for p in Path('.github/workflows').glob('*.yml'):
print(f"--- {p} ---")
for i, line in enumerate(p.read_text().splitlines(), 1):
if any(k in line for k in ['permissions:', 'actions/checkout', 'persist-credentials', 'GITHUB_TOKEN', 'git ']):
print(f"{i}: {line}")
PYRepository: GetStream/react-native-webrtc
Length of output: 2912
Disable checkout credential persistence for this build job.
This job only needs read access to check out the repository, but it then runs repository-controlled npm install, pod install, and Xcode build commands. The default persisted checkout token would unnecessarily remain available to those later steps; set persist-credentials: false unless a later step requires authenticated Git operations.
🧰 Tools
🪛 zizmor (1.26.1)
[warning] 20-20: credential persistence through GitHub Actions artifacts (artipacked): does not set persist-credentials: false
(artipacked)
🤖 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/ios_ci.yml at line 20, Update the actions/checkout step in
the iOS build job to set persist-credentials to false, ensuring the checkout
token is not retained for subsequent npm, CocoaPods, or Xcode commands. Do not
add authenticated Git operations or other workflow changes.
Source: Linters/SAST tools
The repo has shipped alphas continuously (the 'alpha' dist-tag currently points at 145.1.0-alpha.1, with 10 published 145.x alphas), but .releaserc.json only defined 'beta'. Add an 'alpha' prerelease branch so that channel keeps working, and allow it through the release workflow's branch guard. Verified via semantic-release's own lib/branches/normalize.js: 'alpha' resolves to channel="alpha" prerelease="alpha", matching the existing dist-tag.
The Release workflow has no channel input; the branch it is dispatched from selects the channel. That was only recorded in the PR description, so document the branch -> version -> dist-tag mapping, the dry_run option, and the Conventional Commits rules in the README.
25.0.8 is the current latest; the declared floor already resolved to it, so this only makes the intent explicit. No transitive changes (lockfile churn is the single range line).
Two fixes to release.yml: - Declaring any scope in 'permissions' sets every undeclared scope to 'none', so GITHUB_TOKEN had issues: none / pull-requests: none. @semantic-release/github runs its 'success' step after publishing and posts a comment, adds the 'released' label, and closes referenced issues -- all issues/PR writes, whose failures it rethrows. Without these scopes the first release would publish to npm, push the tag and release commit, and only then fail the job with 403s. Dry runs cannot catch this: they skip publish/success entirely. - Add a concurrency group so two dispatches cannot both compute the same version and race on the tag, the branch push, and the publish. cancel-in-progress is false on purpose: the tag and release commit are pushed before publish, so cancelling mid-run can leave the repo tagged with nothing on npm.
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
2 participants
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.
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, OIDC + issue/PR token scopes, concurrency group, branch safety guard,npx semantic-release.github/actions/setup-node/action.yml.nvmrc(v24) +npm ci.releaserc.json.github/workflows/{ci,android_ci,ios_ci}.ymlcheckout@v6/setup-java@v5; drop the now-redundant rootnpm install.github/stale.ymlREADME.mdpackage.json/package-lock.jsonsemantic-releasescript + 4 devDependencies, lockfile synced sonpm cisucceedsRelease channels
There is no channel input — the branch you dispatch from selects the channel, via the "Use workflow from" dropdown. Documented in the README's Releasing section.
master145.1.0latestbeta145.1.0-beta.1betaalpha145.1.0-alpha.1alpha<major>.x(e.g.145.x)145.0.1145.xdry_run: truealphais included deliberately: thealphadist-tag currently points at145.1.0-alpha.1and the 145 line has 10 published alphas, so dropping that channel would have been a regression.A branch only appears in the dispatch dropdown once it exists on the remote and contains
release.yml, soalpha/beta/<major>.xneed branching offmasterbefore first use.Configure the npm Trusted Publisher for
@stream-io/react-native-webrtcon npmjs.com (Settings → Trusted Publisher → GitHub Actions → this repo +release.yml). Tokenless OIDC publish fails without it.This must happen before any dispatch, including
dry_run: true—@semantic-release/npmrunsverifyConditionson every invocation, so a dry run without a registered publisher falls back to looking forNPM_TOKENand fails withENONPMTOKEN. That failure reads like a broken release config but is only the missing registry setting.The baseline-tag concern from the original description is resolved:
v145.0.0now exists on the remote and is an ancestor ofmaster, and it matches semantic-release's defaultv${version}tag format.Verification performed
On the merged tree, not just
tsc:npm ci— clean; lockfile stayslockfileVersion: 2with no driftnpm run lint(eslint +tsc --noEmit) — passgit status --porcelainafternpm ci— clean, soci.yml's dirty-tree gate still holds withbob 0.43npm pack --dry-run—lib/present (built byprepareat publish time)--dry-run,--branchesoverride, no publish/push): computes 145.1.0 fromfeat(ios): setEngineAvailability (#53)+ the stereofix:, with correctly rendered release notesalphachannel resolution checked against semantic-release's ownlib/branches/normalize.js→channel="alpha",prerelease="alpha", matching the existing dist-tagnpm version --no-git-tag-versionconfirmed to update all three version fields inpackage-lock.json, so nopackage.json/lock drift after a release commit (the lock is in thegitplugin'sassets)@semantic-release/npm@13.1.5(lib/trusted-publishing/); Node 24 bundles npm 11.16, above the 11.5.1 floor, so nonpm install -g npm@lateststep is neededFixed during review
permissionswas missingissues: write/pull-requests: write. Declaring any scope sets all undeclared scopes tonone, and@semantic-release/github'ssuccessstep comments on / labels / closes released issues and PRs, rethrowing failures. Since7c971e1 feat(ios): … (#53)is in range, the first release would have published to npm, pushed the tag and release commit, created the GitHub Release — and then failed the job with 403s. Dry runs cannot catch this; they skippublish/successentirely.concurrencygroup (cancel-in-progress: false). Two overlapping dispatches would both compute the same version and race on the tag, the branch push, and the publish. Cancellation is deliberately disabled because the tag and release commit are pushed before publish, so a cancelled run can leave the repo tagged with nothing on npm.GITHUB_TOKENnow passed to the Release step (was flagged in the original description).master— resolved conflicts inios_ci.yml(kept master's Xcode-versioned Pods cache + the composite action),package.json(master'sbob ^0.43.0+semantic-release), and regeneratedpackage-lock.json.Known follow-ups (not addressed here)
release*and non-numeric*.xnames that.releaserc.jsondoesn't handle, so a dispatch from e.g.release/145.2produces a green run that publishes nothing.{ "scope": "deps", "release": "patch" }constrains only the scope, sofeat(deps):yields a patch instead of a minor. Adding"type": "chore"would confine it to dependabot-style commits.tools/release.shis still present alongside the new flow.@stream-io/video-react-native-sdk— worth restoring if the removal was unintentional.Lockfile note
The large diff is almost entirely the reshuffling of
lockfileVersion: 2's legacy nesteddependenciesblock. Compared structurally againstmaster's lockfile, the change is 398 packages added, 0 removed, 0 version changes — a pure addition of semantic-release's tree.Summary by CodeRabbit
New Features
Chores
Documentation
@stream-io/react-native-webrtcpackage branding and streamlined related/example project sections.