Merge branch 'main' into fix/sdk-e2e-bootstrap-downloads

Author: Victor-Rodzko

.github/actions/download-release-artifact/action.yml

@@ -0,0 +1,35 @@
+name: Download release artifact (with availability guard)
+description: >
+  Download a build artifact produced earlier in the run. If the download fails
+  (most commonly because the artifact expired while a release run waited for
+  manual approval, but also on transient registry/network errors, a renamed
+  artifact, or a permissions issue), fail fast with an actionable message
+  instead of the cryptic "Artifact not found" download error.
+
+inputs:
+  name:
+    description: "Artifact name to download"
+    required: true
+  path:
+    description: "Destination path for the downloaded artifact"
+    required: true
+
+runs:
+  using: composite
+  steps:
+    - name: Download build artifact
+      id: dl
+      continue-on-error: true
+      uses: actions/download-artifact@3e5f45b2cfb9172054b4087a40e8e0b5a5461e7c # 8.0.1
+      with:
+        name: ${{ inputs.name }}
+        path: ${{ inputs.path }}
+
+    - name: Guard against unavailable artifact
+      if: steps.dl.outcome == 'failure'
+      shell: bash
+      env:
+        ARTIFACT_NAME: ${{ inputs.name }}
+      run: |
+        echo "::error title=Build artifact unavailable::The '${ARTIFACT_NAME}' build artifact could not be downloaded (see the download step log above for the underlying error). The most common cause is expiry: the GitHub Actions retention window elapsed while this run waited for release approval. If so, re-running ONLY the failed jobs will NOT help because the artifact is gone for good - re-run the ENTIRE workflow ('Re-run all jobs') or re-trigger it (push / workflow_dispatch) on the release branch so the build job regenerates the artifact before publish."
+        exit 1

.github/actions/publish-library-to-npm/action.yaml

@@ -111,8 +111,16 @@ runs:
         # Auto-decide the dist-tag on release branches when the caller did not
         # pass an explicit non-"latest" tag. Backports to older release-* lines
         # (where package.json version is lower than the current published
-        # `latest`) are published under v<major>.<minor> so they never clobber
-        # the homepage pointer. The newest release line auto-promotes `latest`.
+        # `latest`) are published under release-<major>.<minor> so they never
+        # clobber the homepage pointer. The newest release line auto-promotes
+        # `latest`.
+        #
+        # The dist-tag MUST NOT be a valid SemVer range, because npm rejects
+        # such tags ("Tag name must not be a valid SemVer range"). A bare
+        # "v<major>.<minor>" (e.g. "v0.4") coerces to ">=0.4.0 <0.5.0" and is
+        # refused, so the line tag is prefixed with "release-" to keep it a
+        # plain identifier (matching the documented npm_tag override example
+        # "release-1.x" used by the addon workflows).
         #
         # Triggered when:
         #   - caller passed empty input  (EXPLICIT_TAG=false), OR
@@ -178,13 +186,13 @@ runs:
           #     otherwise win to the backport branch -- including the newest
           #     line, which is the catastrophic case (no `latest` promotion
           #     for a legitimate release).
-          #  2. IS_PRERELEASE is checked separately and FORCES v<major>.<minor>
-          #     regardless of how core() compares. npm convention is that
-          #     `npm install <pkg>` should never pull a prerelease, so even a
-          #     prerelease whose core is >= current latest must NOT take the
-          #     `latest` tag. Consumers opt in via `npm i <pkg>@v<M>.<m>`,
-          #     or operators can override with an explicit npm_tag (e.g.
-          #     "next") on workflow_dispatch.
+          #  2. IS_PRERELEASE is checked separately and FORCES
+          #     release-<major>.<minor> regardless of how core() compares. npm
+          #     convention is that `npm install <pkg>` should never pull a
+          #     prerelease, so even a prerelease whose core is >= current latest
+          #     must NOT take the `latest` tag. Consumers opt in via
+          #     `npm i <pkg>@release-<M>.<m>`, or operators can override with an
+          #     explicit npm_tag (e.g. "next") on workflow_dispatch.
           #
           # Removing either piece reintroduces a footgun. Keep both.
           IS_PRERELEASE=$(node -e 'console.log(/-/.test(process.argv[1]) ? "yes" : "no")' "$PACKAGE_VERSION")
@@ -199,13 +207,13 @@ runs:
           MAJOR_MINOR=$(echo "$PACKAGE_VERSION" | awk -F. '{print $1"."$2}')
 
           if [ "$IS_PRERELEASE" = "yes" ]; then
-            TAG="v${MAJOR_MINOR}"
+            TAG="release-${MAJOR_MINOR}"
             REASON="prerelease $PACKAGE_VERSION never auto-promotes latest (current latest=$CURRENT_LATEST)"
           elif [ "$HIGHER" = "yes" ]; then
             TAG="latest"
             REASON="package.json version $PACKAGE_VERSION >= current latest $CURRENT_LATEST"
           else
-            TAG="v${MAJOR_MINOR}"
+            TAG="release-${MAJOR_MINOR}"
             REASON="package.json version $PACKAGE_VERSION < current latest $CURRENT_LATEST (backport)"
           fi