Referencing major version of GitHub action only fails to download action

According to the documentation at it is possible to specify major, minor, or patch versions for a GitHub action.

However, wenn I specify the following workflow:

  - push
  - pull_request

name: Continuous Integration

        name: Foo

        runs-on: ubuntu-latest

            - name: "Checkout"
              uses: actions/checkout@v1

            - name: "Create file"
              run: touch foo.txt

            - name: "Commit file"
              uses: stefanzweifel/git-auto-commit-action@v2
                  commit_message: "Enhancement: Add file"
                  file_pattern: foo\.txt
                  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

the build fails to set up the job with the following messages

Current runner version: '2.162.0'
Prepare workflow directory
Prepare all required actions
Download action repository 'actions/checkout@v1'
Download action repository 'stefanzweifel/git-auto-commit-action@v2.4'
##[warning]Failed to download action ''. Error Response status code does not indicate success: 404 (Not Found).
##[warning]Back off 26.531 seconds before retry.
##[warning]Failed to download action ''. Error Response status code does not indicate success: 404 (Not Found).
##[warning]Back off 16.342 seconds before retry.
##[error]Response status code does not indicate success: 404 (Not Found).

As far as I’m concerned, when specifying a major version only, I would expect the latest version to be downloaded, not attempting to download a tag that doesn’t exist.

Here’s what I suggest:

  • use semantiv versioning to resolve the latest version that satisfies the specified version

  • allow using ^ or ~ operators to specify versions

  • properly resolve versions

  • show actually installed versions

workflow as such, using, 


Hi @localheinz, thanks for the feedback.  At the moment, we encourage action authors to publish tags that align with semantic versions.  We do not currently resolve the semantic versioning within the Actions platform itself.

However, I appreciate that this can lead to inconsistencies when using actions that don’t adopt this workflow.  Thanks for your suggestions - we’ll give this workflow some more thought.

1 Like

Hello @ethomson!

For clarification, when referencing 

uses: actions/cache@v1

and with the following tags 


available - which one will be used?

For reference, see

1 Like

Maybe I’m missing something but isn’t GitHub effectively recommending rewriting history with this suggestion? Once I pushed a tag I can’t just move it. I have to remove it and create a new one followed by push -f.

I think release branches should be prefferred since they don’t require rewriting history.

1 Like

I also believed that referencing @v1 the newest version within major version 1 would be used.

After enabling step debug logging I understand this is not the case.

In your example, referencing @v1 would return the version tagged v1 :confused:

We are also facing the same issue. We have a composite action with releases named v0.1.0, v0.1.1v0.1.5. When I try to reference v0.1, I get the error "unable to find version v0.1".

I could imagine that resolving the version works for docker images, but not for composite actions? In any case the current documentation is either wrong or incomplete.