Skip to content

add pre-triage linked issue check and labeling#50075

Closed
shawkins wants to merge 1 commit into
keycloak:mainfrom
shawkins:pre-triage-pr
Closed

add pre-triage linked issue check and labeling#50075
shawkins wants to merge 1 commit into
keycloak:mainfrom
shawkins:pre-triage-pr

Conversation

@shawkins

Copy link
Copy Markdown
Contributor

Draft of a pre-triage check as a workflow - but there wasn't yet a complete discussion of the expectations for this, so this is more for additional discussion / refinement than a fully working concept.

nearform-actions/github-action-check-linked-issues automates the linked issue check. It seemed to be the best out of several options for this task, but does not appear to be undergoing additional refinements. It only understands linked issues referenced in the PR description. See https://github.com/nearform-actions/github-action-check-linked-issues for all options - which include checking for a no-issue label to skip the check. The end result with no linked issue is a comment and a failing check.

lewagon/wait-on-check-action give us the ability to use the outcome of the dco check in a workflow. Here I'm prototyping adding or removing a lable based upon the outcome of the DC and linked issue check - but if that is not needed it can certianly be removed.

Signed-off-by: Steve Hawkins <shawkins@redhat.com>

@stianst stianst left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know this is a bit extra effort, but I'd prefer not to use "random" github actions, and stick mostly to actions from trusted sources like github.

Shouldn't be that hard to do a bash script that checks the commit message and PR message both contain a link to an issue (and the same issue). We should also check that the issue is open, and not closed.

I also think we perhaps should be a bit more strict in terms of how issues are linked.

  • Should be on a separate line
  • Closes #123 and not Closes: #123
  • Closes #123 and not closes #123
  • Closes should be used for single issue in the same repo
  • Fixes - should not be used as the GH docs states this is for issues in a different repo; we don't do that
  • Resolves #123, resolves #321 - GH docs states to use this when there are multiple issues, not sure how relevant this is. Do we often do this?

Main argument for more strictness here is consistency and more importantly simplifying creating other tools/automation around issue linking.

@shawkins

Copy link
Copy Markdown
Contributor Author

@stianst no problem, I'll see what rolling our own solution looks like.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants