create a merge report to track the PR status

[protocol]

create a merge report to track the PR status

[galargh]

For now I've created a workflow that I run every week (I'll probably put it on cron schedule soon) which:

• looks for all the open web3-bot PRs https://github.com/galargh/.github/blob/master/.github/workflows/add-project-items.yml#L22
• adds them to the board where I track my work https://github.com/orgs/protocol/projects/14/views/4

There's one gotcha though - even though it is possible to add cross org items to Projects (Beta), it is not possible to do so using API :( To work around this, for PRs outside protocol org I create issues like this one https://github.com/protocol/w3dt-stewards/issues/8 and manually add the items listed there to the project.

[marten-seemann]

Possible solution: The copy workflow creates an issues with a list of all PRs that it opened. The automerge workflow in each repo then edits this list and removes the respective repo from the list after it was executed.
I'm not sure how GitHub deals with concurrent modifications of that list though, we might need to implement some kind of poor-man's mutex here (set a label on the issue to lock the mutex and remove the mutex to unlock?).

[mvdan]

Hah, I was thinking of concurrent edit issues, too.

Another idea: set up a GitHub Project titled Deployment <date>, and include an item for every open PR. This seemingly works across repos and orgs too: https://tosbourn.com/github-projects-different-organisations/

You can even use predefined templates for a project like "automated kanban", which uses an issue/PR's status (open, merged, closed, etc) to move it across columns. So then, supposedly, merging or closing a PR would automatically move it out of the "to do" column. I also imagine you could set up custom workflow automation to change this, e.g. have separate columns for "merged" vs "closed", or a column for "merge conficts", etc.

[marten-seemann]

Good point, GitHub Projects might be the better fit here. Every deployment run would be a new project then.
There's a GitHub Actions workflow that would allow us to automatically assign the PRs (when we create them in the copy workflow?): https://github.com/marketplace/actions/assign-to-one-project

[marten-seemann]

There's a GitHub Actions workflow that would allow us to automatically assign the PRs (when we create them in the copy workflow?): https://github.com/marketplace/actions/assign-to-one-project

I played around with that Action a bit, and with others I could find on the market place. The problem is that all these actions are used to assign issues / PRs to projects. That's not quite our use case though: We don't want the action to run when a new issue / PR is created (GitHub might not even run the action on initial deployment), but we want the copy workflow to create the project card for the PR it just opened.
We'll probably have to write our on Action for that. Should be a big problem, the code looks pretty straightforward: https://github.com/srggrs/assign-one-project-github-action/blob/42352f30e8f3608e29350741411ab7061c953972/entrypoint.sh#L115-L138

Furthermore, all existing Actions assume that the project already exists. We'll need to create another Action to create a new GitHub Project and export the URL. This will probably require playing around with the GitHub API a bit.

[marten-seemann]

@BigLep pointed out that we can get this overview over unmerged web3-bot PRs from the Ecosystem Dashboard:
https://ecosystem-research.herokuapp.com/all?range=9999&state=open&user=web3-bot

I'd say this is pretty much exactly what we've been looking for.

[mvdan]

@marten-seemann this is likely very relevant to you now: https://github.blog/2021-06-23-introducing-new-github-issues/

In particular, note how you can now create a "super-issue" that has a list of nested issue links, which automatically get checked off as they are closed. I imagine that would be easier than setting up a Project automation.