actions/create-release@v1 is not found

[okuryu]

When trying to use actions/create-release@v1 not actions/create-release@master, it seems to be not found as follows.

workflow:

      - uses: actions/create-release@v1
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        with:
          tag_name: ${{ github.ref }}
          release_name: Release ${{ github.ref }}

build logs:

2019-11-05T12:38:27.1324943Z ##[section]Starting: Request a runner to run this job
2019-11-05T12:38:27.7073875Z Requesting a hosted runner in current repository's account/organization with labels: 'ubuntu-latest', require runner match: True
2019-11-05T12:38:27.9223384Z Labels matched hosted runners has been found, waiting for one of them get assigned for this job.
2019-11-05T12:38:27.9480373Z ##[section]Finishing: Request a runner to run this job
2019-11-05T12:38:33.7981673Z Current runner version: '2.160.0'
2019-11-05T12:38:33.7982698Z Prepare workflow directory
2019-11-05T12:38:33.8214357Z Prepare all required actions
2019-11-05T12:38:33.8246552Z Download action repository 'actions/checkout@v1'
2019-11-05T12:38:35.1115788Z Download action repository 'actions/setup-node@v1'
2019-11-05T12:38:36.1045139Z Download action repository 'actions/create-release@v1'
2019-11-05T12:38:36.2948582Z ##[warning]Failed to download action 'https://api.github.com/repos/actions/create-release/tarball/v1'. Error Response status code does not indicate success: 404 (Not Found).
2019-11-05T12:38:36.2954290Z ##[warning]Back off 16.36 seconds before retry.
2019-11-05T12:38:52.7780070Z ##[warning]Failed to download action 'https://api.github.com/repos/actions/create-release/tarball/v1'. Error Response status code does not indicate success: 404 (Not Found).
2019-11-05T12:38:52.7782936Z ##[warning]Back off 21.903 seconds before retry.
2019-11-05T12:39:14.8511327Z ##[error]Response status code does not indicate success: 404 (Not Found).

[IAmHughes]

Hi @okuryu, I believe the issue is that the tagged release is actually v1.0.0 not v1.

That said, you‘ve made me realize the README example says @master which isn’t a best practice, so I’ll update that! Thanks!

Please let me know if updating the version reference fixes your issue. I’ll reopen if it doesn’t.

[okuryu]

Hmm, I just thought it would be better to have a v1 alias to allows customers to use the latest version while maintaining compatibility.

https://help.github.com/en/github/automating-your-workflow-with-github-actions/workflow-syntax-for-github-actions#jobsjob_idstepsuses

• Using the specific major action version allows you to receive critical fixes and security patches while still maintaining compatibility. It also assures that your workflow should still work.

[IAmHughes]

@okuryu I appreciate the suggestion, we are using semantic versioning so we use the full v1.0.0 labeling.

[eine]

@okuryu I appreciate the suggestion, we are using semantic versioning so we use the full v1.0.0 labeling.

IMHO, providing both v1 and v1.0.0 is precisely the purpose of semantic versioning. Otherwise, users are forced to manually update their workflows for each minor patch or hotfix.

[okuryu]

IMHO, providing both v1 and v1.0.0 is precisely the purpose of semantic versioning. Otherwise, users are forced to manually update their workflows for each minor patch or hotfix.

Exactly.

[IAmHughes]

IMHO, providing both v1 and v1.0.0 is precisely the purpose of semantic versioning. Otherwise, users are forced to manually update their workflows for each minor patch or hotfix.

@1138-4eb and @okuryu I may be misunderstanding the concern, but what would force you to manually updated your workflow for every minor patch or hotfix? The old release will still be valid and work, and if you wanted to wait to update until a major version came out you would still make the same change to your workflow.

What I mean is when v1.0.1 comes out, that doesn't mean v1.0.0 is no longer available.

I did test to see if a workflow can have a wildcard, i.e. something like v1.* and unfortunately they do not currently.

---

Reopening since we are having open discussion still 😄

[eine]

but what would force you to manually updated your workflow for every minor patch or hotfix?

We mean that you need to manually update the workflow for it to use the latest patch/hotfix, not that it will break.

According to https://semver.org/:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.

Therefore, it is a contract between developers and users (other developers) about the stability of the API. MINOR and PATCH updates are expected to be backwards compatible, so that any user can automatically apply them with little risk for things to break.

From this point of view, in the JS ecosystem, dependencies are normally expressed as ^x.y.z. This allows build tools to pick not x.y.z specifically, but rather any x.yy.zz. I.e., as long as the major version is the same, everything should be good.

So, in the context of GitHub Actions, a user would expect v1.0.0 to be a fixed reference, but either v1.0 or v1 should be 'rolling' references. Currently, all three references point to the same commit. When v1.0.1 comes out, v1.0 and v1 should be updated. When v1.1.0 comes out, v1 should be updated and a new v1.1 should be created. At that point, we would have:

• v1.0.0
• v1.0.1 v1.0
• v1.1.0 v1.1 v1

Users referring to v1 would have picked all the updates automatically, without manually modifying their sources.

I did test to see if a workflow can have a wildcard, i.e. something like v1.* and unfortunately they do not currently.

Well, the purpose of vX.Y and vX is precisely to work around a currently poor implementation of version handling on GitHub's end.

[ethomson]

We'll publish the v1 tag and the specific v1.x.x tag at the same time, pointing to the same commit. This is our documented best practice. It lets users use semver (ie, reference v1 or reference an explicit version) and we can move that v1 tag as we roll out releases.

[eine]

@ethomson, thanks for clarifying! Do you know if proper semantic tag support is planned? With proper I mean either wildcards, as @IAmHughes tried, or full npm semver support?

[ethomson]

Yep, something we're looking at soon.

[mscoutermarsh]

v1 has been tagged. Thanks all.