ci: init pr.yml and merge-queue.yml workflows

[MattSturgeon]

These workflows will serve as top-level entry points for running GHA jobs against PRs and merge groups in the merge queue.

This allows us to have a meta-job "no PR failures" that "needs" all merge requirements. This makes it easier to maintain the "required status checks" ruleset.

Additionally, by having separate workflows for pull_request and merge_group, we can have different "needs" for each.

This is related to #3611, which is adding the first GHA-based check that will need to be "required".

This is based on @wolfgangwalther's excellent work in nixpkgs: merge-group.yml and pr.yml

The PR workflow ran Successfully here: https://github.com/nix-community/nixvim/actions/runs/17108993910/job/48525322498?pr=3628

We won't see the Merge Queue workflow run until this PR enters the queue.

@GaetanLepage you will need to add PR checks successful to the required status checks list in our ruleset. EDIT: the actual status check name may change throughout this PR.

[MattSturgeon]

Rebased and added lint.yml to the required jobs list.

This does mean that lint.yml now runs unconditionally, since there's no paths-ignore equivalent for jobs or workflow_call.

It may be possible to use something like https://github.com/dorny/paths-filter in a prepare job and make the lint job conditional on its output, but I'd rather avoid the complexity for now.

EDIT: ran successfully here: https://github.com/nix-community/nixvim/actions/runs/17108993910/job/48525322498?pr=3628

[khaneliman]

Rebased and added lint.yml to the required jobs list.

This does mean that lint.yml now runs unconditionally, since there's no paths-ignore equivalent for jobs or workflow_call.

It may be possible to use something like https://github.com/dorny/paths-filter in a prepare job and make the lint job conditional on its output, but I'd rather avoid the complexity for now.

EDIT: ran successfully here: https://github.com/nix-community/nixvim/actions/runs/17108993910/job/48525322498?pr=3628

I did add paths-filter to home manager and it works well.

[MattSturgeon]

I did add paths-filter to home manager and it works well.

Good to know 👍🏻

I'll still hold off for now.

One of the main arguments for not linting when specific paths are the only ones modified was that we update flake.lock frequently. However, even in that scenario it is possible that the update is bringing in changes to the formatters themselves, fixes from treefmt-nix, etc.

[wolfgangwalther]

Diff LGTM

[MattSturgeon]

I've just pushed a refactor based on NixOS/nixpkgs#435929, with a few tweaks to wording and formatting.

This now uses @wolfgangwalther's new proposal of manually posting the required status check when the jobs are successful. This should prove simpler than of skipping it when successful and manually failing otherwise.

Being able to manually post status checks requires permissions: statuses: write. IIUC any write permissions require using pull_request_target instead of pull_request, which means taking a bit more care over which revisions are checked out and run.

It also makes it more difficult to test changes to the workflow itself, since PRs will use the base branch's workflow instead of the PR's. That means we won't see it running on this PR, unless we also trigger it via pull_request.

[MattSturgeon]

Optionally, we could combine pr.yml and merge-queue.yml into a single workflow.

We'd need to do things like ${{ github.event.pull_request.head.sha || github.event.merge_group.head_sha }} and it'd be more difficult to specify different checks for PRs vs the Queue.

But it would remove a lot of duplication.

Thoughts?

[wolfgangwalther]

I think it makes a lot of sense to re-use the same file when you can. It looks like this should be easily possible here.

You could even change the run-name so you don't get "PR" for both.

[wolfgangwalther]

Did you leave out the ?pr= suffix out here on purpose? This is a bit annoying when clicking the link, because the "back" link from the summary page won't go to the PR, but to the actions tab.

[MattSturgeon]

Good catch. I copied this from your merge-group.yml without spotting that pr.yml had a different URL.

[wolfgangwalther]

I think it makes a lot of sense to re-use the same file when you can. It looks like this should be easily possible here.

You could even change the run-name so you don't get "PR" for both.

[wolfgangwalther]

One downside of going with the pull_request_target event: Changes to the workflow file now won't be tested in the respective PR anymore. Now you need to start looking into whether to add the pull_request trigger as well.

Overall, it might be simpler to use the non-javascript-status approach here with the old "skipped vs failed job" approach.

[MattSturgeon]

One downside of going with the pull_request_target event: Changes to the workflow file now won't be tested in the respective PR anymore. Now you need to start looking into whether to add the pull_request trigger as well.

Yeah, this is frustrating. Maybe I should consider adding a "testing" on: pull_request trigger to this PR so that it's done.

Overall, it might be simpler to use the non-javascript-status approach here with the old "skipped vs failed job" approach.

I'm of two minds here:

1. On the one hand pull_request is much simpler.
2. On the other hand, if we want to do anything that needs secrets or write permissions then we'll eventually need to switch.
   If so, we may as well do it now and get access to the better "required check" implementation.

I like the idea of the better impl because we can choose a saner name for the required check from the start. It's also less confusing for contributors if we have a green check, rather than a grey one.

[MattSturgeon]

I noticed in #3657 that we have configured the repo to require manual approval before running pull_request workflows on untrusted forks:

Switching to pull_request_target would also resolve this.