Add GitHub Actions workflow linting using actionlint

[MonishPuttu]

Fixes: #1404

I looked into a few options for linting GitHub Actions workflows, including Super-Linter, zizmor, and actionlint.
Super-Linter felt too heavy for this use case, and zizmor focuses more on security analysis than workflow linting. Since the issue already suggested actionlint, and it is lightweight, actively maintained, and purpose-built for GitHub Actions, it seemed like the best one I could find.

I implemented a workflow that installs and runs actionlint, the workflow downloads the official binary directly instead of relying on additional wrapper actions.

I tested this locally by running actionlint against the existing workflows to ensure they pass, and also verified that it correctly detects errors using a deliberately broken workflow file.

I Hope that this satisfies the requirements of the issue by adding lightweight CI linting for GitHub Actions workflows while keeping the dependency surface small.

[gemini-code-assist]

Note

Gemini is unable to generate a review for this pull request due to the file types involved not being currently supported.

[victor-adebowale-momodu]

Hey @MonishPuttu! I’m also looking to contribute to Hermeto and have been diving into this issue. I would love to offer a few suggestions on your implementation to help make it more robust.

First, I want to mention the bash installation method.

I implemented a workflow that installs and runs actionlint, the workflow downloads the official binary directly instead of relying on additional wrapper actions.

While I understand the goal is to keep the setup lightweight, there are issues that can arise from this approach:

1. Because the script pulls the "latest" version, any breaking change or update to actionlint is executed immediately. This could cause the CI to fail unexpectedly even when no changes were made to our actual code.
2. Also, relying on a remote script is generally discouraged in CI/CD. It risks executing code whose effect you are not in control of.

I would suggest that you use the official wrapper and pin it to a specific version (or commit hash), so that any decision to upgrade or change is explicit.

[MonishPuttu]

@victor-adebowale-momodu, really appreciate the feedback

You’re right on both points. I originally went with the bash install approach to avoid introducing a third-party action wrapper, especially since the issue had concerns about abandonware and external dependencies. Piping a remote script into bash without pinning a version is definitely an anti-pattern, and I should have seen that.

I’ll switch this over to the official Docker image pinned to a specific version. That would keep things simple and avoids the remote script issue and makes version updates explicit.

I’ll push a fix shortly

[MonishPuttu]

I would suggest that you use the official wrapper and pin it to a specific version (or commit hash), so that any decision to upgrade or change is explicit.

I was waiting for the maintainer's pov before making any changes

I’ll switch this over to the official Docker image pinned to a specific version. That would keep things simple and avoids the remote script issue and makes version updates explicit.

For now I will go with this approach

[eskultety]

@MonishPuttu some of the PR description should go directly to the commit message as well for reasoning purposes. Also, do you have it deployed on your fork so that we can see it in action? :)
LGTM otherwise.

[eskultety]

Also, do you have it deployed on your fork so that we can see it in action?

Oh, nevermind, it ran from the PR :D, so yeah, it works.

[MonishPuttu]

Oh, nevermind, it ran from the PR :D, so yeah, it works.

Thank you, :D

[eskultety]

@MonishPuttu Well, since the previous CI run failed, you will also need to provide a fix to the failures before we can merge instead of just applying our review comments :) .

[MonishPuttu]

@eskultety actionlint was failing due to existing shellcheck issues in current workflows. should I update the workflow to ignore shellcheck for now so CI passes without expanding scope.
Happy to follow up separately to address those.

[eskultety]

@eskultety actionlint was failing due to existing shellcheck issues in current workflows. should I update the workflow to ignore shellcheck for now so CI passes without expanding scope. Happy to follow up separately to address those.

@MonishPuttu I think there might be some misunderstanding still, so I re-run the CI for you so you can see it. I know the problems are in existing workflows but we cannot merge a PR with a failing CI (that's a hard repo settings check).

[MonishPuttu]

@eskultety I misunderstood, thanks for clarifying. I will fix the shellcheck issues in the existing workflows so CI passes.

[MonishPuttu]

I think I have addressed the remaining shellcheck issues in workflows.

[eskultety]

@MonishPuttu normally you'd fix the issues in a dedicated commit that precedes the one adding the new functionality, but let's keep it as is this time, let's just merge. That said, the commit message doesn't have any mention of the existing workflow fixes you amended.

[MonishPuttu]

@eskultety Sorry about that, I missed updating the commit message earlier. I have updated it now to include the workflow fixes as well.