Enable releases immutability in the repository or org

[nicoddemus]

Recently I learned that GitHub now supports release immutability:

https://github.blog/changelog/2025-10-28-immutable-releases-are-now-generally-available

I think we should enable this for pytest, or even perhaps organization wide.

[bluetech]

Sounds good to me. I checked the deploy workflow and I think it should be OK, though we might want to do the github release in two steps - draft and publish. That's what github recommends though I'm not sure if it applies to the CLI.

[bluetech]

I checked and gh release create uses a draft to upload assets, so it should be good: https://github.com/cli/cli/blob/c0d5f164f20b66b314d71a9ef2a01573e0c156f0/pkg/cmd/release/create/create.go#L508-L510

I think we should enable this for pytest, or even perhaps organization wide.

Organization wide might be too ambitious. There's a chance it will break some repos.

[Pierre-Sassoulas]

Organization wide might be too ambitious. There's a chance it will break some repos.

It forces to do another release if you miss click, which is a small price to pay to guarantee against the crafty things a bad actor (not the actual maintainer, someone who got a hold of their credentials) can do by redefining the content of a tag after the fact. So I would say it certainly fixes a supply chain vulnerability (at a very small cost, I don't think there's automation in place to rewrite tags in case of mistake ?).

[bluetech]

The main thing I think might break is creating the release and then uploading files to it afterwards. pytest doesn't do it but other projects in pytest-dev might.

[nicoddemus]

How about enabling org-wide for security, and see how it fares? From a security POV, might make sense to at least try to adopt the "good practice" org-wide if possible.

[bluetech]

Maybe if we announce it first. I'm not sure how to do it, maybe we can enable "Discussions" in the github organization level and announce it there? Or maybe scan all repos in the org which use github releases and ping their admin teams?

[Pierre-Sassoulas]

What if we offered help to update the "release on tag" github actions ? I think it's a copy paste of the release.yml + asking the maintainer to set up a pypi token variable in the setting ? A MR is less disruptive than adding discussion on the repo, and that way the release is unified org wide. Or maybe the use case of adding files after the release is not a big blocker and we do nothing and see how it goes like Bruno suggested ?

[nicoddemus]

FTR I don't think many plugins use GitHub releases -- I have the impression most just publish to PyPI. But this is just an impression, and I'm out of time at the moment to scan the repositories myself.

[RonnyPfannschmidt]

Afzer the setuptools scm 10 release o can volunteer to overhaul everyones automation

[Pierre-Sassoulas]

On top of making the immutable tag option painless, this release action would be a huge time saver for everyone + quality of life improvement for users. For example, in pytest-html a release is required and it's been stalled for 2 weeks. No doubt that if a release on tag with setuptools_scm was available I would have released myself 3 weeks ago. So I'm also available to add some release.yml into place.