Update plugin list on maintenance branch to keep stable docs current

[dyollb]

Summary

docs.pytest.org/en/stable is built from the maintenance branch (e.g. 9.0.x), not main. The weekly plugin list update only targets main, so stable docs show a frozen plugin list from the release cut.

Fix

Update the workflow to:

1. Find the current maintenance branch dynamically (highest N.N.x)
2. Run the same plugin list update
3. Create a PR to main and apply backport <branch> label
4. Patchback automatically cherry-picks the PR to the maintenance branch once merged

This uses pytest's existing backport automation, avoiding merge conflicts and duplicate logic.

Also adds missing if guard to the "Instruct maintainers" step to prevent failures when there are no plugin list changes.

[nicoddemus]

Thanks @dyollb!

However I fear this might create merge conflicts when we need to merge the maintenance branch back into main after a release.

What if we just apply the appropriate "backport" label to the PR that is created to main? I this would remove the chance of conflicts, as backports are cherry-picked.

[bluetech]

Alternatively, add a note at the top saying to look at /latest

[RonnyPfannschmidt]

a workflow that auto sync it may be more fitting - we dont need to backport like a patch - we can jsut take the verbatim content and update the blob

[nicoddemus]

we dont need to backport like a patch

We "don't", but might be the simplest solution.

[dyollb]

Thanks @dyollb!

However I fear this might create merge conflicts when we need to merge the maintenance branch back into main after a release.

What if we just apply the appropriate "backport" label to the PR that is created to main? I this would remove the chance of conflicts, as backports are cherry-picked.

I tried to change the PR to use your label approach. Is this what you meant? Thanks

[nicoddemus]

Yes it is, thanks!

Could you take a look at the linting failures please? It suggests it can auto-fix the issues if ran locally.

[nicoddemus]

Thanks!

I will merge this tomorrow to give time for others to speak up in case they have concerns with this approach. 👍

[The-Compiler]

The approach seems fine to me, iff it actually works (there are some limitations regarding labels added automatically then triggering automated workflows again, afaik). @webknjaz any thoughts?

I have one suggestion regarding tooling, but no hard feelings either way.

[The-Compiler]

Suggested change

	branch=$(git ls-remote --heads https://github.com/pytest-dev/pytest.git \
	| grep -oE 'refs/heads/[0-9]+\.[0-9]+\.x' \
	| sed 's|refs/heads/||' \
	| sort -t. -k1,1n -k2,2n \
	| tail -1)
	branch=$(git ls-remote --heads --sort=v:refname https://github.com/pytest-dev/pytest.git 'refs/heads/*.x' \
	| sed '$!d;s|.*\trefs/heads/||')

to use the existing capabilities of git ls-remote and sed (sed one-liners is great for this).

[dyollb]

1. Switched branch discovery to the reviewer’s version-sorted command
2. Added fail-fast validation so the job exits clearly if no *.x branch is found
3. I also tightened the label step guard so it only runs when both PR number and branch are present

[dyollb]

The approach seems fine to me, iff it actually works (there are some limitations regarding labels added automatically then triggering automated workflows again, afaik). @webknjaz any thoughts?

I have one suggestion regarding tooling, but no hard feelings either way.

As far as I understand:

• If automation depends on another GitHub Actions workflow triggered by label events, labels added by a workflow token can be skipped due to recursion protections.
• In this repo, backporting is handled by Patchback config in patchback.yml, which indicates an app-style backport flow, not a local Actions workflow. That usually avoids the specific recursion limitation.

[nicoddemus]

Thanks @dyollb!

Triggered a run: https://github.com/pytest-dev/pytest/actions/runs/27685939056/job/81884534201

[nicoddemus]

Hmmm:

Run gh pr label add "$PULL_REQUEST_NUMBER" --repo 'pytest-dev/pytest' --labels "backport $BRANCH_NAME"
  
unknown flag: --labels

Actually there is no gh pr label command, we probably need gh pr edit --add-label.

My bad, I assumed the command was verified before the PR was submitted, but I should have verified this myself.

[nicoddemus]

Follow up: #14616