feat: add dependency checks to PRs and issues #3298
Conversation
GitHub does not (yet) have the ability to block PRs / issues as dependencies of other PRs issues. This commit uses gregsdennis/dependency-action as a simple workaround. Now, wording like "blocks coreruleset#123" or "depends on coreruleset#123" will add a check for the completion of the dependent PR / issue.
|
This sounds nifty. Will this cover only the initial issue / PR message, only the title, or any comment? @RedXanadu Where do we have to document this? |
|
No, as far as I understand it, the only requirement is that the test is in the PR / issue description, aka the first entry. The action should run when a PR is edited, so edits to the description should also work. I haven't tested it though. |
|
If it happens via a first comment update, that's cool. And I do not mind either way. We just need to know - and document it. |
|
Yes. Although I see this primarily as a tool for us core devs, so putting it in the Wiki is probably enough. |
|
Would not it be part of the documentation that also covers the CI/CD testing? |
|
Is there such a thing? I couldn't find anything in the docs... |
|
I thought @RedXanadu would find something... If not, it may be time to start a new section in one of the docs. |
|
Sorry, late to the party. This should be documented as an option under "Making Changes" in the "Contribution Guidelines", e.g.:
Is that a correct understanding of what has been proposed here? Separately, it would be good for someone to document all of the GitHub Lang stuff that underpins the internal CRS project/repo workings in a wiki page, as I would bet that a majority of CRS devs don't have a clue about it… (I certainly don't). Some internal-facing reference material would be very welcome. Does anyone have both the knowledge and the time to write that? @theseion How does this work for issues, as they have no checks to fail? I tested it on the first comment of an issue and couldn't see a change. (Tested it on a PR and it worked as intended.) |
Yes.
I can help with that, although I'm not sure what you want covered. Can you give me a list of topics?
TBH, I only made it work for PRs. But it should only be a small thing to add to issues. |
|
Hmm… I think that, for any time we use a GitHub Workflow/Action/Automation, we should have an internal note (for the attention of CRS devs) stating what it is and what maintenance or modifications it may need. So, I think a list of topics would be everything we're currently doing with GitHub magic, so that the knowledge can be decentralised. I've added this as a workshop suggestion for the retreat, as I think this would be better as an in-person group discussion/workshop, as the aim should be to spread the knowledge of these Workflows and how they function. |
|
Good idea. Definitely better to discuss in a group. |
GitHub does not (yet) have the ability to block PRs / issues as dependencies of other PRs issues. This commit uses gregsdennis/dependency-action as a simple workaround.
Now, wording like "blocks #123" or "depends on #123" will add a check for the completion of the dependent PR / issue.
New GH action used: https://github.com/marketplace/actions/pr-dependency-check
GH feature request with the currently available workarounds: https://github.com/orgs/community/discussions/4477#discussioncomment-1039627