From eeb99d4885b2dd1ce34f1ee36b6929c738787c61 Mon Sep 17 00:00:00 2001 From: Vadorequest Date: Mon, 9 Jan 2023 22:06:49 +0100 Subject: [PATCH] Auto-release current major version (ex: @v2) (#91) --- .../workflows/auto-git-release-production.yml | 13 ++++++- .../workflows/auto-git-release-staging.yml | 11 ++++++ README.md | 37 +++++++++++++++---- 3 files changed, 53 insertions(+), 8 deletions(-) diff --git a/.github/workflows/auto-git-release-production.yml b/.github/workflows/auto-git-release-production.yml index 27495305..34f8e7ae 100644 --- a/.github/workflows/auto-git-release-production.yml +++ b/.github/workflows/auto-git-release-production.yml @@ -48,7 +48,7 @@ jobs: echo "previous_commit: ${{steps.next_semantic_version.outputs.previous_commit}}" echo "current_commit: ${{steps.next_semantic_version.outputs.current_commit}}" - - name: Creating Git release tag for the ${{steps.next_semantic_version.outputs.version_tag}} version + - name: Creating Git release tag for the "${{steps.next_semantic_version.outputs.version_tag}}" version uses: softprops/action-gh-release@v1 with: # See https://github.com/softprops/action-gh-release#-customizing token: "${{ secrets.GITHUB_TOKEN }}" @@ -69,3 +69,14 @@ jobs: generate_release_notes: true files: | CHANGELOG.md + + - name: Updating Git release tag for the major "${{steps.next_semantic_version.outputs.major}}" version + uses: softprops/action-gh-release@v1 + with: # See https://github.com/softprops/action-gh-release#-customizing + token: "${{ secrets.GITHUB_TOKEN }}" + tag_name: ${{steps.next_semantic_version.outputs.major}} + name: "${{steps.next_semantic_version.outputs.major}} latest release (auto-update)" + prerelease: false + generate_release_notes: true + files: | + CHANGELOG.md diff --git a/.github/workflows/auto-git-release-staging.yml b/.github/workflows/auto-git-release-staging.yml index 78aa5abe..1d2bc115 100644 --- a/.github/workflows/auto-git-release-staging.yml +++ b/.github/workflows/auto-git-release-staging.yml @@ -68,3 +68,14 @@ jobs: generate_release_notes: true files: | CHANGELOG.md + + - name: Updating Git release tag for the major "${{steps.next_semantic_version.outputs.major}}-rc" version + uses: softprops/action-gh-release@v1 + with: # See https://github.com/softprops/action-gh-release#-customizing + token: "${{ secrets.GITHUB_TOKEN }}" + tag_name: "${{steps.next_semantic_version.outputs.major}}-rc" + name: "${{steps.next_semantic_version.outputs.major}}-rc latest release (auto-update)" + prerelease: true + generate_release_notes: true + files: | + CHANGELOG.md diff --git a/README.md b/README.md index 7c1ddcc6..351806aa 100644 --- a/README.md +++ b/README.md @@ -15,7 +15,7 @@ jobs: wait-for-vercel-deployment: runs-on: ubuntu-22.04 steps: - - uses: UnlyEd/github-action-await-vercel@latest # TODO best practices recommend to use a fixed version instead of @latest for production usage (i.e: @v1.2.32) + - uses: UnlyEd/github-action-await-vercel@v1 # TODO best practices recommend to use a fixed version instead of @v1 for production usage (i.e: @v1.2.32) id: await-vercel env: VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} @@ -100,7 +100,7 @@ In the below example, we show you how to: 1. **Step 1**: Forward `VERCEL_DEPLOYMENT_URL` as an ENV variable, using ` >> $GITHUB_ENV"` which stores the value into the GitHub Actions env vars. Of course, you might do it differently. It doesn't really matter as long as `VERCEL_DEPLOYMENT_URL` is set. -1. **Step 2**: Then, we use the `UnlyEd/github-action-await-vercel@latest` GitHub Action, which waits for the deployment url to be ready. +1. **Step 2**: Then, we use the `UnlyEd/github-action-await-vercel@v1` GitHub Action, which waits for the deployment url to be ready. 1. **Step 3**: Finally, we show an example on how to read the deployment's information returned by the Vercel API (which have been forwarded). ```yaml @@ -117,7 +117,7 @@ jobs: - name: Retrieve deployment URL (example on how to set an ENV var) run: "echo VERCEL_DEPLOYMENT_URL=nextjs-bzyss249z.vercel.app >> $GITHUB_ENV" - - uses: UnlyEd/github-action-await-vercel@latest # TODO best practices recommend to use a fixed version instead of @latest for production usage (i.e: @v1.2.32) + - uses: UnlyEd/github-action-await-vercel@v1 # TODO best practices recommend to use a fixed version instead of @v1 for production usage (i.e: @v1.2.32) id: await-vercel env: VERCEL_TOKEN: ${{ secrets.VERCEL_TOKEN }} @@ -201,11 +201,34 @@ Our versioning process is completely automated, any changes landing on the `main ## Releases versions: -- We do not provide major versions that are automatically updated (e.g: `v1`). -- We only provide tags/releases that are not meant to be changed once released (e.g: `v1.1.0`). +The examples above use an auto-updated major version tag (`@v1`). +It is also possible to use the `@latest` and `@latest-rc` tags. (RC stands for "Release candidate", which is similar to a Beta version) -> As utility, we provide a special [`latest`](../../releases/tag/latest) tag which is automatically updated to the latest release. -> _This tag/release is **not meant to be used in production systems**, as it is not reliable (might jump to the newest MAJOR version at any time)._ +While those options can be useful, we intend to give some "production-grade" best practices. + +- **Do NOT use `@latest` for production**, ever. While only "supposed-to-be-stable" versions will be tagged as `@latest`, it could harbor bugs nonetheless. +- You can use auto-upgrading major version, such as `@v1`, but this is not a best practice, see our explanations below. + +### Special tags and production-grade apps best practices + +Here are a few useful options you can use to pin a more-or-less specific version of our GitHub Action, alongside some "production-grade" best practices. + +- `@{COMMIT-SHA}`, e.g: `@1271dc3fc4c4c8bc62ba5a4e248dac95cb82d0e3`, recommended for all production-grade apps, it's the only truly safe way to pinpoint a version that cannot change against your will (**SAFEST**) +- `@{MAJOR}-{MINOR}-{PATCH}`, e.g: `@v1.2.31`, while not as safe as the `COMMIT-SHA` way, it's what most people use (SAFER) +- `@{MAJOR}`, e.g: `@v1`, can be used on production, but we do not advise to do so (SAFE-ISH) +- `@{MAJOR}-rc`, e.g: `@v1-rc`, **reserved for development mode**, useful when debugging on a specific prerelease version (UNSAFE) +- `@latest`, **reserved for development mode**, useful when debugging (UNSAFE) +- `@latest-rc`, **reserved for development mode**, useful when debugging on prerelease versions (UNSAFE) + +**"But, what is the issue with the `@{MAJOR}-{MINOR}-{PATCH}` way to pin a specific version"?** + +> Well, if our repositories gets hacked by a 3rd party, **they can easily change all Git tags to a different commit**, which could contain malicious code. + +That's why **pinning a specific commit SHA is the only truly safe option**. This way, the code you're using **cannot be changed against your will**. + +Most people won't care about this and will use a MAJOR version tag instead anyway, such as `@v1`. It's common, but not the best practice. + +It all comes down to the risks you're ready to take, and it's up to you to decide what's best in your situation. ---