Make it possible to digest-pin the iter8 install action

[chgl]

Is your feature request related to a problem? Please describe. It is recommended to pin github actions by their commit hash to ensure reproduciability and enhance the supply chain security: https://michaelheap.com/ensure-github-actions-pinned-sha/. This is also something the OpenSSF Scorecard projects will notify the users about: https://github.com/ossf/scorecard.

It's currently not possible to pin the iter8-tools/iter8 action by its commit hash since the action relies on the tag to determine the version to install: https://github.com/iter8-tools/iter8/blob/master/action.yaml#L8

Describe the solution you'd like I think a solution would be to pass the version to install as an action input parameter. This parameter could continue to default to ${{ github.action_ref }}. But people that would like to pin the action can do so while also specifying a version to install. That's similar to how e.g. the helm-kind-action works: https://github.com/helm/kind-action/blob/main/action.yml#L11

Describe alternatives you've considered An even better solution would be automatically updating the action's default-version on every new release - although this might be challenging/annoying depending on the release process.

Additional context I'd be happy to create a PR for the first proposed solution or help discuss the work required for the second.

[kalantar]

The makes sense to me; I understand the need to pin to a specific SHA. Agree that your first solution would work and that the second would be better.

Would be happy to look at a PR for the first approach. And please do add what might be needed for the second.

[chgl]

Thank you for the feedback! I created a PR at https://github.com/iter8-tools/iter8/pull/1377. The second option is probably something that can build upon this - the only thing needed is a way to keep the default value for the version input up-to-date.

Some thoughts on that:

One option would be an auto-created commit every time a new release is created. Unfortunately, releases created by a github-action workflow can't trigger another workflow (see https://stackoverflow.com/a/69063453) so it would require setting a PAT. Actions like the chart-releaser-action seem to bump versions manually (e.g. https://github.com/helm/chart-releaser-action/commit/98bccfd32b0f76149d188912ac8e45ddd3f8695f). This could be automated using renovatebot (https://github.com/renovatebot/renovate) and its regexmanager (https://docs.renovatebot.com/modules/manager/regex/). In both cases, the downside is that the commit from which the release tag was created is not the same one that bumped the action version but the commit after that.

Personally, I quite like conventional commits so I'm a fan of https://github.com/googleapis/release-please. The created PR can update version tags in the same commit used to create a release. But switching to and enforcing conventional commits can be an annoyance in itself if not deemed necessary.

For my use case, its sufficient to be able to pin the action by digest and specify the release version manually. I will configure renovate on my end to keep the version parameter in-sync with the latest releases from this repository. So for me, option 2 isn't strictly necessary.

[sriumcp]

More re: the second solution ...

SHA pinning of Iter8 action seems like a good reason to have a separate repo for the Iter8 action altogether (we've gone back and forth on this). Then we can do the following in the workflow:

-uses: iter8-tools/iter8-action@<sha commit>

And within the action.yaml in the iter8-action repo, we can simply fix the Iter8 release that is getting used to install Iter8! Of course, the action.yaml would need to get updated after each Iter8 release as described in the 2nd solution. This is something we're already doing with the Homebrew releases of the Iter8 CLI today.

FYI @kalantar.