core-workflow
core-workflow copied to clipboard
python
Add the `CI` or a wider `github-actions` label
I would like to add the CI label for categorizing issues and PRs focusing on improving or updating CI/GHA related files. A more generic name would be a github-actions label that would target anything related to any kind of github actions (so anything related to pushing buttons automatically or not and hooks automatically triggered by a PR or a merge).
See https://github.com/python/core-workflow/issues/544#issuecomment-2286050457 for an expanded description.
On naming things, what would you like to be covered by this label?
CI is things like running tests. We have:
-
The main testing on GitHub Actions: https://github.com/python/core-workflow/actions
-
There's also buildbot testing: https://buildbot.python.org/
-
And some post-merge testing on Azure Pipelines, mostly to verify Windows installer packaging: https://dev.azure.com/Python/cpython/_build?definitionId=4 (Code is in https://github.com/python/cpython/tree/main/.azure-pipelines)
Would these CI things all be covered by the new label?
CD is things like producing software artifacts. We have:
-
Docs and source build is on GitHub Actions in this repo: https://github.com/python/release-tools
-
Windows installer build on Azure Pipelines https://dev.azure.com/python/cpython/_build?definitionId=21, I think the code is mostly (all?) at https://github.com/python/release-tools
-
We don't currently have automated macOS builds, but it is planned.
-
These mostly (all?) live outside https://github.com/python/cpython repo where this label will be created.
Would these CD things be covered by the label?
Ah yes, I think it will be mainly a CI label. I suggested github-actions because it's essentially "whatever you can trigger by pushing a button" (build bots, tests, workflows, etc). I haven't thought of the CD part actually (just put it in the CI/CD since I didn't really know whether we would have some CD part in cpython) but since the CD tools live outside cpython, I think CI would be better.
Would these CI things all be covered by the new label?
I think so (at least, I don't see why we wouldn't do it). More generally, I'd like to triage those kinds of issues under a common label:
- https://github.com/python/cpython/issues?q=is%3Aissue+sort%3Aupdated-desc+.yml+in%3Atitle
- https://github.com/python/cpython/pulls?q=is%3Apr+sort%3Aupdated-desc+.yml+in%3Atitle
- https://github.com/python/cpython/issues?q=is%3Aissue+sort%3Aupdated-desc+workflow+in%3Atitle+
- https://github.com/python/cpython/pulls?q=is%3Apr+sort%3Aupdated-desc+workflow+in%3Atitle
There are duplicated results since workflow + yml files usually come in pairs. While I understand that there are not a lot of open issues or PRs, I think it's because they are important to be fixed fast (or just invalid). We could also have our bot automatically add the skipnews label for CI issues.
In summary, I'd suggest to forget about the CD part (I was wrong to assume that we would need this part in the CPython repo itself) and keep CI (or github-actions just in case we want a larger category).
By the way, some CI issues are also related to build issues (e.g., a build bot that fails could be considered both a CI and a build issue depending on the failure such as https://github.com/python/buildmaster-config/issues/517, here I would also consider it a CI failure).
Nit: note that "github-actions" limits this to "GitHub-backed CI based on the checked in workflow yml files". In particular, it doesn't cover buildbot, which has nothing to do with GitHub Actions. Maybe that's ok, considering buildbot has its own repo where buildbot-specific issues and PRs live.
note that "github-actions" limits this to "GitHub-backed CI based on the checked in workflow yml files".
For me, GHA was mostly anything I can trigger by a button (or a command, and that I would more or less see in the actions tab/CI table under a PR). But I can live with the CI label too.
FWIW you can get added automatically as a reviewer of GitHub-workflows-related PR by adding your name on the .github line of the CODEOWNERS file. This doesn't work for issues though or other automations though.
I would like to add the
CIlabel for categorizing issues and PRs focusing on improving or updating CI/GHA related files. A more generic name would be agithub-actionslabel that would target anything related to any kind of github actions (so anything related to pushing buttons automatically or not and hooks automatically triggered by a PR or a merge).
Did you consider adding a GitHub Project for this instead of adding a new label?
Mmmh. I don't know what is the policy between choosing a GH project or a label. I observed that some topics are using projects and others are using labels (e.g., there is no topic-logging but there is no typing project). So I don't think it really matters whether it's a label or a project (I personally prefer labels since they are simpler to apply/remove and I see projects as trackers with fine granularity, like todo/pending/done/stalled).
By the way, I've got the idea of this by looking at the issues I was triaging. Some issues/PRs were label-less and were related to workflows. For people that are interested in it, it might help them finding them more easily (most of the time, the PRs is just a skipnews (maybe even a skipissue)). But maybe it was just these past weeks where CI and GHA related issues popped and maybe next week, there won't be any (and the label would then be a bit useless...)
See https://discuss.python.org/t/using-github-beta-projects-in-our-workflow/15090
It's mostly up to who is triaging/handling the given subset of issues. Projects allow for more organization, can include issues/PRs from multiple repos of the same org, can define additional custom fields (e.g. to group them by OS, CI/CD, dependabot, etc.), have multiple views with filtering/sorting, and also provide automations to add issues/PRs that match a certain search query. One major downside is that you can't subscribe to projects and get notified once a new issue/PR is added to it (unless they added this feature recently). Labels are simpler and you can subscribe to them.
In light of the discussion, I think I'm the only one interested in triaging those issues. Instead of creating a label that could not be used anymore, I'd suggest that triagers add to the issue/PR title some (CI) prefix. It would then be easy to find related issues and also we won't pollute the label namespace with a namespace that could only be used sporadically and per periods. If no one objects, I'll close the issue in a few days.
Then I'll keep the issue opened! (sorry if I misunderstood your stand Itamar btw)
I'd also be interested in such a label, once the name has been sufficiently bikeshedded :)
I also think this makes sense. I would call the label "CI" and cover issues such as:
- A GitHub Actions check is failing on all PRs
- A test is failing sporadically in GitHub Actions
- A buildbot is failing
Just found this thanks to @hugovk after trying to define https://github.com/python/cpython/issues/113858
+1 to ci or more generally infra, to add to the shedding of bikes
infra would cover externally hosted services like buildbot, its underlying host, GitHub-related things like dependabot, and also workflows and other .yml configuration.
I don't think there is much benefit to scoping it so narrowly to github-actions unless we also then make another label for other infrastructure related things, but who wants more labels 😅
Some other prior art:
Details
python/peps:
python/pythondotorg (although I may have made that one)
infra won 5-0, here's the new label:
- https://github.com/python/cpython/labels/infra
@JacobCoffee Would you like to open a PR to document it in the devguide?
- https://devguide.python.org/triage/labels/#other-labels
That list is getting longer, let's also alphabetically sort the other entries in that list.
I'll close this issue since we got the label I wanted. Thank you all for the discussion!