ci: revert to latest bit version via bvm upgrade

[GiladShoham]

Reverts the pinned bvm install 1.13.240 back to bvm upgrade to track the latest nightly bit version.

[qodo-free-for-open-source-projects]

PR Summary by Qodo

CI: switch bvm from pinned install to upgrade for latest nightly Bit
⚙️ Configuration changes 🕐 Less than 10 minutes

Description

• Change CircleCI to run bvm upgrade to track latest nightly Bit builds
• Stop pinning bvm install 1.13.240 (kept as commented fallback)
• Keep bvm defaults pointing to bbit and nightly release type

Diagram

graph TD
  A["CircleCI pipeline"] --> B["bvm config"] --> C["bvm upgrade"] --> D["bvm link"] --> E["Bit (nightly)"]
  B --> F["DEFAULT_LINK=bbit"]
  B --> G["RELEASE_TYPE=nightly"]
  subgraph Legend
    direction LR
    _ci["CI step"] ~~~ _tool["Tooling"] ~~~ _ext{{"External build"}}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Keep Bit pinned (versioned install)

• ➕ Reproducible CI runs and easier bisects
• ➕ Avoids surprise breakages from nightly changes
• ➖ Requires manual updates to stay current
• ➖ May lag behind nightly-only fixes the team wants to validate

2. Pin by digest/commit (if supported) with scheduled bump

• ➕ Predictable builds while still tracking nightly on a controlled cadence
• ➕ Allows automated rollout with a revert point
• ➖ More CI logic (scheduled job or parameterization)
• ➖ Depends on bvm/Bit support for commit/digest addressing

3. Parameterized channel (nightly vs stable) via CircleCI context/env var

• ➕ Can run nightly in a dedicated workflow while keeping default stable/pinned
• ➕ Fast rollback by switching parameter rather than editing config
• ➖ Adds configuration surface area and branching in CI config
• ➖ Requires discipline to keep both paths working

Recommendation: If the goal is to continuously validate against the newest nightly Bit, the PR’s bvm upgrade approach is appropriate. To reduce operational risk, consider adding an easy fallback mechanism (e.g., an env-var switch that can force a pinned version) so CI can be stabilized quickly when a nightly regression lands.

Files changed (1) +2 / -2

Other (1) +2 / -2

config.ymlUse 'bvm upgrade' instead of pinned 'bvm install' for nightly Bit +2/-2

Use 'bvm upgrade' instead of pinned 'bvm install' for nightly Bit

• Switches the CI provisioning step from installing a fixed bvm-managed Bit version (1.13.240) to upgrading to the latest nightly version. Leaves the pinned install command commented for potential rollback.

.circleci/config.yml

[Copilot]

Pull request overview

This PR updates the CircleCI pipeline to stop pinning a specific BVM-installed Bit version and instead run bvm upgrade so CI tracks the latest nightly Bit build.

Changes:

• Switch BVM setup from bvm install 1.13.240 back to bvm upgrade.
• Keep the previously pinned install command commented out as an easy rollback option.

[qodo-free-for-open-source-projects]

Code Review by Qodo

🐞 Bugs (2) 📘 Rule violations (0) 📜 Skill insights (0)

1. Nightly cache key drift 🐞 Bug ☼ Reliability

Description

bvm_upgrade now upgrades to the latest nightly (RELEASE_TYPE nightly + bvm upgrade), but the
/home/circleci/.bvm cache key is still derived from version.txt generated via `npm view
@teambit/bit version` before the upgrade. As a result, the cache key is not coupled to the nightly
actually installed by bvm upgrade, which can reduce cache correctness/efficiency (cache reuse
across different nightlies, or lack of cache refresh when nightlies change).

Code

.circleci/config.yml[R227-228]

+      - run: bvm upgrade
+      # - run: bvm install 1.13.240

Evidence

bvm_upgrade explicitly upgrades on the nightly channel, but the .bvm cache key is derived from
version.txt created via npm view @teambit/bit version before the upgrade; the key therefore does
not necessarily track the version installed by bvm upgrade.

.circleci/config.yml[223-239]
.circleci/config.yml[391-400]
.circleci/config.yml[565-586]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
The CI cache key for `/home/circleci/.bvm` is computed from `version.txt` that’s populated from `npm view @teambit/bit version`, while `bvm_upgrade` installs/links `bbit` from the **nightly** channel via `bvm upgrade`. This disconnect means the cache key does not represent the actual installed nightly version.

### Issue Context
- `restore_common_caches` writes `version.txt` from `npm view @teambit/bit version` and restores the `.bvm` cache using it.
- `bvm_upgrade` sets `RELEASE_TYPE nightly`, runs `bvm upgrade`, and then saves the `.bvm` cache using the same `version.txt` checksum key.

### Fix Focus Areas
- .circleci/config.yml[223-239]
- .circleci/config.yml[391-400]

### Suggested fix
Update caching so the key reflects the resolved `bbit`/nightly version (or disable `.bvm` caching for the nightly flow):
- After `bvm upgrade` (and after linking), write the resolved version to a file, e.g. `bbit -v > version.txt` (or a dedicated `bbit-version.txt`).
- Save the `.bvm` cache using the checksum of that resolved-version file.
- Adjust the restore logic for the nightly flow to restore the most recent nightly cache (e.g., using a dedicated nightly cache prefix/key strategy) rather than relying on `npm view @teambit/bit version`.

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Nightly CI not reproducible 🐞 Bug ☼ Reliability

Description

Replacing a pinned bvm install 1.13.240 with bvm upgrade under RELEASE_TYPE nightly makes CI
runs depend on whatever nightly is current at runtime, so rerunning the same commit can execute with
a different bbit version. This reduces debuggability and makes failures harder to reproduce
without separately capturing the resolved nightly version.

Code

.circleci/config.yml[R227-228]

+      - run: bvm upgrade
+      # - run: bvm install 1.13.240

Evidence

The PR change replaces a pinned install with bvm upgrade while keeping RELEASE_TYPE nightly,
making the installed version float over time.

.circleci/config.yml[223-235]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

### Issue description
Using `bvm upgrade` on the nightly channel makes the CI environment non-deterministic across reruns of the same commit.

### Issue Context
The CI step explicitly sets `RELEASE_TYPE nightly` and runs `bvm upgrade` instead of installing a pinned version.

### Fix Focus Areas
- .circleci/config.yml[223-235]

### Suggested fix
Add guardrails for reproducibility:
- Persist the resolved `bbit` version to a file (e.g. `bbit -v > bbit-version.txt`) and store it as an artifact (and/or persist to workspace) so failures can be correlated to an exact nightly.
- Optionally support an override to pin a specific version when needed (e.g. via an env var that switches between `bvm install $BIT_VERSION` and `bvm upgrade`).

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---