Skip to content

fix(ci): publish releases under an explicit dist-tag - #678

Draft
iagoaraujo wants to merge 1 commit into
6.xfrom
chore/6.x/fix-npm-publish-dist-tag
Draft

fix(ci): publish releases under an explicit dist-tag#678
iagoaraujo wants to merge 1 commit into
6.xfrom
chore/6.x/fix-npm-publish-dist-tag

Conversation

@iagoaraujo

Copy link
Copy Markdown
Contributor

Problem

The v6.51.1 release never reached npm. The publish workflow ran (run 31034142378), pulled vtex-api-6.51.1.tgz from CodeArtifact, and then failed on the last step:

npm error Cannot implicitly apply the "latest" tag because previously published version 7.4.2
is higher than the new version 6.51.1. You must specify a tag using --tag.

The publish step only passed --tag for the beta environment:

TAG_FLAG=""
if [ "${{ github.event.inputs.environment }}" = "beta" ]; then
  TAG_FLAG="--tag beta"
fi
npm publish "${TARBALL}" --provenance --access public ${TAG_FLAG}

For production it passed no tag at all, so npm tried to move latest from 7.4.2 down to 6.51.1 and refused. This is why v6.51.1-beta published fine while v6.51.1 did not — the beta path always had an explicit tag, so it never exercised the bug. It is also why the 7.x line has never hit this: for v7.4.2 the implicit latest is correct, since it is the highest published version.

Note that lint and ci:test failing on 6.x are unrelated to this. Those come from the node-ci-v2 pipeline, which .vtex/deployment.yaml triggers on branch pushes; tag pushes run npm-publish-v1, which only executes ci:build.

Change

The publish step now always resolves an explicit dist-tag: beta for the beta environment, latest for major >= 7, and v{major}-latest otherwise. The leading v from the git tag name is stripped before the comparison, so both v6.51.1 and 6.51.1 resolve identically.

This is a port of the logic in ee2b88c7 ("fixing ci by adding custom latest tags"), which only ever lived on julio/fix-npm-publish-ci and was never merged into 6.x or master. One difference: that version did not strip the v, so MAJOR became v6, the numeric comparison errored out, and the tag came out as vv6-latest — which is why that odd dist-tag currently holds 6.51.0 on npm.

Follow-ups

  • master carries the same old script. It works today only because 7.x is the highest major, so the same fix should be ported there for consistency.
  • Existing npm dist-tags for this package are v1-latest, v3-latest and the accidental vv6-latest. With this change the v6 line publishes to v6-latest. Whoever tracks vv6-latest would stay on 6.51.0, so that tag should either be re-pointed (npm dist-tag add @vtex/api@6.51.1 vv6-latest) or deprecated.

Test plan

  • YAML parses (6 steps in the publish job)
  • Tag resolution verified for v6.51.1/6.51.1 -> v6-latest, v7.4.2/7.4.2 -> latest, v10.0.0 -> latest, and any version with environment=beta -> beta
  • Cut a new tag off 6.x after merge and confirm the publish lands on v6-latest

Made with Cursor

npm refuses to implicitly move "latest" backwards, so publishing 6.51.1
failed because 7.4.2 already holds that tag. The publish step now resolves
the dist-tag from the major version, keeping the 7.x line on "latest" and
sending older majors to their own tag.

Co-authored-by: Cursor <cursoragent@cursor.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant