version check makes it impossible to use the action with a certain commit

[till]

Kinda a follow-up to #112, I wanted to test the action and pin it to a commit. But it seems like the option is to run your actions with ...@vVERSION or ...@master. Neither might be desirable to test unreleased code.

The offending lines are here:
https://github.com/ariga/atlas-action/blob/master/shim/index.js#L18-L28

Is there a good reason to bail there?

[till]

Looks like the action version is used for the download, so I see why. It's just a bit unconventional to not allow this. Especially since many people prefer the commit vs a fluent version like v1, let alone master.

[rotemtam]

Because this action is written in Go, the option to checkout and compile at runtime was just too slow that we didn't want to ship it.

Instead, we build the binary for master and for tags and use the tag to decide what to only download the prebuilt binary.

[sdemjanenko]

Would it be possible to add a input variable to the action to specify which version of the go binary to use? I'd like to lock the github action to a specific SHA commit hash and I am hitting this issue.

[rotemtam]

Hey @sdemjanenko

Thanks for reaching out. If I understand correctly, you want to use a specific SHA commit id for the version when using it, i.e

- uses: ariga/atlas/action/migrate-push@abc123

Instead of using a specific tag:

- uses: ariga/atlas/action/migrate-push@v1.2.3

Since the action shim, looks at version tags to decide what version of the atlas-action binary to download, that is failing.

Did I get that right?

[sdemjanenko]

@rotemtam yes that is correct. I wonder if something like

- uses: ariga/atlas/action/migrate-push@abc123
  with:
     version: v1

could be a solution.

Also if I wanted to set up a stricter configuration, I might want to set a checksum for the binary

- uses: ariga/atlas/action/migrate-push@abc123
  with:
     version: v1.2.3
     checksum: <hash here>

and in this case the action would checksum the binary and make sure it matches before executing.

[rotemtam]

I understand the need and the suggestion, but I don't love having two different ways of achieving the same thing.

Why is pinning the action version tag an issue?

[till]

For me, I'd like to have an option when I update to address maybe necessary changes vs getting failed builds etc. when I least expect or need it.

Same with all other software.

[rotemtam]

@till , I understand that, but you can pin a specific tag such as v1.2.3 which is bound to a specific build.

[sdemjanenko]

@rotemtam pinning the action is a security best practice. Here is a recent article talking about how github actions aren't pinned enough: https://devops.com/report-surfaces-thousands-of-potential-vulnerabilities-in-github-workflows/amp/. Also here is a tool that I am using to automatically flag if my github actions have this problem: https://github.com/zgosalvez/github-actions-ensure-sha-pinned-actions