search

python / core-workflow

Issue tracker for CPython's workflow
https://mail.python.org/mailman/listinfo/core-workflow
Apache License 2.0
93 stars 60 forks source link

Add the `CI` or a wider `github-actions` label #544

Open picnixz opened 1 month ago

picnixz commented 1 month ago

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.

hugovk commented 1 month ago

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?

picnixz commented 1 month ago

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:

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).

itamaro commented 1 month ago

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.

picnixz commented 1 month ago

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.

ezio-melotti commented 1 month ago

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.

erlend-aasland commented 1 month ago

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).

Did you consider adding a GitHub Project for this instead of adding a new label?

picnixz commented 1 month ago

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...)

ezio-melotti commented 1 month ago

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.

picnixz commented 4 weeks ago

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.

itamaro commented 4 weeks ago

I'm also interested in a CI or github-actions label

picnixz commented 4 weeks ago

Then I'll keep the issue opened! (sorry if I misunderstood your stand Itamar btw)

hugovk commented 4 weeks ago

I'd also be interested in such a label, once the name has been sufficiently bikeshedded :)

JelleZijlstra commented 4 weeks ago

I also think this makes sense. I would call the label "CI" and cover issues such as: