ci: track merged PRs in a GitHub project #6867
Conversation
| @@ -0,0 +1,92 @@ | |||
| #!/bin/bash | |||
| set -eux | |||
There was a problem hiding this comment.
I've always liked the French set here. :D
There was a problem hiding this comment.
I want to gripe about the verbosity of the GraphQL API, but I suppose I won't. :)
What I will ask is if we can plan to add the PRs to a milestone in the relevant project at the same time. It doesn't have to be in this initial PR, but I'd like to see all PRs added to a milestone eventually. So how do you feel about changing the name of the action to something like "track PRs for release" or something along those lines so we can do that in the same action later on?
| fetch-depth: 0 | ||
| - name: Generate token | ||
| id: generate_token | ||
| uses: tibdex/github-app-token@b62528385c34dbc9f38e5f4225ac829252d1ea92 |
There was a problem hiding this comment.
Why a specific commit instead of a release version that dependabot can track and update? That commit seems to map to the current release. :)
| uses: tibdex/github-app-token@b62528385c34dbc9f38e5f4225ac829252d1ea92 | |
| uses: tibdex/github-app-token@v1.8.0 |
There was a problem hiding this comment.
That's from an example in GitHub's docs, which also generally recommend pinning third-party actions for security, which I figured might be particularly useful here, since we're passing in a secret (albeit one with very limited permissions). So that is the reason, though I'll defer to your judgment if you still don't want to go with the pin.
There was a problem hiding this comment.
I'm for us pinning versions going forward whenever images are involved and setting the example for the rest of the org.
It's a hella PITA and costs us some automation, but bumping versions of hashed things ourselves isn't too problematic to automate down the line.
| PR_TITLE: ${{ github.event.pull_request.title }} | ||
| PR_URL: ${{ github.event.pull_request.html_url }} | ||
| run: | | ||
| tools/scripts/add-pr-to-release-project.sh |
There was a problem hiding this comment.
I don't think we want to directly run that embedded script from PRs (especially forks).
It might be nice to package that script up as a docker action, too, but perhaps that's overkill. Just checking it out from the pull request target (or main) would probably be easier.
There was a problem hiding this comment.
I'd totally love help create and action for this if necessary.
We already have a repo for release PR's, so we may as well publish release tooling from it.
dzhu
force-pushed
the
release-project-add-prs
branch
from
71dc2bc to
aaccc9f
Compare
| fetch-depth: 0 | ||
| - name: Generate token | ||
| id: generate_token | ||
| uses: tibdex/github-app-token@b62528385c34dbc9f38e5f4225ac829252d1ea92 |
There was a problem hiding this comment.
That's from an example in GitHub's docs, which also generally recommend pinning third-party actions for security, which I figured might be particularly useful here, since we're passing in a secret (albeit one with very limited permissions). So that is the reason, though I'll defer to your judgment if you still don't want to go with the pin.
As a first step toward exploring a new release process, this creates a GitHub action that adds each merged fix/feat PR to an organization-level GitHub project for tracking during the release party. The PRs are not added directly to the project; instead, new issues linking to them are created in a separate repo. It would be possible and a bit simpler to add them directly, but I felt that it was preferable to have a separate place specifically for release-related discussion that was not appending onto the already closed PRs.
dzhu
force-pushed
the
release-project-add-prs
branch
from
aaccc9f to
ced08a1
Compare
|
Correction to what I said about permissions: I thought the GitHub App could have separate permissions for what repos it could be used from and what repos it had access to, but the first run failed when it wasn't installed on this repo, so now I think actually those are not distinct and it needs to have access to the main repos. Hopefully that's okay, considering it's running on |
Following on from determined-ai#6867, this adds some more steps to the release automation. The workflows now handle a special label that marks a PR as a fix to be cherry-picked for the current release. There's also scaffolding for some future steps for actually handling the cherry-picks; some of that implementation is left stubbed out for now, but I believe this should cover the full shape of the Actions lifecycle we have in mind. Remaining work will lie in filling in that implementation and updating rph to handle the human side of things.
Following on from determined-ai#6867, this adds some more steps to the release automation. The workflows now handle a special label that marks a PR as a fix to be cherry-picked for the current release. There's also scaffolding for some future steps for actually handling the cherry-picks; some of that implementation is left stubbed out for now, but I believe this should cover the full shape of the Actions lifecycle we have in mind. Remaining work will lie in filling in that implementation and updating rph to handle the human side of things.
Following on from determined-ai#6867, this adds some more steps to the release automation. The workflows now handle a special label that marks a PR as a fix to be cherry-picked for the current release. There's also scaffolding for some future steps for actually handling the cherry-picks; some of that implementation is left stubbed out for now, but I believe this should cover the full shape of the Actions lifecycle we have in mind. Remaining work will lie in filling in that implementation and updating rph to handle the human side of things.
Following on from #6867, this adds some more steps to the release automation. The workflows now handle a special label that marks a PR as a fix to be cherry-picked for the current release. There's also scaffolding for some future steps for actually handling the cherry-picks; some of that implementation is left stubbed out for now, but I believe this should cover the full shape of the Actions lifecycle we have in mind. Remaining work will lie in filling in that implementation and updating rph to handle the human side of things.
As a first step toward exploring a new release process, this creates a GitHub action that adds each merged fix/feat PR to an organization-level GitHub project for tracking during the release party. The PRs are not added directly to the project; instead, new issues linking to them are created in a separate repo. It would be possible and a bit simpler to add them directly, but I felt that it was preferable to have a separate place specifically for release-related discussion that was not appending onto the already closed PRs.
As a first step toward exploring a new release process, this creates a GitHub action that adds each merged fix/feat PR to an organization-level GitHub project for tracking during the release party. The PRs are not added directly to the project; instead, new issues linking to them are created in a separate repo. It would be possible and a bit simpler to add them directly, but I felt that it was preferable to have a separate place specifically for release-related discussion that was not appending onto the already closed PRs.
Following on from #6867, this adds some more steps to the release automation. The workflows now handle a special label that marks a PR as a fix to be cherry-picked for the current release. There's also scaffolding for some future steps for actually handling the cherry-picks; some of that implementation is left stubbed out for now, but I believe this should cover the full shape of the Actions lifecycle we have in mind. Remaining work will lie in filling in that implementation and updating rph to handle the human side of things.
As a first step toward exploring a new release process, this creates a GitHub action that adds each merged fix/feat PR to an organization-level GitHub project for tracking during the release party. The PRs are not added directly to the project; instead, new issues linking to them are created in a separate repo. It would be possible and a bit simpler to add them directly, but I felt that it was preferable to have a separate place specifically for release-related discussion that was not appending onto the already closed PRs.
Following on from #6867, this adds some more steps to the release automation. The workflows now handle a special label that marks a PR as a fix to be cherry-picked for the current release. There's also scaffolding for some future steps for actually handling the cherry-picks; some of that implementation is left stubbed out for now, but I believe this should cover the full shape of the Actions lifecycle we have in mind. Remaining work will lie in filling in that implementation and updating rph to handle the human side of things.
Description
As a first step toward exploring a new release process, this creates a GitHub action that adds each merged fix/feat PR to an organization-level GitHub project for tracking during the release party.
The PRs are not added directly to the project; instead, new issues linking to them are created in a separate repo. It would be possible and a bit simpler to add them directly, but I felt that it was preferable to have a separate place specifically for release-related discussion that was not appending onto the already closed PRs.
Test Plan
Did a bunch of iteration on a private test repo. There's some chance that something will go wrong on the transfer to this one, but I think I've done the best I can do. And it's not like anything terrible will happen if something is off.