ci: add a workflow for issue and PR validation - #1061

Thanks for putting this workflow together! The overall idea looks good, and I think this will be really helpful to enforce the contributor workflow around issue assignment and PRs.

I have a few suggestions to make the workflow more robust and easier to maintain:

Required changes

• Use the repository's label naming convention

  • Replace needs-issue with Needs Issue.
  • Replace needs-assignment with Needs Assignment.

  This follows the label naming pattern already used in the repository. Please make sure the exact capitalization is used consistently throughout the workflow.

• Create the labels before enabling the workflow
  The Needs Issue and Needs Assignment labels need to exist in the repository before this workflow runs. Otherwise, the gh pr edit --add-label / gh issue edit --add-label commands can fail and cause the workflow to break.

• Remove the warning comments once the problem is resolved
  If a PR initially has no linked issue, the workflow adds a comment asking the contributor to link one. Once the PR is updated and an issue is correctly linked, that comment should be removed.
  The same applies to the assignment check: if the workflow previously reported that the issue was unassigned or assigned to someone else, the corresponding comment should be removed once the issue is correctly assigned to the PR author.
  I'd recommend using a sticky comment with a stable header for this rather than searching for the comment text. The validate-pr-title-v1.yml workflow is a good reference for this approach.

• Trigger the workflow when the issue assignment changes
  At the moment, the workflow is triggered only by PR events. However, assigning or reassigning an issue is an issue event.
  For example, if a contributor opens a PR while the issue is unassigned and then assigns the issue to themselves, the workflow won't run again. We should add the appropriate issues event so that changes to the assignment trigger the validation.
  This should work in both directions: assigning the issue to the PR author should clear the Needs Assignment state, while reassigning it to someone else should add it again.

Suggestions for robustness and maintainability

• Use GitHub's linked-issue information instead of parsing the PR body manually.
  gh pr view already exposes the closingIssuesReferences field, so we can use that to retrieve the issue linked to the PR instead of maintaining our own regex for close, fix, resolve, etc. This makes the validation simpler and avoids duplicating GitHub's issue-linking logic.
  For example:

  ISSUE_NUMBER=$(gh pr view "$PR_NUMBER" \
    --json closingIssuesReferences \
    --jq '.closingIssuesReferences[0].number // empty')

• Consider checking all assignees instead of only the first one.
  GitHub issues can have multiple assignees, so using .assignees[0] may incorrectly report the issue as not assigned to the PR author when the author is assigned but is not the first assignee.

• Handle changes to the linked issue.
  If a PR is initially linked to issue A and later updated to link to issue B, we should make sure labels and comments associated with issue A are cleaned up. Otherwise, the old issue could be left with a stale Needs Assignment label or warning comment.

• Consider simplifying the workflow structure.
  I think it would be useful to structure the workflow around the two validations, with each validation following the same pattern:

  1. Get the current state — identify the linked issue and retrieve the information needed for the validation.
  2. Validate the state — determine whether the PR currently satisfies the requirement.
  3. If the validation fails — add the appropriate label and create/update the corresponding sticky comment.
  4. If the validation succeeds — remove the label and remove the corresponding sticky comment.

  This makes the workflow behave in a self-healing way: every time it runs, it brings the PR/issue state back to the state that matches the current validation result.
  It would also be good to avoid duplicating the same label/comment logic for the different failure cases. For example, the "unassigned" and "assigned to someone else" cases can share the same state-management logic while only changing the message.
  More generally, I strongly recommend using the cumbucadev/shared-workflows repository as the main reference when structuring this workflow. The workflows there follow the patterns and conventions we want to use: they are generally clear, clean, and organized, with the validation logic and error handling kept easy to follow.
  Since the intention is to eventually move this workflow into shared-workflows as well, following the existing patterns and best practices there from the beginning will make the transition much easier and keep the workflows consistent across the repository.

Overall, I think the workflow is going in a good direction. Most of these changes are about making the validation state self-healing and keeping the implementation consistent with the patterns we already use in shared-workflows.

@camilamaia @niltonpimentel02 I'm having a problem revalidating the pull request after assigning the author. For some reason, the workflow doesn't run, just like when I set the issue events as triggers.
At the moment, I've tested at https://github.com/[Joaolpridolficarvalho/teste](https://github.com/Joaolpridolficarvalho/teste). But it's so dirty. I'll clean it.

@Joaolpridolficarvalho the link returns 404 for me

@Joaolpridolficarvalho the link returns 404 for me

This should work.
https://github.com/Joaolpridolficarvalho/teste

Done.