Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a project board for tracking community PR review progress #155

Closed
8 tasks done
GuySartorelli opened this issue Nov 2, 2023 · 13 comments
Closed
8 tasks done
Assignees

Comments

@GuySartorelli
Copy link
Member

GuySartorelli commented Nov 2, 2023

As part of adding the new peer reviewer and refiner roles, we should provide a project board that these community roles can use to organise and track their work.

Epic

Acceptance Criteria

  • A new GitHub project board is created for tracking community pull request review progress
  • All teams have access to the board
    • Probably the refiners should have view-only access, if that's possible
  • The project board is documented on either the maintainer guidelines page, triage and peer review page, or both
  • The "Backlog with PRs" column in zenhub is removed, in favour of using the new project board for tracking community PRs
  • If possible, all issues with a pull request are displayed in the project board
    • Otherwise, all issues are displayed on the project board
    • NOTE: Opted to list PRs in the end because that's ultimately what people need to review, and that's much easier than finding the 5 different ways PRs can be "related" to an issue in order to know when an issue should be added

TO DECIDE (or explicitly leave it up to whoever implements it)

  • What columns do we want? Examples below
    • New issues
    • Needs review (has a PR but isn't being reviewed yet)
    • In review (must be assigned to the person reviewing)
    • Awaiting contributor feedback (must be assigned to the person who requested feedback)
    • Needs escalation (core committers or CMS squad need to take a look)
    • Needs second approval
    • Done/Merged (HIDDEN)

We'll aim to review these column early once we start having some contributors on-boarded. So we'll go with the initial suggested column.

NOTE about using secrets in GitHub Actions

https://docs.github.com/en/actions/learn-github-actions/contexts#secrets-context

If a secret was used in the job, GitHub automatically redacts secrets printed to the log. You should avoid printing secrets to the log intentionally.

In other words, so long as we're not echoing it out ourselves, there should be no risk of our secret being exposed via logs.

Project board

PRs

Module Standardiser PRs

Running against default-branch

Running against the CMS 5 next-patch branch

I've limited this to only run the new script (with exception of the new repo which had all scripts run). This is because the last few times standardiser was run it was against the next-minor branch, and running all those scripts here would result in redundant changes to check - some of which when I tried it did result in failures.

After merging

Reassign to Guy to

  1. Make a docs PR for this whole thing
  2. run standardiser against the next-patch branch again
  3. Add all pre-existing community PRs to the board
@GuySartorelli
Copy link
Member Author

I was intending on using a GitHub action to add PRs to the board as soon as they're opened.

https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/automating-projects-using-actions

GITHUB_TOKEN is scoped to the repository level and cannot access projects. To access projects you can either create a GitHub App (recommended for organization projects) or a personal access token (recommended for user projects). Workflow examples for both approaches are shown below.

That means storing a private key as a secret in the GitHub org - though it only needs write permissions for projects (not for issues/PRs/code) so not the worst case scenario.

Alternatives

  1. Use project workflows to do it - there's a feature out of the box we can use, but it requires creating a separate "workflow" (not the same as GitHub Actions workflows) for each repo we want for the project. The process is documented at https://docs.github.com/en/issues/planning-and-tracking-with-projects/automating-your-project/adding-items-automatically BUT note we're only allowed 1 for free, and even if we paid money we only get up to 20. So not really viable for us.
  2. Host a bot externally and use the GraphQL API as per documentation for that use case. We still need a token with the same level of access as the initial approach though, so it's not really any better. We either risk leaking a secret from within GitHub Actions or from our own hand-crafted tool and whatever service it's hosted on.

@emteknetnz
Copy link
Member

PRs merged, reassigning to Guy

@GuySartorelli GuySartorelli removed their assignment Jun 18, 2024
@emteknetnz
Copy link
Member

@GuySartorelli I've merged a single PR (cms) for you to validate the new action works as expected. Once you've validated that I'll merge the others.

@GuySartorelli
Copy link
Member Author

GuySartorelli commented Jun 18, 2024

Merging those prs doesn't help validate anything - the action already has run on those prs when they got created and correctly skipping adding to the project, since I opened them and I'm in the CMS squad.

For any further validation we'd have to wait for someone who isn't on the CMS squad to raise a pr. I don't see the point in that since I've already validated the API calls will work with the app token.

@emteknetnz
Copy link
Member

emteknetnz commented Jun 18, 2024

Test PR - didn't seem to trigger - silverstripe/silverstripe-cms#2968

Note: needed to click "Approve and run" for the CI workflow (add pr to project workflow did not trigger) as the author had not contributed to the repo before, which means that if a reviewers workflow is "check the project board for new pull-requests", it may not work so well as some PRs won't appear on the board as the workflow to put them there has not run

@emteknetnz
Copy link
Member

emteknetnz commented Jun 18, 2024

If you need to update module-standardiser change workflow name to "Add new prs to github project" (shorten "pull requests" to "prs", and remove "a" - title is so long it's truncating, currently reads like it's adding a pr to a pr

image

@emteknetnz
Copy link
Member

Also add name: Add PR to GitHub Project to the addprtoproject job in module-standardiser, otherwise it looks kind of ugly

image

@GuySartorelli
Copy link
Member Author

Made the requested changes to names in a new PR to module standardiser

@emteknetnz
Copy link
Member

Reassigned to Guy to copy existing PRs to the board

@GuySartorelli
Copy link
Member Author

Added pull requests which are open, not draft, not created by bots and not created by current CMS Squad across all modules which are commercially supported in CMS 5.
There's a total of 42 open PRs on the board now.

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

No branches or pull requests

2 participants