Set up OpenID Connect to publish NPM packages from GitHub Actions

[eliot-akira]

NPM: Trusted Publishers for GitHub Actions

https://docs.npmjs.com/trusted-publishers#for-github-actions

GitHub: OpenID Connect reference

https://docs.github.com/en/actions/reference/security/oidc

Find information about using OpenID Connect (OIDC) to authenticate GitHub Actions workflows with cloud providers

---

Related to our discussion about automated workflow for NPM and GitHub, particularly:

• Publish NPM package @tangible/fields on every Git tag fields#44

I saw this announcement that will likely affect the setup we figured out.

NPM: Important changes to authentication and token management

Granular npm access token lifetime limits

Starting in mid-October, all newly created write-enabled granular access tokens for npm will have:

• A default expiration of seven days, reduced from 30 days.
• A maximum expiration of 90 days, which used to be unlimited.

So any NPM auth token we added as org/repo-level secret will expire frequently.

They recommend a more frequent token rotation strategy (which would have to be automated); or setting up OpenID Connect (OIDC) authentication between GitHub and NPM.

Trusted publishing for npm packages: Configuring GitHub Actions

Unfortunately it looks like this cannot be automated, and needs to be set up for each NPM package. So far I believe it affects:

• @tangible/fields
• @tangible/roller

But there will likely be more in the future, for frontend and server-side libraries, modules, tools. For example, @tangible/ui.

---

@zinigor I wanted to ask your thoughts on it, how we can solve this without too much maintenance effort.

I'm hoping the tangiblebot user on NPM and maybe a corresponding GitHub user can help with automating some of it. A possible idea is to use a dedicated repo with GitHub Actions to run scheduled tasks.

---

The reason this issue is in the Pipeline module is that the question of publishing NPM packages is part of a larger automated workflow being solved and developed.

• Add common workflow steps and consolidate release script #6

Ideally, as we figure out various aspects of the build/test/release lifecycle for a project, the knowledge (documentation) and code can be extracted into a general-purpose workflow in this shared pipeline. Then new projects can benefit from it and have a simpler setup.

[zinigor]

I'd love to set up something like OIDC per-repo, I don't think the maintenance overhead will be too much of a burden, because we're automating releases that will save us more time in the long run.

I'll try to find some time for that this week.

I also wanted to ask your opinion on changing the workflow to use composer, npm and .gitattributes for plugin build configuration instead of moving everything into roller.

[eliot-akira]

OIDC per-repo

Sure, sounds like a workable solution. We can start with Fields and Roller, and set up others as needed.

use composer, npm and .gitattributes for plugin build configuration

I'd prefer not to depend on Composer for common build tasks, other than installing external dependencies when necessary. PHP and Composer are optional in the current setup, which supports running them in a container instead of required on the local system. Ideally the workflow can accommodate both scenarios for flexibility.

[zinigor]

Still a rough sketch but I'm hoping can be developed further for practical use. This Create tool is also published to NPM, with a nice shortcut to run it: npm create tangible.

This is exactly my point, there are already simple tools available for doing most of the things. How often do we need to scaffold new projects? So for existing ones we can just use whatever we already have with minimal configuration in each respository. I feel like further abstraction here creates more friction than it removes.

[eliot-akira]

minimal configuration in each respository

I agree, I support any effort to simplify the plugin build setup. It currently requires: Git, Node, Docker.

But I'd rather not add another dependency for the user to install on the local system, like PHP/Composer or pnpm. Would be even better to run Node/NPM in a container too. Docker is an industry standard but I'd love to use a more generic tool that runs OCI (Open Container Initiative) containers.

If you'd prefer to use Composer (or any other tools) for parts of the build configuration, please feel free to implement it in any project, maybe an example plugin or an existing one you're working on, and we can consider how to integrate your ideas to the common setup.

I liked @TangibleMark's setup with search-sync, or the more elaborate use of Composer in orm, that one is an exemplary PHP project.

Ideally we can support similar setups without additional install requirements.

---

(Edit: I moved the comment below to issue #9)

On the subject of the build pipeline and authentication with third-party services. So far we have:

• GitHub auth for a project to have Composer/Git dependencies on private repos.
  Example: Blocks Pro - https://github.com/TangibleInc/blocks-pro/blob/main/.github/workflows/release.yml
• NPM auth for a project to publish NPM packages
  Example: Fields - https://github.com/TangibleInc/fields/blob/main/.github/workflows/publish.yml
• Cloudflare auth for a project to publish a static site
  Example: Tangible UI - https://github.com/TangibleInc/tangible-ui/blob/main/.github/workflows/deploy-cloudflare-pages.yml
• WordPress auth for a project to publish to the official plugin directory
  Example: Loops & Logic - https://github.com/TangibleInc/loops-and-logic/blob/main/.github/workflows/release.yml (Publish step is still done by personal SVN user)

For each of these services, currently we have a single person with the actual knowledge and access to set up the authentication.

I suggest we document the setup for each service, and confirm that at least two people are able to do it on a regular basis.

[eliot-akira]

This link has useful info, I added it to the issue description.

• GitHub Docs: OpenID Connect Reference

[zinigor]

OK, on the NPM side this is done for both Fields and Roller:

I haven't set up any environments in the repos themselves, I think we can do without them for now.

[eliot-akira]

Thank you so much - I'll let you know next time there's a version release, and confirm that it works.