[bwalsh434]

BUILD-13251: Resolve Bun dependencies from the production Edge on every runner, using the shared config-bun action.

The October 26 Datadog refresh measured 26.39 GB/day of SaaS response bytes, including 26.30 GB from Bun (168.17 GB over seven days). bunfig.toml and setup-bun hardcoded SaaS, and the absolute tarball URLs in bun.lock kept installs on SaaS even when the registry changed.

• Registry: setup-bun calls config-bun 2.5.0 with repox-url: https://repox-internal.sonar.build. It fetches the Edge reader from Vault and exports BUN_CONFIG_REGISTRY and BUN_CONFIG_TOKEN. The callers in build.yml, full-release.yml and prepare-release-notes.yml no longer pass SaaS reader credentials.
• Lockfile: bun.lock pins every tarball to repox-internal.sonar.build. Bun downloads locked packages from the URLs written in bun.lock, not from the configured registry, and it writes registry-relative entries only for registry.npmjs.org (oven-sh/bun#45250). So the lockfile has to name the Edge for CI to use it. Versions and integrity hashes are unchanged.
• Local development: bunfig.toml points at the Edge too, so a developer's bun install keeps writing Edge URLs. It needs VPN and an Edge-accepted token in ARTIFACTORY_PRIVATE_READER_PASSWORD. A SaaS token valid for less than 240 seconds works through Access Federation: jf atc --server-id repox --expiry 200. The CLAUDE.md note says to commit bun.lock without repox.jfrog.io URLs.
• Every runner type: self-hosted Linux, self-hosted Windows on WarpBuild, and GitHub-hosted macOS, which reaches the Edge through its existing Cloudflare WARP step.
• Removed: build-scripts/normalize-bun-lock.sh, the Linux-only registry selection, the cross-compilation step's SaaS override, and --network-concurrency 4. That limit is being re-checked on a cold install: runs with a warm cache can't show whether it was needed.

Test plan:

• Run 40478890642, with sign-macos temporarily enabled on the PR:
  • Unit Tests - windows on WarpBuild: Dependency registry: https://repox-internal.sonar.build/artifactory/api/npm/npm/, then 288 packages installed [13.28s].
  • Sign and Notarize macOS Binaries: WARP connection established successfully, the same Edge registry, then 288 packages installed [11.81s], followed by successful signing and notarization.
  • Lint, Linux unit tests and Build All Binaries passed with the Edge reader.
• Run 40482224490, on the final head with sign-macos back to master and branch-* only: Lint, Linux and Windows unit tests, and Build All Binaries passed. These installs restored the Bun cache.
• An authenticated request with a 200-second SaaS token downloaded @sonar/scan-5.0.2 from the Edge, with HTTP 200 and the full tarball.

Post-merge: check the first master run's sign-macos install and the Datadog SaaS bytes for this repository.

Rollback: revert this PR.

[netlify]

✅ Deploy Preview for sonarqube-cli canceled.

Name	Link
🔨 Latest commit	baef358
🔍 Latest deploy log	https://app.netlify.com/projects/sonarqube-cli/deploys/6ae0ed405bb90b9b979b4cc0

[hashicorp-vault-sonar-prod]

BUILD-13251

[charafsalmi]

Thanks Brian, the approach and the test plan look good, and the checks cover Linux, Windows and the macOS signing path. I have one open question about Renovate, inline below. If it is already handled, I'm happy to approve.

Two small things that should not block the merge:

• build-scripts/compile-target-runtime.ts:30 still defaults to the SaaS registry, and its comment says it mirrors bunfig.toml, which is no longer true. tests/unit/build-scripts/compile-target-runtime.test.ts:51,57 hardcode the SaaS URL too.
• The Sentry upload step in build.yml:323-324 still sets ARTIFACTORY_PRIVATE_READER_PASSWORD to the SaaS token, which overrides the Edge one exported by setup-bun. It does no harm today because sentry-cli installs nothing.

[charafsalmi]

Question before this merges: once bun.lock pins every tarball to the Edge, what rewrites the URLs of the entries Renovate touches? In #1113 the changed eslint-plugin-headers line points to repox.jfrog.io, and its renovate/artifacts check is failing, so the bun install post-upgrade task in .github/renovate.json is not fixing it.

bun ci downloads from the URL written in the lockfile (as the description says), while BUN_CONFIG_REGISTRY and the token are the Edge ones. So I expect that package to fail with a 401 on Renovate PRs after the merge. Is this handled somewhere I can't see, for example in the Renovate platform config or a host rule?

[gitar-bot]

Code Review ✅ Approved 4 closed / 4 findings

🟡 Medium risk · Routing Bun installs across CI runners and local development through the production Repox Edge could disrupt builds if access or registry configuration fails.

Routes Bun dependency resolution through the production Edge on every runner via config-bun, and pins bun.lock tarball URLs to repox-internal.sonar.build. Resolved this session: CI no longer downloads tarballs from SaaS URLs, hand-edited lockfile URLs no longer revert on the next write, config-bun is pinned to a released version instead of a mutable feature branch, and workflows no longer fetch the unused SaaS private-reader secret. No open issues found.

✅ 4 closed

✅ Bug: bun ci still downloads tarballs from SaaS URLs pinned in bun.lock

📄 .github/actions/setup-bun/action.yml:39-43 📄 .github/actions/setup-bun/action.yml:48-50 📄 .github/actions/setup-bun/action.yml:55-57
bun.lock stores an absolute tarball URL for every package. There are 332 entries like "@babel/core": ["@babel/core@7.29.0", "https://repox.jfrog.io/artifactory/api/npm/npm/@babel/core/-/core-7.29.0.tgz", …]. With a frozen lockfile, Bun downloads from the URL in the lockfile and does not switch to the host in BUN_CONFIG_REGISTRY. I checked this locally with Bun 1.3.14: the lockfile pointed at host A, BUN_CONFIG_REGISTRY pointed at host B and BUN_CONFIG_TOKEN=edgetok was set. bun ci fetched the tarball only from host A and sent Authorization: Bearer edgetok; host B got no requests.

On self-hosted Linux runners this means every dependency tarball still comes from repox.jfrog.io (the SaaS instance), so this change saves none of the 26 GB/day of Bun traffic it targets. Worse, the Edge private-reader token from development/artifactory-edge-prod/... is now sent to SaaS. If SaaS rejects that token, every Linux bun ci fails with 401. The "Dependency registry: …repox-internal…" log line would also suggest Edge is in use when it is not.

Fix: when Edge is selected, rewrite the lockfile host before bun ci. I re-ran the same test with the URLs rewritten via sed: bun ci succeeded and fetched from the configured host with the Edge token. Another option is to stop pinning registry hosts in the committed lockfile.

✅ Bug: Hand-edited bun.lock URLs revert on next Bun lockfile write

📄 bun.lock:53-55
I don't think this bun.lock shape will survive the next lockfile write. Bun 1.4.4 is pinned in mise.toml, and its text-lockfile writer only writes "" for tarball URLs under Npm::Registry::DEFAULT_URL (registry.npmjs.org). Any other URL is written out in full (bun-v1.4.4 bun.lock.rs). Upstream PR #45250 would change that, but it is still unmerged.

When Bun reads a "" entry, it rebuilds the URL from the configured registry. bunfig.toml sets that to https://repox.jfrog.io/.... So the next bun install, bun add or bun update that rewrites the lockfile will put absolute repox.jfrog.io URLs back. That includes Renovate's postUpgradeTasks bun install, which is filtered to bun.lock in .github/renovate.json. A run from a self-hosted Edge environment would pin Edge URLs instead.

This matches the Bun lockfile registry URLs note: the "" form was only checked for reading during a frozen install, not for how it is written back. Once the URLs are absolute again, frozen bun ci on self-hosted Linux goes back to downloading from SaaS. That undoes the bandwidth goal without any error, because the install still succeeds.

Fix: add a guard that fails CI when bun.lock contains absolute tarball URLs. Also add a Renovate post-upgrade step that normalizes the URLs back to "". Bump Bun once upstream writes "" for URLs under the configured registry.

✅ Security: config-bun pinned to a mutable, unreleased feature branch

📄 .github/actions/setup-bun/action.yml:12
Every Bun install in CI now goes through SonarSource/ci-github-actions/config-bun@feat/hnasr/BUILD-13251-configBun. That ref is a feature branch, and config-bun is not on master or in the latest tag (2.4.2). A branch ref can move, so new pushes to it run in every job and can read the Vault reader tokens it fetches and exports. When the branch is merged or deleted, uses: stops resolving and every workflow using setup-bun fails (build, full-release, prepare-release-notes). It also breaks the repo's own convention: every other third-party action here, including SonarSource/ci-github-actions/get-build-number@c3a85ac… # 2.2.0, is pinned to a commit SHA with a version comment. Fix: pin to a full commit SHA (the branch head is currently c4694c9559d9dd76b9f509d06c984d22f1cb357f), and preferably wait for a tagged ci-github-actions release that includes config-bun before merging.

✅ Quality: Workflows still fetch the SaaS private-reader secret that setup-bun no longer uses

📄 .github/workflows/build.yml:68-69 📄 .github/workflows/build.yml:170-171 📄 .github/workflows/build.yml:342-343 📄 .github/workflows/build.yml:368-369 📄 .github/workflows/build.yml:397-398 📄 .github/workflows/build.yml:418-419 📄 .github/workflows/build.yml:442-443 📄 .github/workflows/build.yml:471-472 📄 .github/workflows/full-release.yml:86-87 📄 .github/workflows/prepare-release-notes.yml:31-32
This commit stopped passing artifactory-username/artifactory-password to setup-bun, because config-bun now fetches its own reader from Vault. But the jobs' vault-action-wrapper steps still request development/artifactory/token/{REPO_OWNER_NAME_DASH}-private-reader (as ARTIFACTORY_USER/ARTIFACTORY_ACCESS_TOKEN). Nothing in those jobs reads them anymore. The one exception is the Sentry step in the publish job (build.yml:323-324). So each job makes an extra SaaS credential read, and that credential gets exposed to the job for no reason. Fix: remove the two private-reader lines from every vault step except the publish job's, which still needs them for the Sentry step.

Verification Rules 3/3 met Knowledge 🔎 1

Functional validation No results

Rules 3 passed 1 not applicable

✅ Approved GitHub Actions runners
✅ Internal artifact registries
✅ Repository license compliance

Knowledge 🔎 1 informed a finding

🔎 Bun lockfile registry URLs informed a finding, resolved -> Hand-edited bun.lock URLs revert on next Bun lockfile write

Auto-approval Not enabled

Set up

_{For more verification details, comment gitar display:verbose.}

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing compact verification results.

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}

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues
0 New dependency risks

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[bwalsh434]

Hey @charafsalmi. We at EngXP would prefer to provide you two things to move forward here:

• A solution for Renovate on repox edge, we are looking at consolidating into a single URL for public/private via split-zone on our LB, that way we can have a single URL where Renovate SaaS can access the Edge and you can privately pull these dependencies internally
• A config-bun action in ci-github-actions to handle these dependencies seamlessly

I'm going to close this PR for now and will reopen or open a new PR with refs to this one once we have a solution for you. We appreciate the diligence and feedback here!

cc: @hedinasr