docs: clarify behavior of label and commit requirement#4846
Conversation
There was a problem hiding this comment.
IF this is to be documented (which a maintainer has not commented on the linked issue yet) it should live with the rest of issue triage, as the label can only be added by users with triage or greater permissions.
See https://black.readthedocs.io/en/stable/contributing/issue_triage.html
Furthermore, (and the reason it was positioned as whether it may be worth removing), this means both the maintainer has to add the label and then something needs to trigger the commit to check the IF statement.
It definitely is a maintainer decision on whether or not to document it.
|
Hi! I’ve updated the PR with the corrected CI-related label documentation and removed the accidental code block formatting. The duplicate PR has also been closed. Please let me know if any further adjustments are needed. Thank you! |
|
Please read my previous comments, as well as revert the previous change in CONTRIBUTING.md |
|
Hi! @cobaltt7 I’ve finalized the CI label documentation as requested, cleaned up the formatting, and resolved the merge conflicts. |
This PR adds documentation explaining the behavior of the
ci: build all wheelslabel.Why this change is needed
The label exists to trigger a full wheel build on a PR, but GitHub Actions does not automatically rerun CI when a label is added.
This leads to confusion because contributors expect the wheel build to start immediately, but it only works after pushing a new commit.
What this PR adds
CONTRIBUTING.mddescribing:ci: build all wheelslabel,Security and design considerations
This PR intentionally avoids modifying CI triggers because building wheels on label-added events can introduce security issues (e.g., running untrusted fork code with elevated permissions) and heavy CI load.
Adding documentation is the safest and maintainer-aligned solution.
References
ci: build all wheelslabel #4838