v2 tag doesn't match latest v2.3.0 tag

[kurtmckee]

Please update the v2 tag in the repo to point to the latest release (v2.3.0 as I write this).

It's currently pointing to the previous release SHA.

Thanks!

[afinetooth]

Thanks @kurtmckee. We'll get that handled asap.

[kurtmckee]

The v2 tag is drifting further, and now appears to be missing some recent bug fixes and improvements.

[afinetooth]

@kurtmckee Thanks for the update.

I have not been able to reproduce this drift in action version, so I’m missing something.

Can you help me with a little more context, such as your CI config for your Coveralls step(s), and your CI build log, at least the portion pertaining to Coveralls?

If you could set debug: true that would be ideal since it turns on set -x style debugging (at least in the latest versions).

I’ve added tests to the action now, which you can see in later versions with their results. This is what I will do, but you are welcome to as well: We can start a new PR, replicate your config details in the .gitHub/workflows/test.yml workflow there, and see if we can reproduce.

[kurtmckee]

This is what I'm referring to:

It is common practice for repos hosting GitHub actions to force major-version git tags (like v2 in the screenshot above) to match the latest version tag. This allows most repos to reference the action using the syntax coverallsapp/github-action@v2 and use the latest major version of the action.

When v2.3.2 was released yesterday, the v2 tag should have been updated to point to the same commit SHA (43f11c4), but it hasn't been; it's still pointing to the v2.2.3 commit SHA, released over a year ago.

This is a significant gap in the release process, and it's what this issue is reporting.

[kurtmckee]

For example, if you look at the CI workflow in coverallsapp/coverage-reporter, you'll observe this line:

    - uses: actions/checkout@v4

Then, checking the tags in the actions/checkout repository, you'll see that their v4 tag points to their latest v4 release, v4.2.1:

I'm requesting that the coverallsapp team continuously update the v2 git tag as new versions are released. This is the standard practice for repos hosting GitHub actions.

[afinetooth]

Whoah, I've never seen that before, where a tag/release (for v2 in this case) appears after a subsequent version, like v2.2.2.

Thank you for the examples and screenshots! Apologies, I think I just wasn't able to "see" that before.

I'm relatively new at managing these releases. Let me figure out what went wrong here and how to fix it...

[kurtmckee]

It's definitely a deviation from the common git practice "immutable repo history" but it's a very specific deviation for GitHub action repos. 👍

[afinetooth]

@kurtmckee this should be fixed.

Please let me know if it appears otherwise for you.

I don't know how we ended up with a v2 release, which was essentially a duplicate of our v2.2.3 release. The pattern we follow elsewhere is to tag releases v2.0, or v2.0.0, and reserve v2 (without dots) as a floating tag pointing to the latest release.

That's the pattern I reimplemented in this repo; although it took a minute since I was being careful, wary to change anything historical that I hadn't done myself nor understood the reasoning for.

[kurtmckee]

Sure does! Thanks!

I don't know if your release process is scripted or documented, but I recommend adding that v2 tag update step in, if possible.

Thanks for your work on this! 🥳

[afinetooth]

I recommend adding that v2 tag update step in, if possible.

That's a good recommendation. I am just looking for a common pattern to do that. Are you familiar with one?

[afinetooth]

I found a good example, so I'm good there! ^^

Thanks for your patience!!

[afinetooth]

This should ensure this doesn't happen again:

• Always point the major version tag to the latest release #230

In case it's helpful to anyone with a similar issue, here's a generic workflow to make sure the major version tag (ie. v2) (the "floating" tag) always points to the latest release (latest subversion of the major version, ie. v2.3.2).

Will work for any major version (v2, v3, v4, etc.):

# update-major-version-tag.yml
name: Update Major Version Tag

on:
  release:
    types: [published]

jobs:
  update-major-version-tag:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout Repository
        uses: actions/checkout@v4

      - name: Extract Major Version
        id: extract_major_version
        run: |
          # Extract the major version part (e.g., "v2" from "v2.3.1")
          echo "release_tag=${{ github.event.release.tag_name }}" >> $GITHUB_ENV
          major_version=$(echo "${{ github.event.release.tag_name }}" | grep -oE "^v[0-9]+")
          echo "major_version=$major_version" >> $GITHUB_ENV

      - name: Update Major Version Tag
        run: |
          git fetch --tags
          git tag -f ${{ env.major_version }} ${{ github.event.release.tag_name }}
          git push origin ${{ env.major_version }} --force

      # (Optional)
      # Reset the major version tag on the local runner in case it's helpful for subsequent workflow steps.
      - name: Fetch Updated Tags
        run: git fetch --tags --force

      # (Optional)
      # Display new details on the major version tag to verify it points to the latest release.
      - name: Verify Tag
        run: git show ${{ env.major_version }}

[kurtmckee]

Nice! Thank you!