Wanted to share our implementation and say thanks #62
Replies: 2 comments
-
@aptalca thank you for the kind words and sharing your experience. I will try to maintain the current standard and improve it. |
Beta Was this translation helpful? Give feedback.
-
Sounds great!! Quick update, mixing and matching the v2 project built-in workflows and our workflow utilizing this action resulted in some race condition issues. The built-in workflows (like moving closed issues and PRs to column The edge case we ran into is triggered by things done in quick succession, such as labeling an issue as What happens is:
As the solution, we decided not to mix and match and instead rely on our workflow for all the actions. The links in the original post above point to the updated workflows and the text has been edited to reflect that. |
Beta Was this translation helpful? Give feedback.
-
Thanks so much for publishing and maintaining this action. We have hundreds of repos and we were in desperate need of project management to track all the issues and PRs. We used to use the Github app project bot but it hasn't been maintained for some time and it is no longer functional (works 5-10% of the time, which is not acceptable).
So we recently switched to v2 project boards and reusable workflows utilizing this action to interact with the project board.
We ended up creating a new project board (v2 as Github calls it, which recently came out of beta): https://github.com/orgs/linuxserver/projects/8
For managing the issues and PRs, we created a callable (reusable) workflow that handles all the logic for interacting with the project board (adding issues and PRs and moving them around). This resuable workflow is called by simpler calling workflows in each of our repos. The reason we went for this split workflow approach is so that if and when we decide to make changes to the columns or the logic, we only need to update the reusable workflow rather than updating hundreds of workflows in other repos.
Anyhow, here's the code for our calling workflow that exists in all of our repos: https://github.com/linuxserver/github-workflows/blob/v1/.github/workflows/call-issue-pr-tracker.yml
It triggers on all issues and PRs opened, reopened, labeled and unlabeled, as well as PRs with review requests added or removed. Once triggered, all it does is to call the reusable workflow. Hopefully this workflow is simple enough that we won't have to modify anytime soon (really don't want to update hundreds of repos and triggers docker builds).
Here's the code for our reusable workflow: https://github.com/linuxserver/github-workflows/blob/v1/.github/workflows/issue-pr-tracker.yml
It uses a series of
if
s to determine the correct task, and then uses this action to interact with the project board.In a nutshell, the tasks we specified are:
Insufficient Info
columnPRs Ready For Team Review
Done
EDIT: Per comment below, we ran into race condition issues and decided to let our workflow handle all actions instead of mising and matching with the v2 project built-in workflows
We also utilize some of the built-in workflows that are part of these v2 project boards (not very flexible or customizable but work great)- Closed issues and PRs moved toDone
- PRs where review added will be moved toPRs Approved
- Merged PRs will be moved toDone
I hope this gives some ideas to others who can implement a similar solution.
Beta Was this translation helpful? Give feedback.
All reactions