Correctly set base sha when multiple releases are in progress#63
Open
Conversation
Wraps `git merge-base --is-ancestor` for the upcoming base-SHA walk. A candidate SHA on a side branch isn't reachable from the main-train HEAD, so the walk needs this primitive to skip it.
Pure helper that picks a base SHA from a list of candidate releases by asking git which one is reachable from HEAD. Tests cover the four bug shapes (concurrent trains, mirror, all-non-ancestors, null commitSha) plus baseline + first-sync, and an end-to-end pairing with getCommitContextsBetweenShas that turns the LIN-69430 bug into a concrete reproduction.
Replace `getLatestRelease` + verbatim-trust logic with `recentReleasesByAccessKey` (limit pinned at 20 via a GraphQL variable) and let findBaseSha pick the first ancestor of HEAD. Falls back to the existing first-sync boundary when no candidate matches; surface that fall-through at warn level when the candidate list was non-empty so the case shows up in CI logs.
RomainCscn
force-pushed
the
romain/lin-69484-ci-release-sync-can-pick-a-wrong-base-sha-when-multiple
branch
from
7130412 to
85f286b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
On every
sync, the CLI picks a "starting point" SHA from the API and uses it as the base forgit log <base>..<HEAD>. Today the CLI trusts whatever the API returns, even when that SHA isn't on the build commit's branch ; leading to wrong ranges and re-attached issues. This PR has the CLI walk a list of recent release candidates and pick the first one that's actually an ancestor of HEAD.Before
When a pipeline has multiple in-progress releases (concurrent trains, hotfixes, freshly-created rows), the API can't tell which release CI is asking about. It returns one based on a SQL heuristic. When that pick is wrong, the CLI scans a nonsensical commit range and either re-attaches issues that already shipped via a different release, or under-covers commits that should belong to the new release.
The fix
recentReleasesByAccessKeyreturning a list of recent releases, ordered by the same heuristic.Examples of bugs fixed by this + what doesn't change
1. Hotfix on a side branch
API picks 1.70.1 (most recent
createdAt). Its SHAH2is on the side branch. CLI walksH2..D→ scansB, C, D— everything 1.71.0 already shipped. Already-shipped issues re-attached to 1.72.0.2. Mirror — CI on the hotfix branch
Same topology, CI now building 1.70.2 from the hotfix branch tip. API picks 1.71.0; its SHA is on main, not on the hotfix branch. CLI walks
main-SHA..hotfix-HEAD→ scans every commit on the hotfix branch. Issues already shipped via 1.70.1 re-attached.3. Stale or orphaned
commitShaA release's stored SHA no longer exists on any branch (force-pushed trunk, manual edit, etc.). API still returns it. CLI walks from an orphan SHA → wrong range or error.
4. Newly created release with
commitSha = nullUser clicks "Create release" in the UI. Row exists with no SHA yet. API returns it as latest. CLI sees
null, falls through to "scan current commit only." Misses everything between the previous release and HEAD.What doesn't change
The walk only adds an
is-ancestorcheck. A check can reject wrong answers; it can't turn a right answer into a wrong one.Verification
src/base-sha.test.ts, 8 scenarios) plus an integration test that runsfindBaseSha→getCommitContextsBetweenShas→scanCommitsagainst a real git topology.mainvs the fix branch — three bugs reproduced onmain, all fixed, baseline unchanged.Stacked on #62.