Make Actionlint Directly Invokable as an Action Itself

[norwd]

Currently, there are two ways of running actionlint in a GitHub Action workflow:

1. Running the download script to install actionlint and execute it from a run: step:

   - name: Check workflow files
     shell: bash
     run: |
       bash <(curl https://raw.githubusercontent.com/rhysd/actionlint/main/scripts/download-actionlint.bash)
       ./actionlint -color

2. Running actionlint from a docker container

   - name: Check workflow files
     uses: docker://rhysd/actionlint:latest
     with:
       args: -color

Both of these two options have some drawbacks. Option 1 requires either always running the download script from the main branch (which may be unstable), or specifying a stable tag (which needs to be manually updated when new versions are released as Dependabot won't suggest updates). Option 2 has the benefit of being tied to a stable version, e.g. docker://rhysd/actionlint:v<TAG>, however, it can only be configured by passing in the args: property as a monolithic string, instead of separate inputs with clear defaults and descriptions.

One solution would be to add a action.yml file to the root that defines inputs: and executes actionlint internally. This could be done as a composite action (as was proposed in #257) or as a dockerized wrapper (which would forgo the need to run the download script). Essentially both of these would be wrapping up one or the other of the existing methods to run actionlint from a workflow. The key benefits here are clearly defined inputs and enabling Dependabot updates.

The possible downsides to adding an action.yml file, as pointed out by @rhysd in #257, is that this adds maintenance costs and is identical to just running one of the two existing methods.

Honestly I'm not seeing much difference between running the download script then executing the downloaded binary with run: and running the dedicated action with uses: though making a new action increases maintenance cost.

However, I believe that having a first party action would still add value. In addition to the aforementioned maintenance improvements to end users by enabling Dependabot and distinct inputs:, this would also add actionlint to the GitHub actions marketplace.

[Bertg]

I'm also 👍 for this

• It adds discoverability for the entire project itself
• I just like the feel of a package that could validate if it is used correctly :)

It just makes live easier. I've been using it locally for a while, and now want to introduce it to the dev workflow. I was looking for an action of this linter, and couldn't find it. Nor was there any documentation on how to do it. This ticket was the first usable result.

I believe the project should at least describe on how to use itself as a part of a GitHub workflow.

Alternatively, would the project reference an other repo that maintains just the action?

[jthegedus]

I believe the project should at least describe on how to use itself as a part of a GitHub workflow.

There is a whole section in the docs for this - https://github.com/rhysd/actionlint/blob/main/docs/usage.md#use-actionlint-on-github-actions

It is not directly in the README, but the README does link to USAGE under the DOCS section.

[norwd]

I believe the project should at least describe on how to use itself as a part of a GitHub workflow.

There is a whole section in the docs for this - https://github.com/rhysd/actionlint/blob/main/docs/usage.md#use-actionlint-on-github-actions

It is not directly in the README, but the README does link to USAGE under the DOCS section.

I believe there is still a discoverability issue, as I only found those docs after creating my fork and experimenting with a root action.yml file. More importantly, those docs are rather technical and assume that the reader knows a lot about how to roll their own GitHub actions, not just use workflows. If coupling the official action to the main repo is undesirable, perhaps a separate repo with just the action.yml file could be used as @Bertg suggested? This would allow for more simple and targeted documentation in a more accessible place (i.e. the README) and refer to the existing docs for advanced usage.

[kdeldycke]

Not only will it improve discoverability, but it will allow for pinning the version of both actionlint's action and actionlint binary. And at the same time letting dependabot keep track of upgrades and changelog.

[szepeviktor]

Some guys couldn't sit quietly at home and publish unofficial actionlint actions on GitHub Marketplace.
https://github.com/marketplace?type=&verification=&query=actionlint

[jbergstroem]

I chose to split out the version into a variable thats easily parseable by renovatebot:

https://github.com/jbergstroem/mariadb-alpine/blob/3b72c23dfd221e69c9c7cf4e65a9fa7c1da5c0af/.github/workflows/lint.yml#L36-L48

..then have renovatebot maintain it:

https://github.com/jbergstroem/mariadb-alpine/blob/3b72c23dfd221e69c9c7cf4e65a9fa7c1da5c0af/.github/renovate.json#L64-L72

[norwd]

I completely forgot about this thread, but if there is still interest, I've created a pull request that implements this. I've been running this fork for almost a year with no problems so it should be safe, again, assuming that there is still anyone else that prefers this method over just using the docker image.