RFC: Update Current Workflow for Maintaining Major Release Tags

[Rajib DS_রাজীব]

Issue

Currently, our process of maintaining the major release tags is as follows:

• We create a PR with the necessary changes.
• We merge the PR.
• We create a new release with a new tag to publish in the marketplace.
• We move the major release tag to point to the latest release i.e

# 1 indicates the major release tag
git tag -f 1 <latest_release_tag>

Our current process

• doesn't follow GitHub recommended practice. GitHub encourages creating a release branch i.e release/v1 before creating the release tag i.e v1.0.2
• manually updating the major release tag might result in human errors like forgetting to update it.

Solution

In order to follow the GitHub recommended practice and reduce the effort of manually updating the release tag, here is what we can do:

• Create a new Release Pull Request: We can create a new PR corresponding to the new release tag we want to publish. We are already following this convention in client projects.
• Create a new GH Workflow for updating Major Release Tag: We can introduce a new GH Action workflow that will trigger right after we create a new release. The workflow will update the major release tag to point to the latest release. Popular Actions like actions/checkout follow this practice as well. Our workflow file could look like the following:

name: Move Major Release Tag

on:
  release:
    types: [created]

jobs:
  update_major_release:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3

    - name: Get the major version num and update the tag
      run: |
        LATEST_TAG=${{github.ref_name}}
        MAJOR_VERSION=${LATEST_TAG%%.*}
        # why Hoang? explanation after this
        git config user.name 'Hoang Mirs'
        git config user.email '[e-mail]'
        git tag -fa ${MAJOR_VERSION} -m "Update major version tag"
        git push origin ${MAJOR_VERSION} --f

Why @hoangmirs's username and email in the action? 😅
Because I can see his email on the security contact email:

Who Benefits?

developers

What's Next?

• Agree on creating a release PR before publishing a new release tag.
• Agree on using GH action to automate updating the major release tag to point to the latest release.
• If we agree on the above, then we talk about the Git configuration inside the action

Resources

• actions/checkout
• cicirello/jacoco-badge-generator

[Olivier Robert]

The only concern is the event that triggers the workflow to update the latest tag. This workflow should only be run when the release PR is merged.

[Rajib DS_রাজীব]

Thanks for the catch @olivierobert
I think instead of triggering the workflow when the release PR is merged, we can trigger the workflow when we publish the release. It's also recommended by GitHub as well

Our workflow file can be updated accordingly to get triggered after publish

on:
  release:
    types: [published]