-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Introduce shellcheck to lint shell scripts #15169
base: master
Are you sure you want to change the base?
Introduce shellcheck to lint shell scripts #15169
Conversation
steps: | ||
- uses: actions/checkout@v4 | ||
- name: Run ShellCheck | ||
uses: ludeeus/action-shellcheck@master |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not super happy with running an arbitrarily changing action with an arbitrarily changing version of shellcheck.
Using the shellcheck executable that's available out of the box in GHA or Ubuntu would be slightly better. Or ideally this would be a precise version of a GitHub release of shellcheck, with its version managed by https://docs.renovatebot.com/modules/datasource/github-releases/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could be done in a follow-up, I suppose 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's a good point. I just picked this up as it's an easy solution.
However, we can at least pin the version of the action.
I'm happy to use any other mechanism.
We could also simply use grep -l -E '^#!(/usr/bin/env bash|/bin/sh|/bin/bash)' $(git ls-files)
to detect changed script files.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Integration with pre-commit would also be nice 🤷
@@ -0,0 +1,29 @@ | |||
on: | |||
push: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might be worth defining paths
here. Supposedly this check could then run very rarely, only when needed
https://docs.github.com/en/actions/writing-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I was wondering about that as well. A bit of an obstacle is that there's no simple glob to catch all shell script. Some like bin/crystal
have no extension. The GitHub action actually checks all files for a matching shebang.
Limiting paths would need to hard code all paths that don't identify as shell script by their extension. That means the check could miss out on new ones being added.
I suppose this is an acceptable limitation, though. I wouldn't expect too much movement in that regard.
On the other hand, this job finishes reallly quickly - especially compared to our other workflows - in just 7s so it's not too much overhead to run it on every commit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah it's a fair point. Not a good tradeoff then
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm actually not so sure. Either way seems quite fine. So maybe we can hear some other's comments on this.
It's also relevant to note that the discovery feature depends on the GitHub action and another comment is suggesting we might do without the action. Droping automatic path discovery would make that easier.
It will be nice to have this 🙂 |
This PR fixes a number of issues in several shell scripts that shellcheck complains about. It also introduces a new CI job to ensure shellcheck compliance in the future.
Issues fixed:
Issues ignored:
Follow-up to #15139