Use (test)pypi in Trusted Publishing placeholder for GitHub Environments
#17036
Conversation
…ments GitHub Environments is a confusingly explained feature within GitHub that represents deployment targets. When projects get uploaded to PyPI — that a deployment target; same for TestPyPI. They don't represent processes but server-like entities. So using `release` is conceptually incorrect and gives people the wrong idea of what it is. This is actually connected to Deployments API (and corresponding events) on the GitHub platform. The name Environments is just a misleading interface to describe Deployments that appears in some parts of the ecosystem, like GitHub Actions CI/CD. In other places, it's called deployments and there's even a tab in repositories using it: https://github.com/cherrypy/cheroot/deployments/pypi. Each deployment can be linked to the corresponding released project version URL. This patch attempts to align the practices with those used in the PyPUG guide and GitHub docs: actions/starter-workflows#2345.
webknjaz
added
translation
|
@woodruffw we talked about this in the past, I finally got a minute to try to update it. Are there any other places? Also, feel free to take over if something needs updating. I made changes from browser, so there's no translation template file updates. |
Thanks for doing this! I think those are the main places. If you'd like, you can give me the commit bit on your fork and I'll run |
|
Oh, I thought |
|
@woodruffw invited! |
Only for real maintainers, I am merely a lowly triager 😉 |
Signed-off-by: William Woodruff <[email protected]>
|
Oh, so I'll ask Mike for review too, then. I also only have triage IIRC :) |
|
Not sure if the same makes sense for GitLab. I haven't used it in a while so I didn't attempt updating. Somebody who knows the GL concept mapping should evaluate that, I think. |
The deployment target name `release` is confusing (and a lot of people don't realize that GitHub Environment doesn't refer to a process but rather to the deployment platform). I already fixed this in the Warehouse placeholders, its docs and most other places in the ecosystem. Refs: * pypi/warehouse#17036 * https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ * https://github.com/actions/starter-workflows/pull/2345/files#diff-d0d0af2177759eaa8fa1abff177e78f3f0a157756500999200b0d7888c19133aR52
The deployment target name `release` is confusing (and a lot of people don't realize that GitHub Environment doesn't refer to a process but rather to the deployment platform). I already fixed this in the Warehouse placeholders, its docs and most other places in the ecosystem. Refs: * pypi/warehouse#17036 * https://packaging.python.org/en/latest/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ * https://github.com/actions/starter-workflows/pull/2345/files#diff-d0d0af2177759eaa8fa1abff177e78f3f0a157756500999200b0d7888c19133aR52
GitHub Environments is a confusingly explained feature within GitHub that represents deployment targets. When projects get uploaded to PyPI — that a deployment target; same for TestPyPI. They don't represent processes but server-like entities. So using
releaseis conceptually incorrect and gives people the wrong idea of what it is.This is actually connected to Deployments API (and corresponding events) on the GitHub platform. The name Environments is just a misleading interface to describe Deployments that appears in some parts of the ecosystem, like GitHub Actions CI/CD.
In other places, it's called deployments and there's even a tab in repositories using it: https://github.com/cherrypy/cheroot/deployments/pypi. Each deployment can be linked to the corresponding released project version URL.
This patch attempts to align the practices with those used in the PyPUG guide and GitHub docs/starters: https://packaging.python.org/guides/publishing-package-distribution-releases-using-github-actions-ci-cd-workflows/ / actions/starter-workflows#2345.
Additionally, this patch deletes the i18n marker, as I believe it shouldn't have been made translatable in the first place.