[vdiez]

Publishing from an extracted package directory repacks the Maven-built archive already uploaded to Repox. This produces different SHA-512 checksums for the same package version on Repox and public npm, causing npm ci integrity failures when a public lockfile is installed through Artifactory. For 2.31.0-5284, the archives contain identical files but are 2,861 and 2,840 bytes respectively; SonarSource/SonarJS#8090 exposed this mismatch.

Publish the downloaded Repox tarball directly to public npm instead of extracting and repacking it. Retain Trusted Publishing, provenance, public access, and the latest tag. Both registries then serve the same archive without additional packing or checksum-management logic.

Validation:

• Parsed workflow YAML and checked the publication script's shell syntax.
• Confirmed a real npm publish --dry-run preserves the downloaded tarball's integrity.

Actual OIDC/provenance publication requires a release run. Existing published versions are not repaired by this change.

[hashicorp-vault-sonar-prod]

ACOMMONS-198

[datadog-sonarsource]

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 19c2d7c | Docs | View more details | Give us feedback!}

[gitar-bot]

Code Review ✅ Approved 1 closed / 1 findings

🟡 Medium risk · Release workflow now publishes the Repox tarball directly to public npm.

Fixes npm package integrity mismatches across Repox and public npm by publishing the downloaded tarball directly instead of extracting and repacking it, which eliminates SHA-512 checksum differences. Integrity validation now runs immediately after publish to catch registry lag issues.

✅ 1 closed

✅ Edge Case: Integrity check runs right after publish, so registry lag can fail it

📄 .github/workflows/release.yml:270-275
npm view "$package_spec" dist.integrity runs right after npm publish, with no retry. The public npm registry serves packuments through a CDN and is eventually consistent, so a version that was just published can return E404 or stale metadata for a short time. If that happens, set -e aborts the step, or published_integrity comes back empty and hits the mismatch branch. Either way the release job fails even though the publish worked. The step also can't simply be re-run, because npm publish will then reject the version that already exists. Fix: poll npm view with a bounded retry and backoff until it returns a non-empty integrity, then compare. Optionally, on re-runs, skip the publish when the version already exists and go straight to the integrity check.

Review coverage

🧪 Functional validation No results

📋 Rules No rules evaluated

Cross-repo coverage 1 repository selected

Cross-repo inspection is incomplete. Unread code may contain additional impacts.

🤖 Auto-approval Not enabled · Set up

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Counting what did not apply, without listing it.

Comment with these commands to change the behavior for this request:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
No data about Coverage
0.0% Duplication on New Code

See analysis details on SonarQube