Add publication workflow for npmjs.com

[jdmarshall]

A release workflow for publishing to the npm registry.

[jdmarshall]

Two things with this. First, that project doesn't yet exist in npmjs.org and I don't have the rights to create it so I'm getting a 404.

Second, the NPM_TOKEN needs to be set in secrets and I don't know if it's there or not.

[krajorama]

Hi, thanks for starting on this, I think the release should be triggered on tag push. I've let Claude take a look and it pointed out a bunch of stuff. Here's its version:

---
name: Publish to npmjs.com

on:
  push:
    tags:
      - 'v*'

permissions: {}

jobs:
  publish:
    environment: release
    runs-on: ubuntu-latest
    permissions:
      contents: read
      id-token: write # required for npm publish --provenance

    steps:
      - uses: actions/checkout@9c091bb21b7c1c1d1991bb908d89e4e9dddfe3e0 # v7.0.0
      - name: Use Node.js LTS
        uses: actions/setup-node@48b55a011bda9f5d6aeb4c2d9c7362e8dae4041e # v6.4.0
        with:
          node-version: lts/*
          registry-url: 'https://registry.npmjs.org'

      - name: Verify release secrets
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}
        run: |
          if [ -z "${NODE_AUTH_TOKEN}" ]; then
            echo "::error::NPM_TOKEN secret is not set for the 'release' environment."
            exit 1
          fi

      - name: Verify tag matches package.json version
        run: |
          TAG="${GITHUB_REF_NAME#v}"
          PKG_VERSION="$(node -p "require('./package.json').version")"
          if [ "${TAG}" != "${PKG_VERSION}" ]; then
            echo "::error::Tag ${GITHUB_REF_NAME} (${TAG}) does not match package.json version (${PKG_VERSION})."
            exit 1
          fi
          echo "Publishing version ${PKG_VERSION}"

      - name: Determine npm dist-tag
        id: disttag
        run: |
          PKG_VERSION="$(node -p "require('./package.json').version")"
          if [[ "${PKG_VERSION}" == *-* ]]; then
            TAG="$(echo "${PKG_VERSION}" | sed -E 's/^[0-9]+\.[0-9]+\.[0-9]+-([0-9A-Za-z-]+).*/\1/')"
          else
            TAG="latest"
          fi
          echo "tag=${TAG}" >> "${GITHUB_OUTPUT}"
          echo "Using dist-tag: ${TAG}"

      - run: npm i
      - run: npm test
      - run: npm publish --provenance --access public --tag "${{ steps.disttag.outputs.tag }}"
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

[krajorama]

@jdmarshall I've lost access to NPM as it enforced 2FA - I've asked in the CNCF slack for the Prometheus team for help with it. I think once we get through these initial pain, we'll be fine!

[krajorama]

@jdmarshall I've lost access to NPM as it enforced 2FA - I've asked in the CNCF slack for the Prometheus team for help with it. I think once we get through these initial pain, we'll be fine!

@jdmarshall Got the access. However I cannot create the prometheus organization on npmjs as it's taken by a package last published 13 years ago: https://www.npmjs.com/package/prometheus

We're looking into resolving the conflict.

[jdmarshall]

They don't allow namespaces and packages to overlap? Odd, since they're handled unambiguously.

[krajorama]

They don't allow namespaces and packages to overlap? Odd, since they're handled unambiguously.

Nope, I tried creating the namespace and I got an error. However the author of the conflicting package graciously offered to help, see shubik/prometheus_deprecated#20

[jdmarshall]

good deal

[jdmarshall]

Are there any more changes we need for this? We have at least one user wondering when he gets to use all this good stuff.

[jdmarshall]

I know you're still working with @shubik on the name collision problem but can we land this now so I can pull the trigger when we are ready to go?

[krajorama]

I think our plan B has to be using the existing @prometheus-io org on npmjs. Let's agree on a deadline when we trigger plan B. How about next Friday , the 7th of Aug? cc @jdmarshall @SuperQ

