fix(ci): restore lane config changes during ci merge to main#10219
fix(ci): restore lane config changes during ci merge to main#10219davidfirst wants to merge 5 commits intomasterfrom
Conversation
When `bit ci merge` switches from a lane to main, config changes made via `bit env set` or `bit deps set` were lost. Now compares lane Version extensions with main Version extensions and saves differences to .bitmap before tagging.
There was a problem hiding this comment.
Pull request overview
Fixes bit ci merge behavior when the workspace is checked out to a lane so that lane-only component config changes (e.g. from bit env set, bit deps set) are not lost during the switch back to main before tagging.
Changes:
- Capture lane components before switching to
main, then restore lane-vs-main extension config differences into.bitmapaftercheckout head. - Add an e2e test covering
bit ci mergepreserving anenv-setconfig change made on a lane.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
scopes/git/ci/ci.main.runtime.ts |
Restores lane config changes into .bitmap during CI merge by diffing lane vs main Version extension configs. |
e2e/harmony/ci-commands.e2e.ts |
Adds an e2e scenario asserting env config is preserved after bit ci merge. |
You can also share your feedback on Copilot code review. Take the survey.
- Collapse redundant configDiff intermediate object into single-pass loop - Flatten deep nesting for mainConfig loading with optional chaining - Parallelize component processing with Promise.all - Add missing test assertions for remote export and lane cleanup
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
You can also share your feedback on Copilot code review. Take the survey.
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
You can also share your feedback on Copilot code review. Take the survey.
| this.workspace.bitMap.addComponentConfig(laneComp.id, aspectId, config as Record<string, any>); | ||
| hasChanges = true; |
There was a problem hiding this comment.
hasChanges is set to true whenever a lane aspect differs from main, even if bitMap.addComponentConfig() ends up making no change (it returns false when the current bitmap config already matches). This can cause an unnecessary .bitmap write + workspace.clearCache() and a misleading "Restored config changes" log. Consider using the boolean return value from addComponentConfig() to update hasChanges only when a mutation actually occurred.
| this.workspace.bitMap.addComponentConfig(laneComp.id, aspectId, config as Record<string, any>); | |
| hasChanges = true; | |
| const updated = this.workspace.bitMap.addComponentConfig( | |
| laneComp.id, | |
| aspectId, | |
| config as Record<string, any> | |
| ); | |
| if (updated) hasChanges = true; |
When
bit ci mergeruns on a workspace checked out to a lane, config changes (frombit env set,bit deps set, etc.) were lost during the switch to main.The fix compares each lane component's Version extensions with its main Version extensions. Any differences are saved to
.bitmapbefore tagging, so config changes survive the lane-to-main transition.Test plan
bit ci merge when lane has config changes (env-set)