chore: keep release process in GitHub #9165
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,33 @@ | ||
| name: Release to Production | ||
| on: | ||
| pull_request: | ||
| branches: | ||
| - production | ||
| types: [closed] | ||
| jobs: | ||
| release: | ||
| if: ${{ github.event.pull_request.merged == true }} | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: "read" | ||
| id-token: "write" | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v3 | ||
| - name: Push to Production Server | ||
| run: | | ||
| JOB_ID=$(echo ${{ github.event.pull_request.body}} | perl -ne 'print "$1\n" and exit if m/^Production Job Id:\s(\w+)/;') | ||
| echo "JOB_ID=${JOB_ID}" >> $GITHUB_ENV | ||
| curl "https://gitlab.com/api/v4/projects/${{ vars.GITLAB_PROJECT_ID }}/jobs/$JOB_ID/play" \ | ||
| --request POST \ | ||
| --header 'PRIVATE-TOKEN: ${{ secrets.GITLAB_API_TOKEN }}' | ||
| sleep 90 | ||
| - name: Poll Production Release | ||
| uses: artiz/[email protected] | ||
| with: | ||
| url: https://gitlab.com/api/v4/projects/${{ vars.GITLAB_PROJECT_ID }}/jobs/${{ env.JOB_ID }} | ||
| method: GET | ||
| expect-status: 200 | ||
| expect-response-regex: '"status":"success"' | ||
| timeout: 120000 | ||
| interval: 3000 | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,87 @@ | ||
| name: Release to Staging | ||
| on: | ||
| pull_request: | ||
| branches: | ||
| - master | ||
| - hotfix-* | ||
|
There was a problem hiding this comment. +1 should we keep the convention of There was a problem hiding this comment. Good eye! With this change, I'm proposing that we change the hotfix flow to ALWAYS go to staging. If the PR is time critical, you can still merge to prod without waiting for staging to complete. For everything else, it's an extra chance to check your migration or code fix without delay! |
||
| types: [closed] | ||
| jobs: | ||
| release: | ||
| if: ${{ github.event.pull_request.merged == true && startsWith(github.head_ref, 'release-please--') }} | ||
| runs-on: ubuntu-latest | ||
| permissions: | ||
| contents: "read" | ||
| id-token: "write" | ||
| steps: | ||
| - name: Checkout | ||
| uses: actions/checkout@v3 | ||
| - name: Setup environment variables | ||
| run: | | ||
| ACTION_VERSION=$(grep '"version":' package.json | cut -d\" -f4) | ||
| echo "ACTION_VERSION=${ACTION_VERSION}" >> $GITHUB_ENV | ||
| - id: "auth" | ||
| name: "Authenticate to Google Cloud" | ||
| uses: "google-github-actions/auth@v1" | ||
| with: | ||
| token_format: "access_token" | ||
| workload_identity_provider: ${{ secrets.GCP_WI_PROVIDER_NAME }} | ||
| service_account: ${{ secrets.GCP_SA_EMAIL }} | ||
| - name: "Set up Cloud SDK" | ||
| uses: "google-github-actions/setup-gcloud@v1" | ||
| - name: "Tag image with production version" | ||
| run: |- | ||
| gcloud container images add-tag -q \ | ||
| ${{ secrets.GCP_AR_PARABOL_DEV }}:${{github.event.pull_request.head.sha}} \ | ||
| ${{ secrets.GCP_AR_PARABOL }}:v${{ env.ACTION_VERSION }} | ||
| - name: Push to Staging Server | ||
| env: | ||
| STAGING_JOB: staging-release | ||
| PRODUCTION_JOB: prod-release | ||
| run: | | ||
| COMMIT_ID=$(curl "https://gitlab.com/api/v4/projects/${{ vars.GITLAB_PROJECT_ID }}/repository/commits" \ | ||
| --request POST \ | ||
| --header 'PRIVATE-TOKEN: ${{ secrets.GITLAB_API_TOKEN }}' \ | ||
| --form "branch=main" \ | ||
| --form "commit_message=release v${{ env.ACTION_VERSION }}" \ | ||
| --form "actions[][action]=update" \ | ||
| --form "actions[][file_path]=version.yaml" \ | ||
| --form "actions[][content]= | ||
| # Change it to use a valid docker tag, which are the same of the GitHub tags. Ex: v6.110.0 | ||
| applicationVersion: &applicationVersion v${{ env.ACTION_VERSION }} | ||
|
|
||
| global: | ||
| image: | ||
| tag: *applicationVersion" | jq .id) | ||
| PIPELINES=$(curl "https://gitlab.com/api/v4/projects/${{ vars.GITLAB_PROJECT_ID }}/pipelines" \ | ||
| --header 'PRIVATE-TOKEN: ${{ secrets.GITLAB_API_TOKEN }}') | ||
| PIPELINE_ID=$(echo $PIPELINES | jq ".[] | select(.sha == \"$COMMIT_ID\")" | jq .id) | ||
| JOBS=$(curl "https://gitlab.com/api/v4/projects/${{ vars.GITLAB_PROJECT_ID }}/pipelines/$PIPELINE_ID/jobs" \ | ||
| --header 'PRIVATE-TOKEN: ${{ secrets.GITLAB_API_TOKEN }}') | ||
| JOB_ID=$(echo $JOBS | jq '.[] | select(.name == "${{ env.STAGING_JOB }}")' | jq .id) | ||
| curl "https://gitlab.com/api/v4/projects/${{ vars.GITLAB_PROJECT_ID }}/jobs/$JOB_ID/play" \ | ||
| --request POST \ | ||
| --header 'PRIVATE-TOKEN: ${{ secrets.GITLAB_API_TOKEN }}' | ||
| PROD_JOB_ID=$(echo $JOBS | jq '.[] | select(.name == "${{ env.PRODUCTION_JOB}}")' | jq .id) | ||
| echo "JOB_ID=${JOB_ID}" >> $GITHUB_ENV | ||
| echo "PROD_JOB_ID=${PROD_JOB_ID}" >> $GITHUB_ENV | ||
| sleep 90 | ||
|
There was a problem hiding this comment. Why 90s? If there are migrations that aren't super quick or if the ephemeral pods created for the Gitlab Runners take longer to create it will take more than 90s. There was a problem hiding this comment. i'm using 90s as a minimum here, not a maximum. Then again, we don't pay for CPU cycle so i might as well just have it poll so the yaml is more clear! will rewrite |
||
| - name: Open PR to Push to Prod | ||
| run: | | ||
| BACKLINK="Production Job Id: $PROD_JOB_ID\nStaging Job Id: $JOB_ID" | ||
| TEMPLATE=$(tail -n +12 .github/ISSUE_TEMPLATE/release_test.md) | ||
| CHANGES=$(perl -0777ne 'print "$1\n" and exit if m/\n##\s[^\n]*\n+(.*?\n)##?\s|$/gs;' CHANGELOG.md) | ||
| BODY="${BACKLINK}\n\n${TEMPLATE}\n\n\n${CHANGES}" | ||
| gh pr create \ | ||
| --assignee ${{ github.actor }} | ||
| --base production | ||
| --title "chore(release): Test v${{ env.ACTION_VERSION }}" | ||
| --body "$BODY" | ||
| - name: Poll Staging Release | ||
| uses: artiz/[email protected] | ||
| with: | ||
| url: https://gitlab.com/api/v4/projects/${{ vars.GITLAB_PROJECT_ID }}/jobs/${{ env.JOB_ID }} | ||
| method: GET | ||
| expect-status: 200 | ||
| expect-response-regex: '"status":"success"' | ||
| timeout: 120000 | ||
| interval: 3000 | ||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why using the production branch? IMHO using branches for environments in an Open Source repository isn't a good pattern. Our repository hosts the code of our application, and to know what's in production we can know by checking the latest released tag.
We have multiple instances of Parabol (PPMIs and both SaaS) and we might have more in the future. IMHO it doesn't scale.
If we are going to do this, I would at least use a branch public-saas instead of production. At least it would be clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oh man, i didn't even think about pushing to PPMIs from github! I say we keep PPMIs out of github, since devs shouldn't even have to mess with them. i don't mind the name, but we call it production everywhere else, so i figured we could keep the name here, too?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's keep production then. If we need to change it in the future, we can change it easily.