Versioning

[thewilkybarkid]

I'm following the current README instructions to use superfly/flyctl-actions/setup-flyctl@master, which works great. However, I'd rather pin a version of the action (and let Dependabot update it).

https://github.com/marketplace/actions/github-action-for-flyctl currently shows 1.1 as the latest version:

But the latest tag is 1.3.

I've not published an Action, so I'm not sure what the details are, but could they be aligned and the README changed? (Using v1 there like setup-node is fine, but I'd like to be able to pin it to v1.3.0.)

[PatrickHeneise]

@1.1 doesn't seem to work: Can't find 'action.yml', 'action.yaml' or 'Dockerfile' under '/home/runner/work/_actions/superfly/flyctl-actions/1.1/setup-flyctl'

[mglazer]

I also would love from a security standpoint if there were verified tagged releases that we could depend on, rather than just depending on whatever happens to be latest, and have that potentially break our deployment steps.

[dmarcoux]

Meanwhile, it's possible to pin GitHub actions to a commit SHA like this:

- uses: superfly/flyctl-actions/setup-flyctl@67ddda2a87628f1aff28a54b8a708879ec62c80f # 1.1

Dependabot will update the commit SHA whenever there's a new commit. The comment next to the commit will also be updated if the version number changes.

[jasonkuhrt]

Over the past 2 months we hit two (1,2) bugs and we're also interested in versioning from now on.

It would be nice to have official guidance and commitment from the team about what to expect on versioning (e.g. use semver).

[jasonkuhrt]

Actually I see that there is already what we want which is versioning for flyctl itself: https://github.com/superfly/flyctl-actions#usage-for-deployment.

[geemus]

Would it be possible to get a new version released as asked for above? I wanted to switch to the setup-flyctl usage, but don't want to point to master to avoid brittleness.

[jsierles]

Most people will be fine with versioning flyctl itself like this:

- uses: superfly/flyctl-actions/setup-flyctl@master
  with:
    version: 0.1.0

If we do another release of the action itself, we'll version it.

[jsierles]

v4.1 and also the major v1 tag have been added. This should let you use setup-flyctl. Sorry for the trouble.

[thewilkybarkid]

@jsierles I just tried, but my build has failed with:

Error: Unable to resolve action `superfly/flyctl-actions@v1.4`, unable to find version `v1.4`

[thewilkybarkid]

Oh, hang on, the release is named v1.4, but the tag is actually just 1.4.

[jsierles]

I just added v1.4 as well.

[thewilkybarkid]

Thanks, it's working now.

[Eomm]

Hi, just to share that we use this GH workflow to release a githubaction 😄

• The GHA: https://github.com/nearform-actions/optic-release-automation-action
• An easier example to read: https://github.com/fastify/workflows/blob/main/.github/workflows/release.yml

It syncs the minor/major/patch git tags so users can pin:

myaction@v1 -> always the most recent major
myaction@v1.5 -> always the most fixed minor
myaction@v1.5.1 -> stick to this version

When you want to release you need to:

• run a GH workflow
• approve and merge an automatic PR that list all the commits that are being released
• wait for the job done 😄