fix(spec-sync): compare published specs against main, not the checked-out branch - #623
Merged
Merged
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 6 Skipped Deployments
|
|
…-out branch The sync job checks out the spec's long-lived `spec-sync/<spec>` branch when one exists, so comparing the published spec with the working tree asked whether that branch was up to date rather than whether `main` was. Correct while the pull request is open; wrong once it is closed without merging and the branch survives, because the branch carries the refresh, `main` does not, and every later run reports the spec as current. The spec then stops syncing with no failure and no warning. `spec-sync/settings` hit this on 2026-09-23. Both scripts now read the spec from `SPEC_SYNC_BASELINE` (default `origin/main`), the same ref the export diff already used: one comparison, one knob, and a branch with a pending refresh keeps being brought up to date, which is the existing intent for an open pull request. A spec absent from the baseline counts as fully changed. An unresolvable baseline is an error rather than a silent "everything changed". `--list` also reports a spec whose published `x-version-timestamp` has run more than SPEC_SYNC_STALE_DAYS (14) ahead of the baseline, and the workflow raises that in its step summary. That is the signal this class of failure did not have. Closes #618
field123
force-pushed
the
fix/618-baseline-comparison
branch
from
September 23, 2026 16:51
0c2ee55 to
56ea60a
Compare
field123
marked this pull request as ready for review
September 23, 2026 17:01
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.
Closes #618.
Background
This repository publishes TypeScript SDK packages. It generates them from OpenAPI specifications, which are files that describe an API.
Elastic Path publishes its own copy of each specification. A scheduled job downloads them every weekday. When a published specification differs from ours, the job updates our copy, regenerates the client code, and opens a pull request for a person to review.
The problem
The job decided whether a specification needed updating by comparing the published file against the copy on the branch it had checked out. Each specification has its own branch, and the job checks that branch out when it exists.
That comparison is correct while the pull request is open. The branch already holds the update, so the job does not repeat the work.
The comparison is wrong after somebody closes the pull request without merging it, if the branch stays. The branch still holds the update. The main branch does not. Every later run compares the published file against the updated copy, finds them the same, and reports the specification as current.
The specification then stops updating. Nothing fails and nothing warns. The result looks the same as a specification with no upstream changes.
This happened on 2026-09-23. The branch for the
settingsspecification outlived its closed pull request, and the next run skipped that specification.The fix
Both scripts now compare the published specification against the main branch instead of the checked-out branch. That asks the question the job cares about: does the published file differ from what we released?
A branch that holds a pending update keeps receiving new updates, which is the existing behavior for an open pull request.
The scripts already read
SPEC_SYNC_BASELINEto name the reference branch, and it defaults toorigin/main. This change reuses that variable rather than adding a second one. The two comparisons must use the same reference. If they differ, the job can compare export names against a commit that never held the specification in question.A warning for specifications that stop updating
Nothing noticed that a specification had stopped updating. The listing step now compares dates. If the published specification is more than 14 days newer than ours, the run reports it in the job summary.
SPEC_SYNC_STALE_DAYSsets the limit.Evidence
Three cases, each run as a command.
already currentand the listing returns an empty set.A full run for one specification that does differ regenerates the client, writes a changeset, and exits 0.
For the reviewer
A specification whose pull request stays open now regenerates on every scheduled run. It no longer stops early. A guard still prevents an empty commit, so the cost is build minutes rather than extra pull requests.
If your local copy of the main branch is out of date, a listing run by hand reports merged specifications as changed. Fetch first. Continuous integration is not affected.