search

silverstripe / .github

0 stars 2 forks source link

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

Closed GuySartorelli closed 3 months ago

GuySartorelli commented 11 months ago

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

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

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. [x] Make a docs PR for this whole thing
  2. [x] run standardiser against the next-patch branch again
  3. [x] Add all pre-existing community PRs to the board
GuySartorelli commented 3 months ago

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 commented 3 months ago

PRs merged, reassigning to Guy

emteknetnz commented 3 months ago

Assigning back to Guy - presumbably once you've confirmed it's all working we need a module-standardiser run again all the supported repos?

GuySartorelli commented 3 months ago

Yup, as per "After merging" section.

GuySartorelli commented 3 months ago

The action correctly skips when I create a PR: https://github.com/silverstripe/silverstripe-admin/actions/runs/9558332393/job/26346877875?pr=1783

We won't be able to fully test it without the CI being added to a repo and getting someone not on the CMS Squad to make a PR, but I'm confident with my testing between a combination of manual API requests (mimicking what the CI will be doing) and the above run that things will work as expected.

emteknetnz commented 3 months ago

@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 commented 3 months ago

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 commented 3 months ago

Test PR - didn't seem to trigger - https://github.com/silverstripe/silverstripe-cms/pull/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 commented 3 months ago

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 commented 3 months ago

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

image

GuySartorelli commented 3 months ago

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

emteknetnz commented 3 months ago

Reassigned to Guy to copy existing PRs to the board

GuySartorelli commented 3 months ago

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.