Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

CI: INFRA-2087 auto generated issues for mobile and extension repositories #4763

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+92 −0
Open

CI: INFRA-2087 auto generated issues for mobile and extension repositories #4763

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
dc8c828
INFRA-2087 auto generated issues for mobile and extension repositories
rrabenda Oct 4, 2024
e11bf76
INFRA-2087 spellcheck fix
rrabenda Oct 4, 2024
af3ce7a
INFRA-2087 spellcheck fix 2
rrabenda Oct 4, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 76 additions & 0 deletions .github/workflows/create-update-issues.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
name: Create Update Issues

on:
workflow_call:
inputs:
AUTH_APP_ID:
description: Github app id to authenticate in mobile and extention repositories
type: string
required: true
secrets:
AUTH_APP_PRIVATE_KEY:
description: Github app private key to authenticate in mobile and extention repositories
required: true

jobs:
create-update-issues:
permissions:
issues: write
runs-on: ubuntu-latest
steps:
- name: Checkout head
uses: actions/checkout@v4
with:
fetch-depth: 0
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


- name: Get release tag
id: releaseTag
run: echo "tag=$(git describe --tags --abbrev=0)" >> $GITHUB_OUTPUT

- name: Check released package
id: releaseCheck
env:
tag: ${{ steps.releaseTag.outputs.tag }}
run: |
if [[ ${tag} == @metamask/* ]] ; then
# Extract package name without the leading '@'
package_name="${tag#@}"
package_name="${package_name%@*}"
echo "package_name=${package_name}" >> $GITHUB_OUTPUT

# Extract version number
version="${tag##*@}"
echo "version=${version}" >> $GITHUB_OUTPUT

# Check if version number ends with .0.0
if [[ $version == *.0.0 ]]; then
echo "$package_name major update"
echo "major_version=true" >> $GITHUB_OUTPUT
else
echo "$package_name minor update"
echo "major_version=false" >> $GITHUB_OUTPUT
fi
else
echo 'Monorepo version update'
echo "major_version=false" >> $GITHUB_OUTPUT
fi

- name: Generate a token
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the purpose of using a GitHub app here? Typically we would use a personal access token to create issues.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We use GitHup app here to avoid personal access token. PAT is connected to user and when that user will lost access to org also workload will stop working. On top off that is easier to rotate credentials for security team if required.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We have a fairly well defined process for managing PATs, and we generate them using an account not tied to an individual (metamaskbot). We use them a lot, it would be quite onerous to create an app for each one.

id: generate-token
if: ${{ steps.releaseCheck.outputs.major_version == 'true' }}
uses: actions/create-github-app-token@v1
with:
app-id: ${{ inputs.AUTH_APP_ID }}
private-key: ${{ secrets.AUTH_APP_PRIVATE_KEY }}
repositories: metamask-mobile, metamask-extension

- name: Create Issue
if: ${{ steps.releaseCheck.outputs.major_version == 'true' }}
env:
GH_TOKEN: ${{ steps.generate-token.outputs.token }}
package: ${{ steps.releaseCheck.outputs.package_name }}
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"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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).

gh issue create --title "Update ${package} to version ${version}" --body "Please update ${package} to version ${version}" --repo "MetaMask/metamask-mobile"
Gudahtt marked this conversation as resolved.
Show resolved Hide resolved
12 changes: 12 additions & 0 deletions .github/workflows/main.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -48,6 +48,18 @@ jobs:
NPM_TOKEN: ${{ secrets.NPM_TOKEN }}
SLACK_WEBHOOK_URL: ${{ secrets.SLACK_WEBHOOK_URL }}

create-update-issues:
name: Create update issues
needs: [is-release, publish-release]
if: needs.is-release.outputs.IS_RELEASE == 'true'
permissions:
issues: write
uses: ./.github/workflows/create-update-issues.yaml
with:
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Before merge security team have to create new github app, I will send request to @NicholasEllul

AUTH_APP_ID: ${{ vars.AUTH_APP_ID }}
secrets:
AUTH_APP_PRIVATE_KEY: ${{ secrets.AUTH_APP_PRIVATE_KEY }}

all-jobs-complete:
name: All jobs complete
runs-on: ubuntu-latest
Expand Down
Loading