Skip to content

GHA: Sort pull requests to correct column #3112

Open
@SAUMILDHANKAR

Description

Dependency

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

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

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!

Metadata

Assignees

Labels

Complexity: LargeDraftIssue is still in the process of being createdFeature: Board/GitHub MaintenanceProject board maintenance that we have to do repeatedlyready for dev leadIssues that tech leads or merge team members need to follow up onrole: back end/devOpsTasks for back-end developerssize: 2ptCan be done in 7-12 hours

Type

No type

Projects

  • Status

    New Issue Approval

Relationships

None yet

Development

No branches or pull requests

Issue actions