Action versioning not following GitHub recommendations

[snok]

Action versioning not following GitHub recommendations

[sondrelg]

You'll need to help me out here @frank-fischer-by @JonasKs; how does this look? 🙂

https://github.com/snok/install-poetry/blob/main/.github/workflows/tag_release.yml

If this seems functional, I'll add a test to make sure we're able to run the action with the v1 tag and update the readme tomorrow 👏

Sorry, currently have a lot on my plate, so I simply didn't get around to creating the PR.
The functionality generally looks great. I just ran a workflow and tested that

- name: Install Poetry
  uses: snok/install-poetry@v1

correctly pulls 1.1.6 ❤️

As @JonasKs pointed out, that code is not 100% future proof, once v2 would roll around, so maybe add

run: |
  git tag "${GITHUB_REF:0:2}"
  git push origin HEAD:refs/heads/master --tags --force

Concerning the discussion around (other) tags, that's not really defined by GitHub.

As long as v1points to "latest" v1.X.Ythat's probably the 99.9% case.
Having v1.X might be "nice" but I personally wouldn't bother if semantic versioning is used and v1.2 is compatible with v1.1.

[sondrelg]

Can you not do this today?

uses: snok/install-poetry@v1

If so, am I reading this correctly - that we would just need to git tag each new release with v1 to move the v1 reference?

I would love to do this, as it would save us having to update patch versions in the readme every time we update something haha 🙂 Do you think this would be something we could automate with a workflow triggered by a release in the repo?

git is super naïve in that regard - it doesn't do anything if the GIT_REF does not exist, so it's as you said

we [would] just need to git tag each new release with v1 to move the v1 reference

✅

Do you think this would be something we could automate with a workflow triggered by a release in the repo?

I'm not sure how https://docs.github.com/en/actions/reference/events-that-trigger-workflows#release and git tags are related, but I would expect acting on release by updating the tag should work (or if you get a circular dependency 😬)

In theory a small workflow like

on:
  release:
    types:
      - "published"
jobs:
  create-tag:
    name: "create-tag"
    runs-on:
      - "ubuntu-latest"
    timeout-minutes: 2
    steps:
      - name: "Check out repository"
        uses: "actions/checkout@v2"
      - name: "Bump version and push tag"
        # see https://github.com/marketplace/actions/github-actions-create-tag
        uses: "laputansoft/github-tag-action@v4"
        with:
          github_token: ${{ env.github-token }}
          tag: "v1"

should work 🤞

[sondrelg]

Seems like a nice way to handle it 👏

Perhaps we don't even need a separate action - this seems to have ~all the code we need.

Would you be interested in trying to implement it? If not I'll try to get this done within a day or two 👍

[JonasKs]

Looks good to me, but I guess that action don't really scale if you need a v2.
Maybe check github.event.ref and get the first two letters, and release to that version? So if a v2.2 is published, push to v2 and not v1?

[miigotu]

Looks good to me, but I guess that action don't really scale if you need a v2.
Maybe check github.event.ref and get the first two letters, and release to that version? So if a v2.2 is published, push to v2 and not v1?

v2 ends up being the highest versioned of v2, so if you have a v2.3.1, a v2.3.4 and a v2.4, v2.4 is pointed to by v2 tag, as well as the v2.2 tag. v2.3.4 would still be tagged as v2.3.4 and v2.3. v2.3.1 is only tagged as v2.3.1 because it is not the highest of the v2 or of the v2.3 versions availed, but it is always itself (v2.3.1).

[sondrelg]

Yep I think this sounds like the desired behaviour. In other words, someone who has specified

- name: Install Poetry
  uses: snok/install-poetry@v2

will always be on the latest version of v2 👍

[sondrelg]

I suppose we could tag major and minor versions if we wanted 🤔

[sondrelg]

Quickly tested in a separate repo: https://github.com/sondrelg/test-tagging/runs/3069653365?check_suite_focus=true

I believe this workflow should do the trick

name: Tag releases with minor and major version

on:
  release:
    types: [published]

jobs:
  tag-v1:
    name: Tag v1
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Update tag
        run: |
          major_tag="$(python get_version.py "${GITHUB_REF}" major)"
          minor_tag="$(python get_version.py "${GITHUB_REF}" minor)"
          git tag $major_tag
          git tag $minor_tag
          git push origin HEAD:refs/heads/master --tags --force
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Where get_version.py can be kept in the repo and looks like this

import sys

from packaging import version

if __name__ == '__main__':
    ref = sys.argv[1]  # ref will usually look like refs/tags/v1.0.1
    major = sys.argv[2] == 'major'
    version = version.parse(ref.split('refs/tags/v')[1])

    if major:
        print(f'v{version.major}')
    else:
        print(f'v{version.major}.{version.minor}')

Does that seem like a reasonable solution?

[sondrelg]

If the ref doesn't follow the correct format the script will throw an IndexError and exit out, which seems like the right thing to do