ci: add canary publish workflow using npm Trusted Publisher (OIDC) - #2285
Merged
Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughNew GitHub Actions workflow to publish npm packages in two modes: automatic canary on pushes to master and manual PR prerelease via workflow_dispatch, with version manipulation, selective package publishing, build steps, and optional Discord notifications. Changes
Sequence Diagram(s)sequenceDiagram
participant Runner as Actions Runner
participant Repo as Git Repo
participant Registry as npm Registry
participant Discord as Discord Webhook
Runner->>Repo: checkout + read workflow inputs (mode, pr, packages, build)
Runner->>Runner: install deps, run builds (packages in order)
alt mode = canary
loop per package
Runner->>Repo: read package.json version
Runner->>Registry: check if package@version exists
alt exists
Runner-->>Runner: skip publish
else
Runner->>Registry: publish package@version with tag "canary"
end
end
else mode = pr
Runner->>Repo: read base version
Runner->>Repo: compute prerelease version (BASE-pr${PR}.${BUILD}) and overwrite package.json
loop per package
Runner->>Registry: publish prerelease version with tag "pr${PR}"
end
Runner->>Repo: restore original package.json versions
end
Runner->>Runner: set workflow outputs (mode, install commands)
alt mode = pr
Runner->>Discord: send success/failure webhook (optionally mention requester)
end
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 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 |
…ooks → cloud-common → cloud-addon → export-import → svelte-query → observable → syncable)
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
.github/workflows/publish-canary.yml (1)
18-29: Pin the publish toolchain to known-good versions instead of floatinglatest.Lines 20 and 29 use
version: latestandnpm@latest, creating release path fragility. Per npm's Trusted Publisher documentation, this workflow requires npm 11.5.1+ and Node.js 22.14.0+. Additionally, line 26 pins onlynode-version: 22, which may not satisfy the 22.14.0 minimum.Recommended changes:
- Line 20: Pin
pnpmto a specific version (e.g.,version: 10.5.0or later)- Line 26: Update to
node-version: 22.14.0to ensure Trusted Publisher requirements are met- Line 29: Optionally pin
npmto 11.5.1 or a known-good patch (e.g.,npm@11.5.1ornpm@latest-11.5) for reproducibility🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish-canary.yml around lines 18 - 29, Update the GitHub Actions publish workflow to pin tool versions instead of using floating "latest": set the pnpm/action-setup@v4 "version" input to a specific known-good release (e.g., 10.5.0), change actions/setup-node@v4 "node-version" from "22" to "22.14.0" to meet Trusted Publisher minimums, and replace the global npm install step to install a pinned npm (e.g., npm@11.5.1 or another vetted patch) rather than npm@latest so the publish toolchain is reproducible and stable.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish-canary.yml:
- Around line 39-144: The current publish steps (e.g., the jobs named "Publish
dexie", "Publish dexie-cloud-common", "Publish dexie-react-hooks", etc.) check
if the exact version exists and skip, which breaks repeated canary publishing;
change each publish step to either 1) update package.json to a unique prerelease
version (e.g., append -canary.${GITHUB_RUN_NUMBER} to VERSION before publishing)
so pnpm publish always uploads a new version, or preferably 2) keep publishing
once and replace the skip logic with an npm dist-tag command (npm dist-tag add
<package>@$VERSION canary) to move the canary tag to the chosen VERSION when it
already exists; implement this in each publish block (identify by the step names
above) so canary behavior is deterministic.
---
Nitpick comments:
In @.github/workflows/publish-canary.yml:
- Around line 18-29: Update the GitHub Actions publish workflow to pin tool
versions instead of using floating "latest": set the pnpm/action-setup@v4
"version" input to a specific known-good release (e.g., 10.5.0), change
actions/setup-node@v4 "node-version" from "22" to "22.14.0" to meet Trusted
Publisher minimums, and replace the global npm install step to install a pinned
npm (e.g., npm@11.5.1 or another vetted patch) rather than npm@latest so the
publish toolchain is reproducible and stable.
🪄 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: 1572c74c-c6da-4da8-b02f-888299b70636
📒 Files selected for processing (1)
.github/workflows/publish-canary.yml
Comment on lines
+39
to
+144
| - name: Publish dexie | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show dexie@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing dexie@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "dexie@$VERSION already published, skipping." | ||
| fi | ||
|
|
||
| - name: Publish dexie-cloud-common | ||
| working-directory: libs/dexie-cloud-common | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show dexie-cloud-common@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing dexie-cloud-common@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "dexie-cloud-common@$VERSION already published, skipping." | ||
| fi | ||
|
|
||
| - name: Publish dexie-react-hooks | ||
| working-directory: libs/dexie-react-hooks | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show dexie-react-hooks@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing dexie-react-hooks@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "dexie-react-hooks@$VERSION already published, skipping." | ||
| fi | ||
|
|
||
| - name: Publish dexie-svelte-query | ||
| working-directory: libs/dexie-svelte-query | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show dexie-svelte-query@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing dexie-svelte-query@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "dexie-svelte-query@$VERSION already published, skipping." | ||
| fi | ||
|
|
||
| - name: Publish dexie-export-import | ||
| working-directory: addons/dexie-export-import | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show dexie-export-import@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing dexie-export-import@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "dexie-export-import@$VERSION already published, skipping." | ||
| fi | ||
|
|
||
| - name: Publish dexie-observable | ||
| working-directory: addons/Dexie.Observable | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show dexie-observable@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing dexie-observable@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "dexie-observable@$VERSION already published, skipping." | ||
| fi | ||
|
|
||
| - name: Publish dexie-syncable | ||
| working-directory: addons/Dexie.Syncable | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show dexie-syncable@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing dexie-syncable@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "dexie-syncable@$VERSION already published, skipping." | ||
| fi | ||
|
|
||
| - name: Publish y-dexie | ||
| working-directory: addons/y-dexie | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show y-dexie@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing y-dexie@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "y-dexie@$VERSION already published, skipping." | ||
| fi | ||
|
|
||
| - name: Publish dexie-cloud-addon | ||
| working-directory: addons/dexie-cloud | ||
| run: | | ||
| VERSION=$(node -p "require('./package.json').version") | ||
| PUBLISHED=$(npm show dexie-cloud-addon@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then | ||
| echo "Publishing dexie-cloud-addon@$VERSION as canary..." | ||
| pnpm publish --tag canary --provenance --no-git-checks | ||
| else | ||
| echo "dexie-cloud-addon@$VERSION already published, skipping." | ||
| fi |
There was a problem hiding this comment.
🧩 Analysis chain
🌐 Web query:
Can npm publish the same package version more than once, and if not, what is the supported way to move or update a dist-tag like canary for an already-published version?
💡 Result:
No, npm cannot publish the same package version more than once. The official npm documentation states: "The publish will fail if the package name and version combination already exists in the specified registry. Once a package is published with a given name and version, that specific name and version combination can never be used again, even if it is removed with npm unpublish." The supported way to update or move a dist-tag like canary for an already-published version is to use the npm dist-tag command. Specifically: - To add or move the tag to a specific version: npm dist-tag add @ canary - To remove a tag: npm dist-tag rm canary - To list tags: npm dist-tag ls This allows pointing dist-tags to any existing published version without republishing the version itself.
Citations:
- 1: https://docs.npmjs.com/cli/v8/commands/npm-publish/
- 2: https://docs.npmjs.com/cli/v8/commands/npm-dist-tag/
- 3: https://docs.npmjs.com/adding-dist-tags-to-packages/
- 4: https://docs.npmjs.com/cli/v9/commands/npm-publish
- 5: https://stackoverflow.com/questions/55769038/npm-cannot-publish-over-previously-published-version
- 6: [Question]Can npm publish same version npm package with different tag? npm/npm#20365
- 7: https://npmjs.com/policies/unpublish
- 8: https://stackoverflow.com/questions/67813980/how-to-point-latest-dist-tag-to-a-previous-version-in-npm
Update the publish logic to account for npm's version immutability.
The skip guard based on exact version will prevent repeated canaries on each master push. Once x.y.z exists on npm, the publish fails (npm forbids republishing the same version). To publish canaries on every push:
- Bump to a unique prerelease version per run (e.g.,
x.y.z-canary.${GITHUB_RUN_NUMBER}) inpackage.jsonbefore publishing, OR - Use
npm dist-tag add <pkg>@<version> canaryto move the tag to an existing version without republishing.
Option 2 is the standard pattern for dist-tag workflows: publish once per version, then use dist-tag commands to update which version the canary tag points to.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-canary.yml around lines 39 - 144, The current
publish steps (e.g., the jobs named "Publish dexie", "Publish
dexie-cloud-common", "Publish dexie-react-hooks", etc.) check if the exact
version exists and skip, which breaks repeated canary publishing; change each
publish step to either 1) update package.json to a unique prerelease version
(e.g., append -canary.${GITHUB_RUN_NUMBER} to VERSION before publishing) so pnpm
publish always uploads a new version, or preferably 2) keep publishing once and
replace the skip logic with an npm dist-tag command (npm dist-tag add
<package>@$VERSION canary) to move the canary tag to the chosen VERSION when it
already exists; implement this in each publish block (identify by the step names
above) so canary behavior is deterministic.
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (2)
.github/workflows/publish-canary.yml (2)
18-20: Pin pnpm version for reproducible builds.Using
version: latestcan cause unexpected build failures if a new pnpm release introduces breaking changes. Pin to a specific version for deterministic CI behavior.🔧 Suggested fix
- uses: pnpm/action-setup@v4 with: - version: latest + version: 9🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish-canary.yml around lines 18 - 20, Replace the non-deterministic `version: latest` value in the pnpm setup step so CI uses a pinned pnpm release; update the workflow step that uses `pnpm/action-setup@v4` to set `version` to a specific semver (e.g., a tested 8.x.y) or a repository-controlled input so builds are reproducible and only changed intentionally.
7-14: Consider adding concurrency control to prevent overlapping runs.If multiple commits are pushed to master in quick succession, parallel workflow runs could attempt to publish the same package versions simultaneously, potentially causing race conditions or confusing log output.
🔧 Suggested fix
jobs: publish: name: Publish canary to npm runs-on: ubuntu-latest + concurrency: + group: publish-canary + cancel-in-progress: false permissions: contents: read id-token: write # required for OIDC Trusted Publisher🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish-canary.yml around lines 7 - 14, The workflow's publish job ("publish" / name: "Publish canary to npm") can overlap when multiple commits are pushed; add GitHub Actions concurrency to the workflow (at top-level or enclosing the "publish" job) with a stable key (e.g. using github.ref or github.workflow and github.ref_name) and set cancel-in-progress: true to ensure only one publish run proceeds and in-flight runs are cancelled to avoid race conditions and duplicate publishes.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish-canary.yml:
- Around line 74-75: The current PUBLISHED check hides all npm errors by
redirecting stderr to /dev/null, so distinguish a genuine "version not found"
from other failures: run the npm show (npm view) command and capture stderr into
a temporary variable, set PUBLISHED only when the command succeeds (stdout
contains a version), but if it fails inspect the captured stderr for a 404/“not
found” indicator to treat as not-published and otherwise fail-fast (export an
error/exit with failure) so network/auth/registry errors aren’t masked; apply
the same pattern wherever PUBLISHED is computed.
---
Nitpick comments:
In @.github/workflows/publish-canary.yml:
- Around line 18-20: Replace the non-deterministic `version: latest` value in
the pnpm setup step so CI uses a pinned pnpm release; update the workflow step
that uses `pnpm/action-setup@v4` to set `version` to a specific semver (e.g., a
tested 8.x.y) or a repository-controlled input so builds are reproducible and
only changed intentionally.
- Around line 7-14: The workflow's publish job ("publish" / name: "Publish
canary to npm") can overlap when multiple commits are pushed; add GitHub Actions
concurrency to the workflow (at top-level or enclosing the "publish" job) with a
stable key (e.g. using github.ref or github.workflow and github.ref_name) and
set cancel-in-progress: true to ensure only one publish run proceeds and
in-flight runs are cancelled to avoid race conditions and duplicate publishes.
🪄 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: 9cb8da99-68ab-4be2-ba76-f4fa5bf3015d
📒 Files selected for processing (1)
.github/workflows/publish-canary.yml
Comment on lines
+74
to
+75
| PUBLISHED=$(npm show dexie@$VERSION version 2>/dev/null || echo "") | ||
| if [ -z "$PUBLISHED" ]; then |
There was a problem hiding this comment.
Improve npm show error handling to distinguish "not found" from other failures.
The current pattern 2>/dev/null || echo "" treats all errors (network issues, auth problems, registry outages) the same as "version not found". This could cause confusing error messages when pnpm publish then fails for an already-published version.
🔧 Suggested fix using exit code inspection
- PUBLISHED=$(npm show dexie@$VERSION version 2>/dev/null || echo "")
- if [ -z "$PUBLISHED" ]; then
+ if npm show dexie@$VERSION version >/dev/null 2>&1; then
+ echo "dexie@$VERSION already published, skipping."
+ else
echo "Publishing dexie@$VERSION as canary..."
pnpm publish --tag canary --provenance --no-git-checks
- else
- echo "dexie@$VERSION already published, skipping."
fiNote: This same pattern applies to all other publish steps.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-canary.yml around lines 74 - 75, The current
PUBLISHED check hides all npm errors by redirecting stderr to /dev/null, so
distinguish a genuine "version not found" from other failures: run the npm show
(npm view) command and capture stderr into a temporary variable, set PUBLISHED
only when the command succeeds (stdout contains a version), but if it fails
inspect the captured stderr for a 404/“not found” indicator to treat as
not-published and otherwise fail-fast (export an error/exit with failure) so
network/auth/registry errors aren’t masked; apply the same pattern wherever
PUBLISHED is computed.
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
.github/workflows/publish-pr.yml (1)
63-97: Consider one source of truth for publish targets.This workflow hard-codes the package inventory twice, and
.github/workflows/publish-canary.yml:71-80keeps a third copy. A shared manifest or generated matrix would make it much harder for PR prerelease and canary publishing to drift.Also applies to: 156-164
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.github/workflows/publish-pr.yml around lines 63 - 97, The workflow duplicates the list of package build/publish targets across publish-pr.yml and publish-canary.yml (e.g., steps named "Build dexie", "Build y-dexie" and working-directory values like addons/y-dexie, libs/dexie-react-hooks, addons/Dexie.Observable, addons/Dexie.Syncable), so centralize the package inventory into one source of truth (either a shared manifest file checked into the repo or a single workflow-level matrix/env variable) and update both publish-pr.yml and publish-canary.yml to consume that single list; modify the build job to iterate the shared list (via a job matrix or fromJson of the manifest) and remove the hard-coded duplicated steps (also apply the same replacement where the other duplicate block exists around the 156-164 section).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish-pr.yml:
- Around line 112-126: The publish logic currently lets publish_pkg calls be
skipped silently (SHOULD_PUBLISH remains false) and uses return which can mask
failure; change the flow to validate inputs.packages early and fail if the
resolved publish set is empty: when processing PACKAGES (and when PACKAGES !=
"all") split into PKG_LIST, trim items and check each entry against a known
allowlist of package names (or the repository package directories) and if any
requested name is invalid exit 1 with a clear error; after determining
SHOULD_PUBLISH for a PKG_NAME, if no package in the repo matches any requested
names (i.e. the final resolved set is empty) call exit 1 (or fail the job)
rather than echo+return so the workflow fails fast; update references in this
block (variables PACKAGES, PKG_LIST, PKG_NAME, SHOULD_PUBLISH and the
publish_pkg invocation) to implement the validation and exit behavior.
- Around line 186-194: The Discord payload currently injects the multiline shell
variable MESSAGE (which includes VERSIONS) directly into a JSON string causing
invalid JSON; update the send step to JSON-encode MESSAGE (e.g., use jq --arg or
printf + python -c/json.dumps/other JSON-escape helper to build {"content":
message} and pipe that to curl -d `@-`) and stop silencing failures (remove or
avoid curl -s) so HTTP errors surface; target the curl invocation and the
MESSAGE/VERSIONS variables in the publish workflow to replace the inline "-d"
JSON string with a properly escaped payload fed to curl from stdin.
---
Nitpick comments:
In @.github/workflows/publish-pr.yml:
- Around line 63-97: The workflow duplicates the list of package build/publish
targets across publish-pr.yml and publish-canary.yml (e.g., steps named "Build
dexie", "Build y-dexie" and working-directory values like addons/y-dexie,
libs/dexie-react-hooks, addons/Dexie.Observable, addons/Dexie.Syncable), so
centralize the package inventory into one source of truth (either a shared
manifest file checked into the repo or a single workflow-level matrix/env
variable) and update both publish-pr.yml and publish-canary.yml to consume that
single list; modify the build job to iterate the shared list (via a job matrix
or fromJson of the manifest) and remove the hard-coded duplicated steps (also
apply the same replacement where the other duplicate block exists around the
156-164 section).
🪄 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: fda86d35-bb44-4f77-a850-e633ee0841f1
📒 Files selected for processing (1)
.github/workflows/publish-pr.yml
Comment on lines
+112
to
+126
| if [ "$PACKAGES" = "all" ]; then | ||
| SHOULD_PUBLISH=true | ||
| else | ||
| IFS=',' read -ra PKG_LIST <<< "$PACKAGES" | ||
| for p in "${PKG_LIST[@]}"; do | ||
| if [ "$(echo $p | tr -d ' ')" = "$PKG_NAME" ]; then | ||
| SHOULD_PUBLISH=true | ||
| break | ||
| fi | ||
| done | ||
| fi | ||
|
|
||
| if [ "$SHOULD_PUBLISH" = "false" ]; then | ||
| echo "Skipping $PKG_NAME (not in requested packages)" | ||
| return |
There was a problem hiding this comment.
Do not report success when inputs.packages matches nothing.
A typo here skips every publish_pkg call and the workflow still completes as a success. Fail fast when the resolved publish set is empty, or validate the requested names against an allowlist before publishing.
Possible guard
PACKAGES="${{ inputs.packages }}"
PUBLISHED_VERSIONS=""
+ PUBLISHED_COUNT=0
@@
(cd "${PKG_DIR}" && pnpm publish --tag "${TAG}" --provenance --no-git-checks)
@@
PUBLISHED_VERSIONS="${PUBLISHED_VERSIONS}\n- \`npm install ${PKG_NAME}@${PR_VERSION}\`"
+ PUBLISHED_COUNT=$((PUBLISHED_COUNT + 1))
}
@@
+ if [ "$PUBLISHED_COUNT" -eq 0 ]; then
+ echo "::error::No packages matched inputs.packages='${PACKAGES}'"
+ exit 1
+ fi
+
echo "published_versions<<EOF" >> $GITHUB_OUTPUTAlso applies to: 153-168
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish-pr.yml around lines 112 - 126, The publish logic
currently lets publish_pkg calls be skipped silently (SHOULD_PUBLISH remains
false) and uses return which can mask failure; change the flow to validate
inputs.packages early and fail if the resolved publish set is empty: when
processing PACKAGES (and when PACKAGES != "all") split into PKG_LIST, trim items
and check each entry against a known allowlist of package names (or the
repository package directories) and if any requested name is invalid exit 1 with
a clear error; after determining SHOULD_PUBLISH for a PKG_NAME, if no package in
the repo matches any requested names (i.e. the final resolved set is empty) call
exit 1 (or fail the job) rather than echo+return so the workflow fails fast;
update references in this block (variables PACKAGES, PKG_LIST, PKG_NAME,
SHOULD_PUBLISH and the publish_pkg invocation) to implement the validation and
exit behavior.
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish.yml:
- Around line 30-33: The workflow currently allows mode=pr without validating
pr_number; update the publish job to validate inputs.pr_number when inputs.mode
== 'pr' (in the publish step logic) and fail fast with a clear error if it's
missing—e.g., add a conditional check at the start of the publish step that
inspects inputs.mode and inputs.pr_number and throws/uses core.setFailed when
mode === 'pr' and pr_number is empty so malformed versions cannot be published;
reference the publish step and the inputs keys pr_number and mode when making
the change.
- Around line 208-228: The Discord notify step currently won't run on failure
and reads an incorrect status; update the step's if condition to force execution
(e.g., prefix with always(): if: always() && (inputs.mode == 'pr' ||
(github.event_name == 'workflow_dispatch' && inputs.mode == 'pr'))) and replace
the STATUS assignment that uses job.status with the publish step outcome (change
STATUS="${{ job.status }}" to STATUS="${{ steps.publish.outcome }}") so the
script can correctly detect success vs failure and send the appropriate message;
keep the rest of the message construction (PR, REQUESTER, VERSIONS, RUN_URL)
unchanged.
🪄 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: 36e89cd1-71aa-451e-84ad-d46200846534
📒 Files selected for processing (1)
.github/workflows/publish.yml
- Pin pnpm to v10 and node to 22.14.0 (not 'latest') for reproducible builds - Pin npm to 11.5.1 (minimum required for OIDC Trusted Publisher) - Fix npm show error handling: use exit code instead of stdout capture - Add pr_number validation: fail fast when mode=pr but pr_number is missing - Add PUBLISHED_COUNT guard: fail with clear error if inputs.packages matches nothing - Discord notify: add always() so it fires on failure too; use steps.publish.outcome instead of job.status - Discord notify: build JSON payload with python3 to safely handle special chars - Fix build order to match topological dependency graph - Remove dexie-observable and dexie-syncable from build + publish (planned deprecation)
There was a problem hiding this comment.
Actionable comments posted: 3
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.github/workflows/publish.yml:
- Line 223: Replace the incorrect secret name used for Discord notifications:
change the workflow reference from DISCORD_WEBHOOK_LIZ_LEAD_DEV to the
documented secret name DISCORD_WEBHOOK_URL so the action reads e.g.
DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK_URL }}; update any related
environment variable usage that expects DISCORD_WEBHOOK to ensure it pulls from
DISCORD_WEBHOOK_URL and remove or correct the old secret reference to prevent
misconfigured notifications.
- Line 14: The workflow comment contains a real Discord user ID in the commented
env line "requester_discord_id=321912613246337024"; replace that concrete
identifier with a neutral placeholder (e.g., requester_discord_id=DISCORD_ID or
requester_discord_id=<YOUR_DISCORD_ID>) or remove the commented line entirely so
no real user identifiers are committed in the publish workflow. Ensure the
replacement keeps the same comment structure so intent is preserved.
- Around line 201-207: Reorder the publish_pkg calls to follow
dependency/topological order so dependent packages are published after their
dependencies: move the publish_pkg "y-dexie" "addons/y-dexie" line so it appears
before publish_pkg "dexie-react-hooks" "libs/dexie-react-hooks" (and verify any
other dependent pairs like dexie-cloud-addon vs its deps); update the sequence
of publish_pkg entries in the .github/workflows/publish.yml block to publish
dependencies first and dependents later.
🪄 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: 3651e72e-21ed-46a0-8636-c2028bf9cf7b
📒 Files selected for processing (1)
.github/workflows/publish.yml
| # -f mode=pr \ | ||
| # -f pr_number=2253 \ | ||
| # -f packages=dexie-cloud-addon \ | ||
| # -f requester_discord_id=321912613246337024 \ |
There was a problem hiding this comment.
Avoid committing real Discord user identifiers in workflow comments.
Line 14 includes a concrete Discord ID. Use a placeholder to avoid publishing user identifiers in repo metadata.
🔧 Proposed fix
-# -f requester_discord_id=321912613246337024 \
+# -f requester_discord_id=<discord-user-id> \📝 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
| # -f requester_discord_id=321912613246337024 \ | |
| # -f requester_discord_id=<discord-user-id> \ |
🧰 Tools
🪛 Betterleaks (1.1.1)
[high] 14-14: Identified a Discord client ID, which may lead to unauthorized integrations and data exposure in Discord applications.
(discord-client-id)
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish.yml at line 14, The workflow comment contains a
real Discord user ID in the commented env line
"requester_discord_id=321912613246337024"; replace that concrete identifier with
a neutral placeholder (e.g., requester_discord_id=DISCORD_ID or
requester_discord_id=<YOUR_DISCORD_ID>) or remove the commented line entirely so
no real user identifiers are committed in the publish workflow. Ensure the
replacement keeps the same comment structure so intent is preserved.
Comment on lines
+201
to
+207
| publish_pkg "dexie" "." | ||
| publish_pkg "dexie-cloud-common" "libs/dexie-cloud-common" | ||
| publish_pkg "dexie-react-hooks" "libs/dexie-react-hooks" | ||
| publish_pkg "dexie-svelte-query" "libs/dexie-svelte-query" | ||
| publish_pkg "dexie-export-import" "addons/dexie-export-import" | ||
| publish_pkg "y-dexie" "addons/y-dexie" | ||
| publish_pkg "dexie-cloud-addon" "addons/dexie-cloud" |
There was a problem hiding this comment.
Publish order should follow dependency order to reduce broken partial releases.
At Line 203, dexie-react-hooks is published before y-dexie (Line 206), while your own dependency-order notes indicate dexie-react-hooks depends on y-dexie. If a later publish fails, consumers can get an installable package set with missing prerelease deps.
🔧 Proposed fix (match topological order)
publish_pkg "dexie" "."
publish_pkg "dexie-cloud-common" "libs/dexie-cloud-common"
- publish_pkg "dexie-react-hooks" "libs/dexie-react-hooks"
publish_pkg "dexie-svelte-query" "libs/dexie-svelte-query"
- publish_pkg "dexie-export-import" "addons/dexie-export-import"
publish_pkg "y-dexie" "addons/y-dexie"
+ publish_pkg "dexie-export-import" "addons/dexie-export-import"
+ publish_pkg "dexie-react-hooks" "libs/dexie-react-hooks"
publish_pkg "dexie-cloud-addon" "addons/dexie-cloud"🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish.yml around lines 201 - 207, Reorder the
publish_pkg calls to follow dependency/topological order so dependent packages
are published after their dependencies: move the publish_pkg "y-dexie"
"addons/y-dexie" line so it appears before publish_pkg "dexie-react-hooks"
"libs/dexie-react-hooks" (and verify any other dependent pairs like
dexie-cloud-addon vs its deps); update the sequence of publish_pkg entries in
the .github/workflows/publish.yml block to publish dependencies first and
dependents later.
| - name: Notify via Discord (PR mode only) | ||
| if: always() && github.event_name == 'workflow_dispatch' && inputs.mode == 'pr' | ||
| env: | ||
| DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK_LIZ_LEAD_DEV }} |
There was a problem hiding this comment.
Use the documented webhook secret name to avoid notification misconfiguration.
Line 223 uses secrets.DISCORD_WEBHOOK_LIZ_LEAD_DEV, but the PR objective documents DISCORD_WEBHOOK_URL as the required secret. If only the documented secret exists, Discord notifications will fail.
🔧 Proposed fix
- DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK_LIZ_LEAD_DEV }}
+ DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK_URL }}📝 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
| DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK_LIZ_LEAD_DEV }} | |
| DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK_URL }} |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.github/workflows/publish.yml at line 223, Replace the incorrect secret name
used for Discord notifications: change the workflow reference from
DISCORD_WEBHOOK_LIZ_LEAD_DEV to the documented secret name DISCORD_WEBHOOK_URL
so the action reads e.g. DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK_URL }};
update any related environment variable usage that expects DISCORD_WEBHOOK to
ensure it pulls from DISCORD_WEBHOOK_URL and remove or correct the old secret
reference to prevent misconfigured notifications.
This was referenced Mar 31, 2026
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.
Adds
.github/workflows/publish.ymlthat automatically publishes all packages to npm with--tag canaryon every push tomaster, and supports manual prerelease publishing.How it works
master(canary) or manually (prerelease)pnpm publish --tag canary --provenance --no-git-checksversioninpackage.jsonis already published on npm, that package is skippedpnpm publish(notnpm publish) to correctly replaceworkspace:dependencies with real version numbersBuild order
Packages must be built in topological order based on their workspace dependencies:
Packages covered
dexie(root)libs/dexie-cloud-commonlibs/dexie-react-hookslibs/dexie-svelte-queryaddons/dexie-export-importaddons/y-dexieaddons/dexie-cloud(dexie-cloud-addon)npm Trusted Publisher setup needed
Before merging, configure Trusted Publisher on npm for each package:
publish.ymldexie/Dexie.js✅ David has configured Trusted Publisher for all packages above (as of 2026-03-30).
❌
dexie-observableanddexie-syncableintentionally excluded (planned deprecation).Discord webhook secret needed
Add a repository secret
DISCORD_WEBHOOK_URLwith the webhook URL for release notifications.Note on npm version
The workflow upgrades npm to latest before publishing — required for OIDC Trusted Publisher to work correctly.
Summary by CodeRabbit