-
-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the CI
or a wider github-actions
label
#544
Comments
On naming things, what would you like to be covered by this label? CI is things like running tests. We have:
Would these CI things all be covered by the new label? CD is things like producing software artifacts. We have:
Would these CD things be covered by the label? |
Ah yes, I think it will be mainly a
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:
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 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 python/buildmaster-config#517, here I would also consider it a CI failure). |
CI/CD
or a wider github-actions
labelCI
or a wider github-actions
label
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. |
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 |
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). |
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 |
I'm also interested in a CI or github-actions label |
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:
|
Just found this thanks to @hugovk after trying to define python/cpython#113858 +1 to I don't think there is much benefit to scoping it so narrowly to Some other prior art: |
I'll create a label tomorrow. 👍 this comment to vote for |
👍 this comment to vote for |
@JacobCoffee Would you like to open a PR to document it in the devguide? 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! |
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 agithub-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 #544 (comment) for an expanded description.
The text was updated successfully, but these errors were encountered: