ci: render specs against the post-merge azldev version#17777
Open
dmcilvaney wants to merge 1 commit into
Open
Conversation
dmcilvaney
force-pushed
the
damcilva/4.0/pipelines/improve_azldev_checks
branch
from
efeb5dc to
7795f7c
Compare
Contributor
There was a problem hiding this comment.
Pull request overview
Updates the rendered-specs drift check workflow to resolve and use the post-merge .azldev-version (from GitHub’s test-merge commit) so PRs are validated against the azldev binary that will actually run on 4.0 after merge, and to avoid unnecessary full renders when a PR is merely behind the base pin.
Changes:
- Poll PR mergeability to obtain
merge_commit_sha, then read.azldev-versionfrom that test-merge commit via the Contents API (no merge tree checkout). - Emit the resolved azldev version + a
render-alldecision asupdate_locksjob outputs and consume them inrender. - Switch full-render gating from a
base..head.azldev-versiondiff to the computedRENDER_ALLflag.
dmcilvaney
force-pushed
the
damcilva/4.0/pipelines/improve_azldev_checks
branch
from
7795f7c to
f3727c4
Compare
dmcilvaney
force-pushed
the
damcilva/4.0/pipelines/improve_azldev_checks
branch
2 times, most recently
from
bada665 to
019e7e0
Compare
The rendered-specs check built azldev from the PR head's .azldev-version and gated the full re-render on a two-dot `base..head` diff of .azldev-version. Both are wrong for a branch merely behind base on the pin: the head value is stale (not what runs on 4.0 after merge), and the two-dot diff fires a spurious full re-render that can only ever find no drift. Resolve the version that will actually be in effect on 4.0 after the PR merges: read .azldev-version from GitHub's test-merge commit via the Contents API -- no merge tree is checked out, only a single regex-validated string crosses to the host. GitHub computes mergeability asynchronously and the event's merge_commit_sha can be empty or stale, so poll the PR endpoint for the authoritative value and fail closed on a genuinely non-mergeable PR. Resolve once in update_locks (which polls mergeability, hence pull-requests:read) and expose azldev-version + render-all as job outputs that the render job consumes, so both jobs check drift against the same binary. A full re-render runs only when that post-merge version differs from the base pin -- i.e. the PR changes the azldev binary on 4.0 -- otherwise the normal PR-scoped render runs.
dmcilvaney
force-pushed
the
damcilva/4.0/pipelines/improve_azldev_checks
branch
from
e97823d to
95c938d
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
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.
The rendered-specs check built azldev from the PR head's .azldev-version and gated the full re-render on a two-dot
base..headdiff of .azldev-version. Both are wrong for a branch that is merely behind base on the pin: the head value is stale (not what runs on 4.0 after merge), and the two-dot diff fires a spurious full re-render that can only ever find no drift.Resolve the version that will actually be in effect on 4.0 after the PR merges: read .azldev-version from GitHub's test-merge commit (merge_commit_sha) via the Contents API -- no merge tree is checked out, only a single regex-validated string crosses to the host. GitHub computes mergeability asynchronously (the event's merge_commit_sha is usually null on a freshly opened PR), so poll the PR endpoint until it is computed and fail closed on a genuinely non-mergeable PR.
A full re-render now runs only when the post-merge version differs from the base branch's current pin -- i.e. when the PR actually changes the azldev binary on 4.0 -- otherwise the normal PR-scoped render runs. Adds pull-requests:read to the build/render jobs for the poll and logs the resolved version + render-all decision.