Fix speculative build matching for CD-workflow repositories - #3737
Merged
Conversation
The link registry lookup used the full repository name (e.g. "elastic/kibana") but the registry keys are short names (e.g. "kibana"), so alreadyPublishing was always false. This caused version branches like 9.5 to trigger speculative builds on repos that publish continuously from main — a scenario we already accounted for but the key mismatch silently bypassed. Also logs the detected branching strategy (cd vs tagged-release) to make future debugging easier. Co-Authored-By: Claude Sonnet 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Cursor <cursoragent@cursor.com>
reakaleek
approved these changes
Jul 28, 2026
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
2 participants
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.
Why
Repositories using the CD (continuous deployment) branching strategy — where
current,next, andedgeall point tomain— were incorrectly getting speculative builds triggered for version branches like9.5.We already had logic to prevent this: the
Matchmethod checks whether a repo is "already publishing" to the link registry, and if so, skips speculative builds for version branches on CD-workflow repos. The guard was correct, but a key-format mismatch in the caller silently defeated it.Surfaced via: https://github.com/elastic/kibana/actions/runs/30279228305/job/90021040764#step:5:1
Kibana is configured as a CD-workflow repo (
current = next = edge = main), yet branch9.5matched as a speculative build because thealreadyPublishingflag was alwaysfalse.What
The link registry uses short repository names as keys (e.g.
"kibana"), but the matching service was looking up the full GitHub name (e.g."elastic/kibana").ContainsKeysilently returnedfalse, so every repository appeared "not yet publishing" — bypassing the guard that blocks speculative builds for CD-workflow repos that are already in the registry.Both
Match()andGetProductByRepositoryName()already split the full name and use the short form. The registry lookup was the one place that didn't.The fix extracts the short repository name before the lookup and adds logging for:
cd/continuous-deploymentvstagged-release)Made with Cursor