Diff iterative RCs against the prior RC of the same base version#396
Merged
Conversation
Until now the workflow always diffed any RC against the latest stable
release. For 27.6-RC2 this meant a 62k-line diff and a $2.10 agent run,
re-processing nearly all of 27.6-RC1's content for the second time.
This commit changes the diff-base resolution to:
1. Look at the tracking issue's processed-marker comments for prior
RCs of the same base version (e.g. 27.6-RC1 when processing
27.6-RC2).
2. If at least one such prior RC exists, use the latest one as the
diff base.
3. Otherwise fall back to the existing behavior (latest stable
release before the RC).
For RC2/RC3/RC4 of an active cycle this collapses the diff from
"everything since the last stable" to "delta from the previous RC",
which is typically a few hundred lines of bugfixes. Expect per-run
costs on iterative RCs to drop by roughly an order of magnitude.
The first RC of a new base version still diffs against stable (no
prior same-base markers exist). Manual workflow_dispatch with explicit
rc_tag also gets the optimization automatically — useful for backfill
of RCs older than what is already on the issue.
Two implementation notes worth flagging in review:
- `fetch_latest_marker` was generalized to `fetch_processed_markers`
(returns the full list rather than just the most recent). Both
consumers — the cron's "last processed RC" gating and the new
same-base diff-base resolver — now share one fetch and one helper.
- A new `PREV_KIND` env var (`stable` or `rc`) is exposed to the agent
alongside the existing `PREV_RELEASE`, so its run-summary can
distinguish a full-cycle diff from an incremental-RC diff. The
agent prompt doesn't *require* this; it's just informational.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Deploying yoast-developer with
|
| Latest commit: |
1d137ec
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2660391b.yoast-developer.pages.dev |
| Branch Preview URL: | https://rc-docs-sync-diff-base-prev.yoast-developer.pages.dev |
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.
What
Changes the diff-base resolution in
.github/workflows/rc-docs-sync.ymlso that iterative RCs (e.g.27.6-RC2,27.6-RC3, ...) are diffed against the most recent already-processed RC of the same base version, rather than always against the latest stable release.Why
The 27.6-RC2 run on Tuesday cost $2.10 for a single processing pass:
…because the diff was
27.5..27.6-RC2— 62k lines covering essentially the entire 27.6 release cycle, the vast majority of which was already considered (and rejected as internal) when 27.6-RC1 was processed. Every RC iteration in a cycle redoes the same work.This was already noted as a known optimization in #394's body. Implementing it now.
Behavior change
27.6-RC1(first RC of cycle)27.527.5(unchanged)27.6-RC2(after RC1 processed)27.527.6-RC127.6-RC3(after RC2 processed)27.527.6-RC227.6stable27.7-RC1(new cycle, after27.6shipped)27.627.6(unchanged)27.6-RC2(no prior27.6markers)27.527.5(unchanged)27.6-RC2(markers for RC1 + RC3 already exist)27.527.6-RC1The first-run seed behavior, the manual-
workflow_dispatchexplicit-RC path, and the agent's overall flow are all unchanged. The optimization fires automatically wherever prior same-base-version RCs are recorded on the tracking issue.Implementation
fetch_latest_marker→fetch_processed_markers. Returns the full list of processed RC tags for a product instead of just the most recent. Both the cron's "what's newer than the marker" gate and the new diff-base resolver now share one API call and one helper.PREV_KINDenv var (stableorrc) alongside the existingPREV_RELEASEso the agent can mention in its run summary whether this run was a full-cycle diff or an incremental-RC diff. Optional context; the prompt doesn't require it.Expected cost impact
For Yoast SEO's bi-weekly cadence (≈26 cycles/year), assuming an average of 2 RC iterations per cycle:
About a 2× reduction on free, more on full rollout because every product's iterative RCs benefit. Also drops PR-noise risk: the agent re-considers only what's actually new since the previous RC, rather than re-evaluating the same already-decided content.
Risk
Low. The fallback path is unchanged, so any RC for which no prior same-base marker exists behaves exactly like today. Manual
workflow_dispatchwith an explicitrc_tagcontinues to work, andfetch_processed_markersis a strict superset of whatfetch_latest_markerreturned, so the cron's "newer than last processed" gate is unaffected.The one observable change is that PRs opened on iterative RCs will reference a smaller, narrower diff in their evidence — which is what we want.