Project Management: Assign issues 'fixed' by a PR to the author of th…

[noisysocks]

Adds a GitHub Action which, when a pull request is opened, searches the pull request description for 'Fixes #XXXX' and, for each found issue:

• Adds the author of the pull request as an assignee.
• Adds the [Status] In Progress label.

Testing

I'm unable to test this on GitHub because my personal GitHub account doesn't have access to GitHub Actions.

I tested it locally by:

1. Generate a personal access token with the public_repo permission.
2. Create a mock pull request event and save it as event.json:

{
  "pull_request": {
    "body": "Lorem ipsum etc etc. Fixes #1.\nCloses 2",
	"user": {
	  "login": "noisysocks"
	}
  }
}

3. Run the action, replacing INSERT_TOKEN_HERE with the token generated above:

docker build .github/actions/assign-fixed-issues/ -t assign-fixed-issues
docker run -v `pwd`:`pwd` -w `pwd` -e GITHUB_EVENT_PATH=event.json -e GITHUB_TOKEN=INSERT_TOKEN_HERE -e GITHUB_REPOSITORY=noisysocks/gutenberg -it assign-fixed-issues

[noisysocks]

Right now I'm only handling the case where a pull request is opened. If one edited an existing pull request to include a 'Fixes #XXXX', the action would not pick it up. I'm thinking that this is fine for now and that we can build our way up once we're more confident in the action.

[youknowriad]

I think to avoid annoying Github filters links in the PR @aduth moved these filters to the entry point script instead. Should we do the same?

[aduth]

My changes in #16702 weren't related to the spamming of the checks box. I did replace the filtering, partly on a hunch that it might explain inadvertent cancellations we've been seeing when using GitHub's canonical actions/bin repository (the cancellations occur in this container).

[noisysocks]

Do you think I should have any filtering in the entry point script here?

[aduth]

Do you think I should have any filtering in the entry point script here?

It's hard to say. In a perfect world, the way you've implemented it would be correct. The problem we were seeing which led to #16702 was that this step was frequently being cancelled unexpected. I have an open ticket with GitHub support which they've repeatedly deferred, so the changes there were meant as an experiment on our end to determine whether it might provide any more stability to our GitHub Actions workflows.

So far: The cancellations have stopped. But now we're seeing another new issue that they've become perpetually queued ¯\_(ツ)_/¯ [1] [2]

For the purposes of your pull request, I'd say to keep it as you've implemented, but expect that it unfortunately may not work very reliably.

[aduth]

To the original question: I think your proposal as it stands now is reasonable, and if we want additional coverage later, it can come as a future enhancement.

[aduth]

I've not actually run the code, but it reads sensibly, and looks to adopt many of the conventions I incorporated in #15826. Let's give it a try, and pay attention to new pull requests to sort through any issues we encounter. Nice work here 👍

[aduth]

As I noted in #15826 (comment), I feel like shell-based custom actions might become a pain-point for maintenance. For example, I'm not particularly comfortable with this (assuredly simple) Perl script. Since the work has already been done here, I'd not advocate to change it, but I think in the future we should consider whether to just use our collective JavaScript knowledge and encourage that these be written as Node scripts.

[noisysocks]

Agreed!

[aduth]

To the original question: I think your proposal as it stands now is reasonable, and if we want additional coverage later, it can come as a future enhancement.

[aduth]

We'll need to note to update this if we ever decide to reword these labels in the future.