CI: INFRA-2087 auto generated issues for mobile and extension repositories #4763
Conversation
| - name: Checkout head | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| fetch-depth: 0 |
There was a problem hiding this comment.
I'm not 100% sure that we have to fetch here whole history, if release pipeline have always tag on head commit fetch-tags: true to make it little faster
There was a problem hiding this comment.
I think it would be safe just to get the HEAD commit. The release tags will always be on that commit. The tags are created in the publish-release step, which happens before this one.
| permissions: | ||
| issues: write | ||
| uses: ./.github/workflows/create-update-issues.yaml | ||
| with: |
There was a problem hiding this comment.
Before merge security team have to create new github app, I will send request to @NicholasEllul
rrabenda
force-pushed
the
feat/INFRA-2087-auto-generate-issues
branch
from
8e95e76
to
dc8c828
Compare
| run: | | ||
| echo "Creating new issue..." | ||
| gh issue create --title "Update ${package} to version ${version}" --body "Please update ${package} to version ${version}" --repo "MetaMask/metamask-extension" | ||
| gh issue create --title "Update ${package} to version ${version}" --body "Please update ${package} to version ${version}" --repo "MetaMask/metamask-mobile" |
There was a problem hiding this comment.
For now I hardcoded repositories names if you see any case that this have to be dynamic I can move this step to new job and leverage workflow matrix.
There was a problem hiding this comment.
Hard-coding these seems fine to me 👍
| - name: Get release tag | ||
| id: releaseTag | ||
| run: | | ||
| echo "tag=$(git describe --tags --abbrev=0)" >> "$GITHUB_OUTPUT" |
There was a problem hiding this comment.
This would only retrieve a single tag, but a single release can contain multiple package releases in it. We need to create issues for all major version bumps in a given release
| fi | ||
| shell: bash | ||
|
|
||
| - name: Generate a token |
There was a problem hiding this comment.
What is the purpose of using a GitHub app here? Typically we would use a personal access token to create issues.
| version: ${{ steps.releaseCheck.outputs.version }} | ||
| run: | | ||
| echo "Creating new issue..." | ||
| gh issue create --title "Update ${package} to version ${version}" --body "Please update ${package} to version ${version}" --repo "MetaMask/metamask-extension" |
There was a problem hiding this comment.
We'll want to assign teams as well, this was part of the acceptance criteria and is important for achieving the main goal here (visibility and accountability for these updates).
We use labels to keep track of who owns which issue, so assigning a team here means attaching that team's label to the issue (which luckily is easy with the gh issue command).
However, determining which team to assign might be tricky. The ticket suggests that we assign it to "the responsible team", but doesn't describe who should be responsible. In discussing this work, we had considered either:
- Assigning the team who released the work on core, or
- Assigning the "codeowner" team(s) for the given package.
I think either way would be fine to start with, as the assigned team can easily re-assign a different team as appropriate. As long as some team is assigned, it accomplishes the goals of visibility and accountability.
For the first strategy, we could get the team label using an approach like this: https://github.com/MetaMask/github-tools/blob/058012b49ff2fbd9649c566ba43b29497f93b21d/.github/workflows/add-team-label.yml#L19
(we already have a mapping of user to team in our planning repo)
For the second strategy, we could parse the .github/CODEOWNERS file. But we'd need a mapping of GitHub team names to labels (the format is a little different between the two right now, and doesn't follow a consistent naming convention from team to team).
Explanation
CI pipeline for auto generated issues when major release of any package occurs. New issues will be created in metamask-extension and metamask-mobile repositories.
References
Changelog
None