| Age | Commit message (Collapse) | Author |
|---|
|
Add a merge_protection that blocks merge while a maintainer-applied WIP
label is present. Bot authors (mirror pipeline vyos-bot, mergify,
copilot, vyosbot) are exempt via the if: scope, so cross-org mirror PRs
to rolling are never held. Same shape as the existing label gates; has
teeth once the Mergify Merge Protections check is made required
(T8850 Cat 1). Mergify does not auto-merge in this fleet, so today this
is an advisory check-run.
π€ Generated by [robots](https://vyos.io)
|
|
Add the blessed 3-condition bot exclusion (-author~=\[bot\]$,
author!=copilot-swe-agent, author!=vyosbot) to the two convention
labeling rules so bot-authored PRs aren't gated by human title/body
conventions. Mirrors the live Auto-assign PR author rule. Part of the
uniform bot-excluded protections rollout (IS-531).
π€ Generated by [robots](https://vyos.io)
|
|
per-repo) (#18)
|
|
π€ Generated by [robots](https://vyos.io)
|
|
Tracking: T8943
|
|
feat: add base-branch labeling + author-assign rules (T8937)
|
|
Adds 5 new pull_request_rules to the central Mergify config:
- 4Γ Label PR with <equuleus|current|circinus|sagitta> β replaces
vyos/.github:add-pr-labels.yml (consumes the same baseβlabel mapping
from labeler.yml). Uses toggle: for base-retarget cleanup; omits
-closed so labels persist post-merge for triage history.
- 1Γ Auto-assign PR author β replaces vyos/.github:assign-author.yml.
Uses -author~=\[bot\]$ to skip GitHub App-bot identities, plus
explicit exceptions for copilot-swe-agent and vyosbot (legacy PAT).
PR stale migration was DEFERRED (see Phorge T8937 + spec Β§2)
because Mergify's own label/comment activity bumps updated_at,
producing a self-unstaling cycle that breaks parity with
actions/stale@v10. PR + issue stale stay in vyos/.github:check-stale.yml.
Advances: T8937
π€ Generated by [robots](https://vyos.io)
|
|
feat(close): auto-close PRs targeting EOL release branches (sagitta, crux, circinus)
|
|
mergify: T8935: gate merge on conflicts + invalid-title labels
|
|
Add a `pull_request_rules` entry that closes every PR (and Mergify-
created backport) opened against the EOL release branches `sagitta`,
`crux`, or `circinus` in any vyos/* repo extending this config.
Excludes vyos-documentation (still accepts per-branch docs backports
to sagitta and circinus) and vyos.vyos (Ansible Galaxy collection
on `main`; listed defensively).
Replaces vyos/vyos-1x:.github/workflows/pr-auto-close.yml, which only
covered sagitta. Centralizing in Mergify removes per-repo workflow
drift and extends coverage to crux and circinus.
Uses Mergify's `repository-name` condition attribute (bare repo name,
no org prefix) β unambiguous because this central config is consumed
only by vyos/* repos via `extends: mergify`.
|
|
Promote two existing auto-applied labels from informational to
merge-blocking via Mergify merge_protections, mirroring the existing
backport-conflict gate:
- `conflicts` β applied by the central `Label conflicting pull
requests` rule (Mergify's built-in `conflict` attribute = GitHub's
`mergeable_state == "dirty"`) and by
vyos/.github:scripts/check-pr-conflicts.py (committed conflict
markers on non-Mergify PRs).
- `invalid-title` β auto-toggled by the central `Flag T-ID format
violation in PR title or commit messages` rule when the PR title or
any commit's first line does not match `[scope: ]T<digits>: <text>`.
Both labels were applied but did not block merge unless the consumer
repo had a corresponding required-status-check or branch-protection
ruleset. This change makes the central baseline enforce the gate via
Mergify's merge_protections, with per-repo override available via
same-named child rule (per Mergify `extends:` inheritance semantics).
Verified via /mergify-config-check (all six known schema/keyword
gotchas PASS) and Phase 0 local CodeRabbit (clean).
|
|
feat(commands): allow vyos-bot[bot] App identity as Mergifyio sender
|
|
The mirror-pipeline App vyos-bot[bot] issues @Mergifyio backport
commands as part of the algorithm's step 6. Under the prior PAT auth,
the comment author was the `vyosbot` GitHub user account, which the
existing third allowlist condition matches. Under the new App auth
(rolled out as Mirror Pipeline Rollout 1), the author is the App
identity vyos-bot[bot] β distinct from the user, no team membership.
Mergify currently rejects with 'Command disallowed due to command
restrictions'.
Empirically verified on canary VyOS-Networks/mirror-canary#6 on
2026-05-26: Mergify rejected the App's command with the exact format
that lists the three currently-allowed senders. Adding this fourth
condition allows the App to issue all 9 Mergifyio slash commands
(backport / copy / dequeue / queue / rebase / refresh / requeue /
squash / update) via the shared YAML anchor.
`sender=vyosbot` (the legacy user identity) is RETAINED here β
Rollout 1's staggered migration leaves some consumers on PAT during
Tasks 5-10. Removing `vyosbot` is deferred to 1b Task 12 cleanup,
after Task 11 PAT revocation.
Parent plan: ~/.claude/plans/2026-05-26-mirror-mergify-app-allowlist.md
Canary evidence: ~/.claude/plans/2026-05-26-mirror-rollout-1a-expanded-canary-tests.md Task B.1.5
|
|
ci(mergify): upgrade configuration to current format
|
|
T8595: add AGENTS.md + Copilot symlink for the vyos-org central Mergify baseline
|
|
Both the project-purpose summary (line 5) and the Conventions note (line 38)
incorrectly stated `ignore_conflicts: false`; .mergify.yml has had
`ignore_conflicts: true` (with label_conflicts + assignees as compensating
controls) since the incident post-mortem. Update both lines to match.
Agent-Logs-Url: https://github.com/vyos/mergify/sessions/68cbfb22-2a97-46af-b2fd-4161c6236f74
Co-authored-by: andamasov <12631358+andamasov@users.noreply.github.com>
|
|
Authority: T8595 (AGENTS.md fleet rollout).
π€ Generated by [robots](https://vyos.io)
|
|
|
|
T8782: Document Depends-On built-in merge protection in central config
|
|
CodeRabbit on the mirror PR (VyOS-Networks/mergify) flagged that the
literal `vyos/vyos-1x#5191` example contradicts the documented same-
organization constraint when read in the VyOS-Networks context. Swap
both central configs to a generic `owner/repo#42` placeholder so the
block reads identically in either org and the example never contradicts
the constraint.
π€ Generated by [robots](https://vyos.io)
|
|
Add a documentation comment block above `merge_protections:` so
contributors reading the central Mergify config can discover the
`Depends-On:` PR-body feature without spelunking Mergify's docs.
The protection is built-in: Mergify parses `Depends-On:` lines from
the PR description and blocks merge until every referenced PR has
merged. No YAML is required to enable it, so this is a docs-only
change.
The block covers:
- the three accepted reference syntaxes (#N, owner/repo#N, full URL)
- the same-org / Mergify-enabled constraints
- cross-branch `@Mergifyio refresh` caveat (quoted from docs)
- hypothetical merge-queue interaction (theoretical β no consumer
repo in either org defines queue_rules as of 2026-05-15)
- explicit note that no condition attribute exposes dependency
satisfaction, so `pull_request_rules` cannot label by it
Will be mirrored byte-identical to VyOS-Networks/mergify in a paired
PR (see prior central-config pairs: #7+#5, #8+#6).
π€ Generated by [robots](https://vyos.io)
|
|
T8782: Add opt-in auto-update rule for stale PRs (label=auto-update)
|
|
When a PR carries the `auto-update` label and has at least one commit
behind its base branch, merge the base into the PR via the `update`
action. Skipped on drafts, conflicts, closed/merged, and
`backport-conflict` so the rule doesn't interfere with the conflict
workspace.
Why `update` and not `rebase`:
1. Fork-safe β `rebase` loses fork support 2026-07-01 per Mergify
docs; `update` works on fork PRs indefinitely. Important for
vyos/vyos-1x and vyos/vyos-documentation community contributions.
2. Mirror-pipeline-safe β gen-1 cross-org mirroring (vyos β VyOS-
Networks) copies refs by SHA. Rebase rewrites SHAs and would
create mirror noise or break consumer PRs. `update` preserves
SHAs.
3. CI-cache-friendly β one new merge commit triggers one re-run;
rebase changes every SHA and re-runs the entire PR.
Opt-in via label so this isn't a fleet-wide behavior change. Repos
that want it apply the `auto-update` label to PRs (per-PR or via
per-repo default-label automation); repos that don't, ignore the
rule.
|
|
T8782: Restore backport conflict workspace via label_conflicts and assignees
|
|
Mergify schema validation rejected the prior commit with
`Field required @ root β merge_protections β item 0 β if`. The `if:`
clause scopes when the rule applies; without it the entry is invalid.
Now `if: - label = backport-conflict` so the rule applies only when the
label is present, and `success_conditions: - label != backport-conflict`
fails whenever the rule applies β merge blocked while the label is set.
No behavior change vs. intent β purely fixing schema compliance.
|
|
merge_protections
Add a merge_protections rule requiring `label != backport-conflict` for
merge. The backport action above auto-applies the label on cherry-pick
conflicts, so this closes the loop: the conflicted PR exists (workspace
preserved), is labeled and assigned, AND cannot be merged until the
operator pushes a resolution and removes the label manually.
Per Mergify docs, merge_protections from `extends:` merges across parent
and child with same-name override semantics; consumer repos can opt out
by defining a same-named rule locally with weaker conditions.
`dequeue` is not exposed as a YAML action under pull_request_rules β only
as a user-facing slash command and a key under commands_restrictions.
merge_protections is the declarative equivalent. Manual `@Mergifyio
dequeue` remains available to Maintainers via commands_restrictions.
Active ejection of an already-queued PR when the label arrives vs.
holding the PR indefinitely in queue is not explicitly documented by
Mergify; the comment marks this as TBD on first real backport conflict.
|
|
Re-enable PR creation on backport cherry-pick conflicts (ignore_conflicts:
true) and add label_conflicts: backport-conflict + assignees: ["{{ author }}"]
so the conflicted PR is discoverable and accountable instead of silent.
The prior ignore_conflicts: false (set after vyos-documentation#1994 β
#1998/#1999 shipped conflict markers) stopped silent merges but eliminated
the workspace where conflicts could be resolved. With this config the PR
exists, carries a distinct label (backport-conflict, not the base-merge
`conflicts` label), and pings the source PR author.
The label itself does not block merge β fleet-wide enforcement (required
CI catching <<<<<<< markers, or branch-protection ruleset on the label)
is governance work tracked under T8850 Cat 1, not central config.
|
|
Allow @VyOS-Networks/maintainers to run Mergify commands
|
|
Add `sender=@VyOS-Networks/maintainers` to the shared
`commands_restrictions` block so VyOS-Networks Maintainers can issue
@Mergifyio slash commands when this central config (or any per-repo
config copying its conditions) is encountered on the VyOS-Networks
side of the cross-org mirror.
Mergify evaluates each `or:` branch independently. A team reference
from a different org evaluates to a non-match with a surfaced warning
("Team @<org>/<team> is not part of the organization <repo-org>")
but does not fail the rule. So on vyos org PRs, `@vyos/maintainers`
still matches normally and the cross-org entry is benign.
Incident: VyOS-Networks/vyatta-cfg#33. The T8531-era inline config
in `.github/mergify.yml` only listed `@vyos/maintainers`, and after
the cross-org mirror pipeline replicated it to VyOS-Networks,
`@Mergifyio backport` from a VyOS-Networks Maintainer was rejected.
Pairs with vyos/vyatta-cfg#134 (migration to `extends: mergify`) and
the matching change to VyOS-Networks/mergify.
π€ Generated by [robots](https://vyos.io)
|
|
Use single `invalid-title` label for both title and commit-message rules
|
|
The previous revision of this PR moved both rules' `toggle` action to
the same `invalid-title` label but kept them as two separate rules.
That has a structural conflict: each `toggle` rule fires in both
directions on every evaluation (add when condition true, remove when
false). When the title conforms but a commit doesn't (or vice versa),
the two rules issue conflicting add/remove operations on the same
label β order-dependent and likely to flap.
Mergify's `toggle` docs frame the action as a single-rule pattern
that subsumes the earlier two-rule "add on match / remove on
inverse" idiom (mergify changelog 2022-11-15). Using `toggle` on two
rules pointing at the same label is outside the documented use case.
Collapse the title-check condition and the commit-message-check
condition into one rule with an `or`-combined condition. One rule,
one label, one toggle β no conflict. The diagnostic separation
between "title failed" vs "commits failed" was already given up when
the label was unified; the rule description still lists both
surfaces so an operator reading the rule log knows what to look at.
π€ Generated by [robots](https://vyos.io)
|
|
The two PR-message-format rules check the same `T<digits>: <text>`
headline regex against two surfaces β the PR title and each commit's
first line. Splitting that into two labels (`invalid-title` +
`invalid-commit-title`) creates near-identical labels on the same PR
and adds no information for the author: the fix in both cases is
"rewrite the headline to match the format."
Collapse onto `invalid-title`. The two rules stay separate so an
operator scanning rule logs can still see which surface tripped, but
the user-facing surface gets one label.
π€ Generated by [robots](https://vyos.io)
|
|
T8782: add central Mergify baseline for vyos org
|
|
Adds two `pull_request_rules` that flag PRs whose title or commit message
headlines do not match the required T-ID format:
^(([a-zA-Z0-9\-_.]+:\s)?)T\d+:\s+[^\s]+.*
Examples that pass:
- `T99999: make IPsec secure`
- `dhcpv6: T8849: Add time-zone support for Kea DHCPv6`
Failing PRs get one of two labels:
- `invalid-title` β PR title does not conform
- `invalid-commit-title` β at least one commit's first line does not
conform
This replaces the reusable workflow at
vyos/.github/.github/workflows/check-pr-message.yml and the per-repo
caller workflows that invoke it. Coverage is dormant in any repo until
it adopts `extends: mergify` in its own `.mergify.yml`; until then the
existing GHA continues to run unchanged.
Implementation notes:
- Mergify exposes only `commits[*].commit_message` (full message, not
headline-only), but default Python `re` flags make `^` = start-of-
string and `.*` non-newline-matching, so `^<pattern>` effectively
checks the first line β equivalent to the GHA's `messageHeadline`.
- Because `commits[*]` returns true on ANY-match and Mergify has no
`!~=` operator, the commit-message rule uses a negative-lookahead
regex that fires when at least one commit's first line does NOT
conform.
- Regex verified locally against representative valid samples (5 pass)
and invalid samples (6 caught, including `Bump foo from 1.2.3 to
1.2.4` and `Merge pull request #...` β same behavior as the existing
GHA, no regression).
Migration sequence (out of scope for this commit):
1. This PR lands; rules dormant.
2. Per-repo PRs add `extends: mergify` (vyos-documentation PR #2005
is the first canary).
3. After parallel coverage confirms equivalence, retire per-repo
check-pr-message.yml callers and the central reusable workflow
in vyos/.github.
π€ Generated by [robots](https://vyos.io)
|
|
Flip Mergify default from "commit conflict markers and open PR labeled
`conflicts`" to "fail the backport, comment on source PR, create no
destination PR." See in-file comment for the 2026-05-12 incident in
vyos/vyos-documentation (#1994 β #1998/#1999 β conf.py markers merged β
RTD `SyntaxError`) that drove this.
Also fix stale `mergify-config` references in the header comment to
match the repo rename (2026-05-09).
This default is dormant for any repo until it adopts `extends: mergify`
in its own `.mergify.yml`. The ~140 existing per-repo configs from
T8531/T8615 are unaffected by this change.
π€ Generated by [robots](https://vyos.io)
|
|
Adds `.mergify.yml` carrying the shared `commands_restrictions` block
(9 keys: backport, copy, dequeue, queue, rebase, refresh, requeue,
squash, update) and the `Label conflicting pull requests` rule.
Per-repo files will reference this via `extends: mergify-config`.
π€ Generated by [robots](https://vyos.io)
|
|
|
