Fix open PR action

[ForestEckhardt]

Currently the update builder action creates a single branch and tries to make changes to and make a PR with that branch. When that PR is merged, the branch is deleted. However if the PR is closed the branch is not deleted and a new PR will not be reopened on that branch meaning that there is a possibility to miss updates. This problem can be demonstrated by the following to PRs, first we have paketo-buildpacks/full-builder#331 which opens a branch with relevant changes. This PR was then closed by another PR through linking and all subsequent update runs did not reopen a similar PR until the automation/builder-toml branch was deleted and then this PR was created and merged paketo-buildpacks/full-builder#333.

[fg-j]

I think the same problem happens with the update-github-config and update-buildpack workflows on other repos, because in all cases, the update branch name is fixed. (e.g. automation/github-config/update or automation/builder-toml). This means that when a branch already exists with the hard-coded name, no PR is created.

In, fact I think it's the open PR action that should be fixed to cover this edge case. (If no PR is already open for a given branch, one should be created.)

[fg-j]

It seems like the root cause of this failure is rate limiting by Github (cli/cli#4801). Since all of the PR-creating actions use the shared Paketo Github token, update PRs that go out to all Paketo repos in batches will inevitably hit this rate limit.

Since it seems like the Github Actions default GITHUB_TOKEN can have pull request read/write permissions, I think we can address this problem by using the repository GITHUB_TOKEN to create PRs instead of the shared PAKETO_BOT_GITHUB_TOKEN , and specifying that the token needs PR write permissions using the GHA job permissions key.

Edit: Unfortunately, Github Actions won't trigger on events instigated by other Github Actions using the default token. This means that PRs opened by the Github Actions bot won't trigger our PR testing workflows. So we'll need to find another way around the rate limit.