feature: adding trusted publishing

[cache-your-dreams]

What does it do?

Adding trusted publishing

Why is it needed?

We want to stop using tokens to publish to npm

[changeset-bot]

⚠️ No Changeset found

Latest commit: 2d3878a

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[coderabbitai]

Important

Review skipped

Auto 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.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 9be20b65-fe7e-4d6b-813c-033e314768c7

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

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[Copilot]

Pull request overview

Adds npm “trusted publishing” support to the release workflow to move away from long-lived npm tokens when publishing packages.

Changes:

• Moves workflow permissions to the release job and adds id-token: write for OIDC.
• Updates the workflow to upgrade npm CLI before publishing.
• Removes use of NPM_TOKEN from the Changesets publish step.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[jhoward1994]

Thanks. Similar to the strapi/client discussion this seems like what we should do next, wdyt?

Workflow tweaks

• On registry-url: design-system’s trusted publishing setup doesn’t set this — would it make npm look for a token instead of OIDC. Can we remove it and align with design-system?
• Pin npm@^11.5.1 instead of @latest for consistency with client.

Suggested test plan

Unlike client, we can't workflow_dispatch this — publish only happens when Changesets merges a version PR. So:

1. Merge this PR (once registry-url thing is sorted)
2. Don't merge chore: version packages for release #177 yet — that would publish 6.2.0 to latest and would be our first OIDC publish
3. Enter changeset pre-release mode for a safe dist-tag:
   • pnpm changeset pre enter experimental (matches the existing npm experimental tag)
   • Add a small patch changeset on a branch → PR to main
4. Let Changesets open/update the version PR (should get something like 6.2.0-experimental.0)
5. Merge that version PR → release.yml runs → changeset publish should auth via OIDC (no NPM_TOKEN)
6. Verify:

   npm view @strapi/sdk-plugin dist-tags
   npm view @strapi/sdk-plugin@experimental version

[innerdvations]

I fixed one of the issues Jamie pointed out, LGTM now but I will defer final approval to him

[cache-your-dreams]

According to the docs, we should have registry-url when using actions/setup-node@v6. The Design System is still using actions/setup-node@v4, which might explain the difference.

For the npm version, I have no objections for pinning to npm@^11.5.1 but we use @latest on the Design System workflow, so should we harmonise? What is the arguement for pinning @^11.5.1?

One last question, is there a reason that we sometimes use Changesets and other times we do not?

As for the process, I suggest we go through the different steps together to make sure we're aligned on each step.

Thanks. Similar to the strapi/client discussion this seems like what we should do next, wdyt?

Workflow tweaks

• On registry-url: design-system’s trusted publishing setup doesn’t set this — would it make npm look for a token instead of OIDC. Can we remove it and align with design-system?
• Pin npm@^11.5.1 instead of @latest for consistency with client.

Suggested test plan

Unlike client, we can't workflow_dispatch this — publish only happens when Changesets merges a version PR. So:

1. Merge this PR (once registry-url thing is sorted)

2. Don't merge chore: version packages for release #177 yet — that would publish 6.2.0 to latest and would be our first OIDC publish

3. Enter changeset pre-release mode for a safe dist-tag:

   • pnpm changeset pre enter experimental (matches the existing npm experimental tag)
   • Add a small patch changeset on a branch → PR to main

4. Let Changesets open/update the version PR (should get something like 6.2.0-experimental.0)

5. Merge that version PR → release.yml runs → changeset publish should auth via OIDC (no NPM_TOKEN)

6. Verify:

   npm view @strapi/sdk-plugin dist-tags
   npm view @strapi/sdk-plugin@experimental version

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud