@teambit/ci 1.0.382 → 1.0.384

package/commands/pr.cmd.ts

@@ -9,6 +9,7 @@ type Options = {
   lane?: string;
   strict?: boolean;
   dryRun?: boolean;
+  keepLane?: boolean;
 };
 
 export class CiPrCmd implements Command {
@@ -23,6 +24,11 @@ export class CiPrCmd implements Command {
     ['b', 'build', 'Set to true to build the app locally, false (default) will build on Ripple CI'],
     ['s', 'strict', 'Set to true to fail on warnings as well as errors, false (default) only fails on errors'],
     ['d', 'dry-run', 'Run the full pipeline but skip exporting to remote (build runs only if --build is set)'],
+    [
+      '',
+      'keep-lane',
+      'Reuse the same remote lane across PR commits (preserves lane history and cloud UI edits) instead of recreating it on every run',
+    ],
   ];
 
   constructor(
@@ -67,6 +73,7 @@ export class CiPrCmd implements Command {
       build: options.build,
       strict: options.strict,
       dryRun: options.dryRun,
+      keepLane: options.keepLane,
     });
 
     if (results) {

package/dist/ci.main.runtime.d.ts

@@ -113,17 +113,99 @@ export declare class CiMain {
     private getCustomCommitMessage;
     private verifyWorkspaceStatusInternal;
     private switchToLane;
+    /**
+     * Sync *config-only* changes from main onto the lane — without a full `bit lane merge`.
+     *
+     * In this workflow git is the source of truth for files: the PR author merges the default branch
+     * into their PR branch, so source changes arrive via git. The one thing git can't carry is
+     * config that's already been *tagged into objects* on main — e.g. another PR ran `bit env set` /
+     * `bit deps set`; those records lived in `.bitmap`, rode git into main, and `bit ci merge` baked
+     * them into the component's Version (clearing them from `.bitmap`). A long-running PR's lane
+     * would otherwise miss them.
+     *
+     * A full lane merge is the wrong tool here: it does a 3-way *file* merge and refuses to run while
+     * the workspace has modified components — but in `bit ci pr` the workspace is always dirty (the
+     * PR's changes, not yet snapped). So instead we do a per-component 3-way merge of the aspect
+     * *config only* (base = common ancestor, ours = lane, theirs = main), keeping the PR's config on
+     * conflict, and stash the result on an `unmergedComponents` entry's `mergedConfig`. The
+     * subsequent `snap` reads it (via the aspects-merger on component load) and bakes main's config
+     * into the new snap, while the snap's files still come from the workspace (git). No file
+     * checkout, so no clean-workspace requirement.
+     */
+    private syncConfigFromMain;
+    /**
+     * Copied from `merging.main.runtime` (`filterDeletedDependenciesFromConfig`): the config merge
+     * can emit deletion markers (`version: '-'`) for deps removed on main. The aspects-merger applies
+     * `mergedConfig` verbatim, so strip those here to avoid writing a policy entry with version '-'.
+     */
+    private filterDeletedDependenciesFromConfig;
+    /**
+     * Best-effort, fetch-free check for whether the current (PR) branch is *behind* the default
+     * branch — i.e. the default branch has commits the PR branch doesn't contain.
+     *
+     * We intentionally do NOT `git fetch` here (a fetch in CI can hang on an interactive SSH
+     * host-key prompt — that's why `isStaleCiRun` was removed in #10300). We compare against
+     * whatever `origin/<default>` ref the checkout already has, which reflects the state the default
+     * branch was in when this CI run started — exactly the reference point we care about.
+     *
+     * Returns true only when we can *confirm* the branch is behind. If the ref can't be resolved or
+     * anything else goes wrong, returns false (treat as "not behind" / proceed) so we never silently
+     * disable the main→lane config propagation.
+     */
+    private isBranchBehindDefaultBranch;
     verifyWorkspaceStatus(): Promise<{
         code: number;
         data: string;
     }>;
-    snapPrCommit({ laneIdStr, message, build, strict, dryRun, }: {
+    snapPrCommit({ laneIdStr, message, build, strict, dryRun, keepLane, }: {
         laneIdStr: string;
         message: string;
         build: boolean | undefined;
         strict: boolean | undefined;
         dryRun?: boolean;
+        keepLane?: boolean;
     }): Promise<string | undefined>;
+    /**
+     * `--keep-lane` flow: reuse the existing remote lane (or create it on the first run), merge main
+     * into it to pick up config changes that landed since the fork, snap, and export with
+     * adopt-on-conflict recovery for concurrent CI pushes. The lane object is preserved across PR
+     * commits, so its history and lane-based UI edits on Bit Cloud survive.
+     */
+    private snapAndExportReusingLane;
+    /**
+     * Default flow: snap onto a uniquely-named temporary lane, then at export time delete any
+     * existing remote lane and rename the temp lane to the final name. The temp name minimizes the
+     * race window when multiple CI jobs run concurrently on the same branch. Trade-off: the final
+     * lane is recreated on every PR commit, so its history and any lane-based UI edits on Bit Cloud
+     * don't survive across commits — use `--keep-lane` for that.
+     */
+    private snapAndExportWithTempLane;
+    /**
+     * Export with a recovery path for the two concurrent-CI conflicts that can surface from the
+     * remote (see the marker constants at the top of the file): lane-hash mismatch (both runners
+     * created fresh lane objects when the lane didn't yet exist on the remote) and per-component
+     * divergence (both reused the existing lane but snapped the same component with different
+     * content).
+     *
+     * Recovery: adopt-the-winner. The remote lane (whoever pushed first) becomes canonical. We
+     * drop our local lane object, fetch the remote, rebase our snapped Version objects so each
+     * one's parent points to the remote head for that component, then swap those rebased Versions
+     * in as the new lane heads and re-export. Build artifacts are preserved — only the parent
+     * pointers on the Version objects change. Result: both runners' snaps end up chained on a
+     * single lane object (last-writer-wins on content for any contested component, with the
+     * winner's snap preserved in history as the parent).
+     */
+    private exportWithAdoptOnConflict;
+    /**
+     * Wrap `exporter.export()` with retry on the "server is busy" error. The retried export's
+     * pending-dir lands behind whichever concurrent client is still in the remote's queue (we
+     * arrived second by definition — we're the loser of the original race). The 60s wait inside
+     * `export-validate.waitIfNeeded` covers the common case, but on slow CI hosts or large pushes
+     * we sometimes time out before the other client finishes its persist. A short sleep + retry
+     * here just gives the queue room to drain.
+     */
+    private exportWithBusyRetry;
+    private rebaseOntoRemoteLane;
     mergePr({ message: argMessage, build, strict, releaseType, preReleaseId, incrementBy, explicitVersionBump, verbose, versionsFile, autoMergeResolve, forceTheirs, laneName, skipPush, noBitmapCommit, }: {
         message?: string;
         build?: boolean;
@@ -163,9 +245,10 @@ export declare class CiMain {
     /**
      * Export with retry on lane hash-mismatch, caused by a concurrent `bit ci pr` run pushing the
      * same lane id between our pre-export delete and the hub's merge (the export takes 1-2 minutes,
-     * plenty of time to race). Before each retry we skip if the PR branch has advanced past our
-     * commit - in that case a newer run will publish the correct lane, and retrying with our older
-     * snaps would regress the PR preview.
+     * plenty of time to race). Used by the default (temp-lane) flow. On mismatch we delete the
+     * remote lane and retry — the temp-lane flow recreates the lane on every run anyway, so there's
+     * no lane history to preserve. (The `--keep-lane` flow instead adopts the remote lane and
+     * rebases onto it; see `exportWithAdoptOnConflict`.)
      */
     private exportWithRetryOnLaneHashMismatch;
     /**