T8782: scaffold queue defaults and backport label vocabulary#6
Draft
andamasov wants to merge 1 commit into
Draft
T8782: scaffold queue defaults and backport label vocabulary#6andamasov wants to merge 1 commit into
andamasov wants to merge 1 commit into
Conversation
Follow-up to the 2026-05-13 Mergify kick-off meeting with maintainers (Christian, Daniil, Kyrylo, Alex, John). Codifies fleet-wide queue defaults and the backport target label vocabulary in the central baseline, without flipping any new live capability. What this adds: - `defaults.queue_rule:` with `update_method: rebase`, `merge_method: merge`, `batch_size: 1`. Per https://docs.mergify.com/configuration/sharing, `defaults:` field- merges between parent and child, so consumers inherit these values and can override any single one. These defaults are INERT until a consumer defines a concrete `queue_rules:` entry, so no PR on any current extender (vyos-documentation, vyatta-cfg) gets enqueued by this change. - Comment block documenting the canonical backport target labels (`backport/sagitta`, `backport/circinus`, `backport/equuleus`, `backport/crux`). Mergify does not provision labels itself; this is the contract the future external "deferred backport on release tag" GitHub Action will consume (Christian's ask in the meeting). - Commented-out reference `queue_rules:` shape for the first opt-in consumer to copy-paste into its per-repo `.github/mergify.yml`. What this deliberately does NOT add: - No `queue_rules:` entry. The meeting framed merge queue rollout as "preparation, gather feedback, iterate"; declaring a concrete queue in central would silently accept `@Mergifyio queue` from any maintainer on every consumer. The first opt-in repo declares its own `queue_rules:` locally, validates on real PRs, and the queue shape graduates to central once observed working. - No standalone `pull_request_rules` auto-rebase. The rebase behavior Alex asked about is covered by `update_method: rebase` once a queue is in use; a free-standing `update` action on every open PR fleet-wide would force-push history under maintainers' feet. - No auto-trigger backport rule. The deferred-backport workflow (Christian's ask) needs an external trigger on tag creation, which lives in a future GH Action, not here. Refs: T8782, T8852, IS-432. 🤖 Generated by [robots](https://vyos.io)
|
Important Review skippedDraft detected. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Central YAML (base), Organization UI (inherited) Review profile: CHILL Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches✨ Simplify code
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
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.
Summary
Follow-up to the 2026-05-13 Mergify kick-off meeting with Christian, Daniil, Kyrylo, Alex, and John. Codifies the next layer of the central baseline from the meeting outcomes without flipping any new live capability for the 2 current extenders (vyos/vyos-documentation and vyos/vyatta-cfg) or the ~27 T8852 migration targets.
Three additions, all in
.mergify.yml:defaults.queue_rule:withupdate_method: rebase,merge_method: merge,batch_size: 1. Per the Mergify sharing docs, values underdefaults:field-merge between parent and child — so any consumer that later defines a concretequeue_rules:entry inherits these and can override any single value. Inert until a consumer adds aqueue_rules:block.backport/sagitta,backport/circinus,backport/equuleus,backport/crux. This is the canonical contract a future external GitHub Action will consume to implement Christian's "hold backport until target release tag exists" ask.queue_rules:shape that the first opt-in consumer copies into its per-repo.github/mergify.yml. Validate on real PRs locally, then graduate the queue definition into this central file after one round of feedback.Deliberately out of scope
queue_rules:entry centrally. Yuriy framed the meeting as "preparation, gather feedback, iterate" — declaring a concrete queue here would silently start accepting@Mergifyio queueon every consumer.updatepull_request_rules. Alex's auto-rebase ask is covered byupdate_method: rebaseonce a queue is in use. A free-standing fleet-wide rebase action would force-push under maintainers' feet on every open PR.release.published); not a Mergify primitive.Refs
Notes for reviewer
python3 -c "import yaml; yaml.safe_load(open('.mergify.yml'))"). Structural keys after this change:defaults(now withactions+queue_rule),pull_request_rules(unchanged, 2 entries),commands_restrictions(unchanged).commands_restrictions.queue: *allowedline is unchanged. Because noqueue_rules:entry exists,@Mergifyio queuefrom a maintainer would currently fail (no queue defined). No tightening needed at this layer.Test plan
vyos/vyos-documentation(extender T8782: add central Mergify baseline for vyos org #1) and confirm Mergify continues to enforce only the existing rules (conflict label, T-ID format) and that@Mergifyio queuerejects with no-queue-definedvyos/vyatta-cfg(extender general: T8595: add AGENTS.md #2)queue_rules:locally (per "graduate from per-repo to central after feedback")🤖 Generated by robots