-
Notifications
You must be signed in to change notification settings - Fork 100
[other] ENGMT-1857: add gha for release #1083
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.
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
Changes from 3 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,97 @@ | ||
| name: Publish Next Release (Manual) | ||
|
|
||
| on: | ||
| workflow_dispatch: | ||
| inputs: | ||
| ref: | ||
| description: Reference git commit to release (e.g. "master", "12341fa") | ||
| required: true | ||
| default: master | ||
|
|
||
| env: | ||
| NODE_VERSION: 18 | ||
|
|
||
| jobs: | ||
| publish: | ||
| runs-on: ubuntu-latest | ||
| steps: | ||
| - uses: actions/checkout@v4 | ||
| with: | ||
| ref: ${{ github.event.inputs.ref }} | ||
|
|
||
| - name: AWS, credentials setup | ||
| uses: aws-actions/configure-aws-credentials@v4 | ||
| with: | ||
| aws-region: us-west-1 | ||
| aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }} | ||
| aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }} | ||
|
|
||
| - name: Add INPUT_SHA env var | ||
| run: | | ||
| export INPUT_SHA=$(git rev-parse ${{ github.event.inputs.ref }}) | ||
| echo "INPUT_SHA=`echo $INPUT_SHA`" >> $GITHUB_ENV | ||
| - name: Install branch-github-actions | ||
| uses: actions/checkout@v4 | ||
| with: | ||
| repository: BranchMetrics/branch-github-actions | ||
| ref: master | ||
| path: .branch-github-actions | ||
| token: ${{ secrets.BRANCHLET_ACCESS_TOKEN }} | ||
|
|
||
| - name: Get next release version | ||
| uses: actions/github-script@v7 | ||
| id: next-version | ||
| with: | ||
| result-encoding: string | ||
| script: | | ||
| const getNextVersion = require('./.branch-github-actions/custom-scripts/next-version'); | ||
| const nextVersion = await getNextVersion({ | ||
| core, | ||
| github, | ||
| context, | ||
| sha: process.env.INPUT_SHA, | ||
| }); | ||
| return nextVersion; | ||
| env: | ||
| INPUT_SHA: ${{ env.INPUT_SHA }} | ||
|
|
||
| - name: Install Node ${{ env.NODE_VERSION }} | ||
| uses: actions/setup-node@v4 | ||
| with: | ||
| node-version: ${{ env.NODE_VERSION }} | ||
|
|
||
| - name: Write version to files | ||
| run: | | ||
| ./deployment/write-versions.sh ${{ steps.next-version.outputs.result }} | ||
| - name: Configure NPM | ||
| run: npm ci | ||
|
|
||
| - name: Release to npm, s3, prod | ||
| run: | | ||
| ./deployment/release.sh ${{ steps.next-version.outputs.result }} | ||
| # We deploy to stage to send the updated release numbers. The code should not be any different | ||
| - name: Release to stage | ||
| run: | | ||
| ./deployment/deploy-qa.sh ${{ steps.next-version.outputs.result }} | ||
| - name: Create Github Release | ||
| uses: actions/github-script@v7 | ||
| env: | ||
| GE_NEXT_VERSION: ${{ steps.next-version.outputs.result }} | ||
| INPUT_SHA: ${{ env.INPUT_SHA }} | ||
| with: | ||
| result-encoding: string | ||
| script: | | ||
| const createRelease = require('./.branch-github-actions/custom-scripts/create-release'); | ||
| const sha = process.env.INPUT_SHA; | ||
| const version = process.env.GE_NEXT_VERSION; | ||
| await createRelease({ | ||
| core, | ||
| context, | ||
| github, | ||
| sha, | ||
| version, | ||
| }); | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -39,4 +39,5 @@ test-results.json | |
| .direnv/ | ||
| dev.config | ||
| dev.html | ||
| example.html | ||
| example.html | ||
| dist/ | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -24,14 +24,12 @@ NC='\033[0m' | |
| ./deployment/build-example-html.sh "key_live_feebgAAhbH9Tv85H5wLQhpdaefiZv5Dv" "https://api.stage.branch.io" "https://cdn.branch.io/branch-staging-latest.min.js" | ||
| aws s3 cp example.html s3://branch-cdn/example-staging.html | ||
|
|
||
| ./deployment/build-example-html.sh "key_live_hcnegAumkH7Kv18M8AOHhfgiohpXq5tB" "https://api2.branch.io" "https://cdn.branch.io/branch-latest.min.js" | ||
| aws s3 cp example.html s3://branch-builds/web-sdk/example.html | ||
|
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. was looking at this more, we did this before my previous pr so i kept it in that pr. But, i dont understand the point of this so i removed it
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. how is the example page going to be uploaded in this new flow?
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. looks like it happens in a later file
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yeah this was deploying to prod, and also under this web-sdk prefix for some reason |
||
|
|
||
| echo -en "${GREEN}Pushing to CDN ...${NC}\n" | ||
| aws s3 cp --content-type="text/javascript" --content-encoding="gzip" dist/build.min.js.gz s3://branch-cdn/branch-staging-latest.min.js --cache-control "max-age=300" | ||
|
|
||
| echo -en "Invalidating cloudfront distribution for staging ...\n" | ||
| aws configure set preview.cloudfront true | ||
| aws cloudfront create-invalidation --distribution-id E10P37NG0GMER --paths /branch-staging-latest.min.js /example-staging | ||
|
|
||
| # Exit prompts | ||
| echo -en "${GREEN}Done deploy QA script ...${NC}\n" | ||
This file was deleted.
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,31 @@ | ||
| #!/bin/bash | ||
|
|
||
| [ $# -eq 0 ] && { echo "Usage: $0 1.0.0"; exit 1; } | ||
|
|
||
| VERSION_NO_V=$1 | ||
| VERSION="v"$VERSION_NO_V | ||
| DATE=$(date "+%Y-%m-%d") | ||
|
|
||
| echo "Releasing Branch Web SDK" | ||
|
|
||
| make release | ||
|
|
||
| ./deployment/build-example-html.sh "key_live_hcnegAumkH7Kv18M8AOHhfgiohpXq5tB" "https://api2.branch.io" "https://cdn.branch.io/branch-latest.min.js" | ||
| aws s3 cp example.html s3://branch-builds/example.html | ||
|
|
||
| aws s3 cp --content-type="text/javascript" --content-encoding="gzip" dist/build.min.js.gz s3://branch-cdn/branch-$VERSION.min.js --acl public-read | ||
| aws s3 cp --content-type="text/javascript" --content-encoding="gzip" dist/build.min.js.gz s3://branch-cdn/branch-latest.min.js --acl public-read | ||
|
|
||
| echo -en "Invalidating cloudfront distribution...\n" | ||
| aws configure set preview.cloudfront true | ||
| aws cloudfront create-invalidation --distribution-id E10P37NG0GMER --paths /branch-latest.min.js | ||
|
|
||
| npm publish | ||
|
|
||
| echo "Post-release sanity checks." | ||
| read -p "Can you visit https://cdn.branch.io/branch-$VERSION.min.js ?" -n 1 -r | ||
| echo | ||
| read -p "Is https://cdn.branch.io/example.html using the right version number $VERSION?" -n 1 -r | ||
| echo | ||
| read -p "Is https://www.npmjs.com/package/branch-sdk using the right version number $VERSION?" -n 1 -r | ||
| echo |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,7 @@ | ||
| #!/bin/bash | ||
|
|
||
| [ $# -eq 0 ] && { echo "Usage: $0 1.0.0"; exit 1; } | ||
|
|
||
| sed -i -e "s/\"version\":.*$/\"version\": \"$1\",/" package.json | ||
| sed -i -e "s/version = '.*';$/version = '$1';/" src/0_config.js | ||
| sed -i -e "s/version = '.*';$/version = '$1';/" test/web-config.js |
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.
wouldnt we want to do this first? before prod?
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.
sure
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.
i mean like as a separate step
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.
kind of like how we deploy applications to staging, then verify, then manually release to prod
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.
could we stage the gha release and new version, and then have a manual action to put this on the prod cdn? does that make sense for something like this?
Uh oh!
There was an error while loading. Please reload this page.
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.
i didnt want to increment the version every time in staging, just increment when we actually deploy. However, that would be another solutoin i suppose
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.
my worry would be something like: adds major commit -> updates major version. Finds bug, tags commit major again because we had to change some other part of the api. Now, when we deploy to prod we have incremented 2 versions when we prob should have just done 1
Uh oh!
There was an error while loading. Please reload this page.
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.
For manual pre-production "publications" we use
alphaandbetasuffixes. Example being https://www.npmjs.com/package/react-native-branch/v/6.4.0-alpha.0 Incrementing only the last part, without messing with the eventual version (as a suggestion)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.
ah gotcha, sorry, was unaware we were already deploying to staging separately. what youve got looks good, unless maybe we can use the beta/alpha tags like gabe is indicating?
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.
that is an interesting idea, but i think i came up with a better solution
I am just always going to calculate the next version in staging and deploy that. I.e:
current: 2.84, next 2.85
every staging deploy, we check, get 2.84, and deploy 2.85. The github release wont change tho!
on prod, we deploy 2.85, and write 2.85 to releaeses.
Then, next stage deploy we will deploy 2.86 over and over... and on and on