* Keep the stored release commit when HEAD is behind it
A sync from a rolled-back checkout used to write its older HEAD onto an
existing release, rewinding the pipeline's scan baseline. The next sync
then re-scanned the range up to the current HEAD and re-attached issues
that had already shipped.
Before syncing, compare HEAD to the newest stored release anchor from
recentReleasesByAccessKey. When HEAD is strictly behind it, omit
commitSha from the sync input and log that the release commit is left
unchanged. The scan range itself is unaffected; --base-ref keeps
controlling it without dragging the anchor backwards as a side effect.
Requires server support for a nullable commitSha on ReleaseSyncInputBase.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Send preserveStoredCommitSha instead of omitting the commit
Omitting commitSha broke continuous pipelines, which identify releases
by it. Always send the checked-out commit and set
preserveStoredCommitSha when HEAD is behind the stored anchor; the
server applies it to scheduled pipelines only. The field is only sent
when set, so normal syncs remain compatible with older servers.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Always send preserveStoredCommitSha
The field was dropped from the payload when false to tolerate servers
without it. The server change deploys before this releases, so the
compatibility gate is unnecessary.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Prefer the syncing version's release in the rollback check
The candidate list is ordered by activity, not ancestry, so a release
from a divergent train could rank first. Ancestry to it cannot be
established, the check failed open, and the sync could still replace
the syncing version's stored commit with the rollback HEAD.
When a version is supplied and a candidate carries it, that release's
commit alone decides preservation, mirroring the scan-base rule that
prefers the syncing version's release.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Support negated release path filters
Co-authored-by: linear-code[bot] <222613912+linear-code[bot]@users.noreply.github.com>
* Trim whitespace after negation so the exclusion is not silently dropped
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Reject a pathless negation instead of scanning unfiltered
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
---------
Co-authored-by: Linear <linear-6ee3ee0f-1ea6-4b88-a969-f63432eeb657@linear.linear.app>
Co-authored-by: linear-code[bot] <222613912+linear-code[bot]@users.noreply.github.com>
Co-authored-by: Axel Niklasson Yun <axel@linear.app>
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* Detect repository provider for self-hosted VCS hosts
* Trim provider detection to GitLab CI inference and explicit override
* Rename override to LINEAR_VCS_PROVIDER and move resolution into provider module
* Simplify provider resolution after cleanup review
* Tighten provider detection note in README
* Move repo URL parsing and provider knowledge into the provider module
* Add --include-messages option to filter commits by subject regex
* Extract subject-parsing into a shared helper
* Apply --include-messages to inner subject of revert commits
* Rename --include-messages to --include-subjects
* Group scanCommits filters into a ScanOptions object
---------
Co-authored-by: Axel Niklasson Yun <axel@linear.app>
duong-vu