[jdmarshall]

I don't have a better suggestion. But can we land some PRs to clear the decks? This one and a couple others are getting no progress and I'm losing momentum.

I'll file one to put back the other project name.

[jdmarshall]

@krajorama how we deal with the name collision is entirely moot as long as this PR is stuck in limbo. Can we please merge it? Like today? Juggling pending PRs takes time and energy I’d rather be spending on other things.

[jdmarshall]

Additionally I think the NPM secrets haven't been set yet and I'm hoping we can take care of that sooner rather than later. It's been six weeks. We'd told some people something would be out 2 weeks ago.

[krajorama]

Looks about right, I've added two - I think - blocking comments.

In a follow up, we should open two PRs:

• have a check that verifies that the tag is the same as the version in package.json
• switch to trusted publishing

[krajorama]

Let's try.

WDYT of we follow prometheus release process and make a branch for the 0.16 line, as in release-0.16. That would let us not deal with dependabot updates to packages and other changes to main and release from the branch. We can then merge back the changes to main.

[jdmarshall]

have a check that verifies that the tag is the same as the version in package.json

See, this and the Confused Deputy problem with Github Actions is why I don't like this solution. npm publish already sets the tag to match the package version. We're clobbering that to do something more clever and then having to tack stuff on to restore the same level of functionality that already exists. There's no Github Actions expert here. So every feature we implement using it is more surface area for a truly stupid issue to be introduced and louder recriminations to follow.

release branch

I would rather not sign up for supporting release branches for prom-client if at all possible. Are you thinking about hot fixes? We also haven't done anything in this workflow to deal with any branches other than main, so this is scope creep at this point. Which I'm happy to talk about once it's time to start landing V1 PRs. I want this PR and a couple others off of my plate so I can do other stuff, including life stuff like job hunting.

I'm having some issues with node-config that will repeat here, but I'll save that conversation for when we have it. Which is not now.

[krajorama]

have a check that verifies that the tag is the same as the version in package.json

See, this and the Confused Deputy problem with Github Actions is why I don't like this solution. npm publish already sets the tag to match the package version. We're clobbering that to do something more clever and then having to tack stuff on to restore the same level of functionality that already exists. There's no Github Actions expert here. So every feature we implement using it is more surface area for a truly stupid issue to be introduced and louder recriminations to follow.

Ah, ok. Well triggering a workflow or pushing a tag are both manual tasks, so there's no difference in principle to me, I was suggesting the tag, because in the projects I worked in we've always used that, including Prometheus. I think the friction comes from coming from very different backgrounds.

@jdmarshall I have set up the token in repo secrets.

release branch

I would rather not sign up for supporting release branches for prom-client if at all possible. Are you thinking about hot fixes? We also haven't done anything in this workflow to deal with any branches other than main, so this is scope creep at this point. Which I'm happy to talk about once it's time to start landing V1 PRs. I want this PR and a couple others off of my plate so I can do other stuff, including life stuff like job hunting.

I'm having some issues with node-config that will repeat here, but I'll save that conversation for when we have it. Which is not now.

Having a release branch just makes it easier to work on a stable state before/during release, I didn't want to imply supporting them in the future - but I can see how people might misinterpret having those branches. It's fine, software should be possible to release from main.

[jdmarshall]

Having a release branch just makes it easier to work on a stable state before/during release, I didn't want to imply supporting them in the future - but I can see how people might misinterpret having those branches. It's fine, software should be possible to release from main.

I want to be clear that I'd like to work something out for security fixes. Because I think that'll be important. It's more that there's too many open ended things going on in my github at the moment and I'm trying to squash some of them. We should brain storm how to do hot fixes in the next month or so. I'd like to have something worked out in the v1 timeframe.

If there's a CVE bulletin on a supply chain or DOS attack on prom-client or one of its dependencies, I'm absolutely on board for skipping the queue and getting a release out even if we are halfway through a giant refactor on main.