GHA: Sort pull requests to correct column

[SAUMILDHANKAR]

Dependency

• Epic: Project migration from classic to beta #3265

Overview

As a developer, we have to ensure that our Kanban board is organized for all teams so that productivity is high. For this issue, we are creating a GitHub action that will change the status-column of each Pull Request (PR) based on its review progress.

Details

Currently, the following status-columns in our Project Board have been set-up such that the PRs move within these status-columns based on project automations:

Automated Column, do not place items here manually

• PR Needs review
• PRs being reviewed
• PRs ✅ waiting for merge team

However, this hasn't been working as desired and we have decided to use different status-column names with a GitHub action/s to sort the PRs appropriately. The new PR status-columns would be:

• PR Needs review
• PRs being reviewed
• PRs needing changes from author
• PRs ready for re-review (from the original reviewer)
• PRs ✅ waiting for merge team

Action Items

• Review how PRs currently move within different status-columns in our Project Board, paying attention especially to the Workflows affecting PRs.
• Create/ change the status-columns suggested above in your repo.
• Use the available Workflows and when needed create a GitHub action/s which would move the PRs among different status-columns accordingly.
• Demo your results in a team meeting.
• Once your demo is approved by the technical leads, change the names and add new new status-columns in our Project Board
• Create a PR for the newly created GitHub action to be merged.
• For merge team: Release dependency on Create a wiki page for details on new PR columns #3227
  • Update "Action Items" in the dependency issue if needed.
  • Remove the Dependency label, move the issue to the "New Issue Approval" status-column and add a Ready for Prioritization label.
• For merge team: Once the pull request associated with this issue is approved and merged, please change the name of the status-columns and/or sort the issues into the appropriate status-columns.
  • Finally delete any of the status-columns that are no longer being used.

Pseudo Code

• NOTE: This is covered by an existing Workflow, change the status-column name. When a new PR is added to the Project Board, it should automatically move to "PRs needing a reviewer assigned" status-column.
• NOTE: This is covered by an existing Workflow, change the status-column name. If the reviewer requests changes in the PR, the PR should move to "PRs needing changes from authors" column
• NOTE: This will need to be addressed by a GHA: When PR author requests re-review from the original author, the PR should move to "PRs ready for re-review (from the original reviewer)" status-column
• NOTE: Check whether the existing Workflow covers this condition, and if so change the status-column name. Otherwise address with a GHA. If 2 reviewers have already approved the PR, the PR should move to "PRs approved, waiting for merge team to merge" status-column

Resources/Instructions

Never done GitHub actions? Start here!
Events that trigger workflows
Workflow syntax for GitHub Actions
actions/github-script
GitHub RESTAPI
GitHub GraphQL
Encrypted secrets

Architecture Notes

• Refer to Hack for LA's GitHub Actions (current)

• Currently, we want our GitHub Actions to be structured like so based on this proposal:

• Schedules (military time)
  - Schedule Friday 0700
  - Schedule Daily 1100
  - Schedule Monthly

• Linters
  - Lint SCSS

• PR Trigger
  - Add Linked Issue Labels to Pull Request
  - Add Pull Request Instructions

• Issue Trigger
  - Add Missing Labels To Issues

• WR - PR Trigger
  - WR Add Linked Issue Labels to Pull Request
  - WR Add Pull Request Instructions

• WR - Issue Trigger

Actions with the same triggers (excluding linters, which will be their own category) will live in the same GitHub action file. Scheduled actions will live in the same file if they trigger on the same schedule (i.e. all files that trigger everyday at 11am will live in one file, while files that trigger on Friday at 7am will be on a separate file).

That said, this structure is not set in stone. If any part of it feels strange, or you have questions, feel free to bring it up with the team so we can evolve this format!

[github-actions]

Hi @SAUMILDHANKAR.

Good job adding the required labels for this issue. The merge team will review the issue and add a "Ready for Milestone" label once it is ready for prioritization.

Additional Resources:

• Wiki: How to create issues
• Wiki: How to read and interpret labels