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
feat: Lint actions #366
base: main
Are you sure you want to change the base?
feat: Lint actions #366
Conversation
For the moment we kept the old scheme and rules.
It allows existing rules to function as are (they potentially make preparation and post actions in Workflow* Job* functions).
">" stricts newlines with single spaces, but apparently this isn't picked by actionlint/shellcheck
Starting to port rule_id, rule_expression and rule_shellcheck to correctly handle action visits.
Use interface for the Runs block and a normal struct for the Action itself
Select syntax to check based on file name or top-level yaml keys.
Marking PR as ready to indicate further work depends on PR review. |
78e9286
to
0b49da7
Compare
What's the status on this? Will this eventually be merged or should I look for another tool to lint action files? I've tried @msw-kialo changes on my action files and it seems to work perfectly. I would like to use this in my actions workflow without having to clone and build their fork. |
I am ready to make needed adjustments, rebases, restructure the PR/change etc. |
This PR tries to address #46 to lint action metadata files (
action.yml
/action.yaml
) analog to workflow files. In addition to scheme validation this allows finding more sophisticated errors by running pyflake, shellcheck, validation expressions and other cross field references (e.g. outputs). The main advantage is obviously for people writing composite actions.Included changes
This PR tries to cover all essential aspects of this feature and provides example implementation for most of them:
parse*
methods to parse action metadata.Implementation decisions
We needed to take a few implementation decisions where it is not clear whether to picked the best option (once they are decided we will squash our changes and mark the PR as ready):
Parse
andVisit
were added). At the moment, the visitorspass
interface is extended byVisitActionPre
andVisitActionPost
, however it reusesvisitStep
. This could "crash" (nil value accessed) custom rules asVisitWorkflowPre
,VisitJobPre
might not be called beforevisitStep
: theRuleID
,RuleExpression
had this issue.action_metadata.go
) was left unchanged (it appears to be more light-weight and overall simpler to leave as small duplication).LintDir
will only lint arbitrary.yml
,.yaml
files if the directory is.github/workflows
. This should be an issue in practice (as workflows needs to be in such directory to be interpreted by GitHub), but it required thetestdata/projects
tests to be adapted (specify-input-format=workflow
would also work).actionlint
is invoked without extra arguments)action.yml
/action.yaml
file within the repository is considered an action metadata file (top level, or in any subdirectory at any level). While it ensures by default any such file is discovered, it might slow if it is a big repository and could cause false positives (the filename isn't that specific). Discovery could be reduced; but, new config option might be needed to handle more complex use-cases.-input-format=workflow
was added to the dog-food CI calls to ensure thetestdata
actions aren't discovered.actionlint $dir
to lint only files within the specific directory, e.g.actionlint .github/actions
(it was originally added for testing purposes but it might be helpful for others, too).inputs.X.default
,runs.envs.X
,runs.pre-if
,runs.post-if
are new. E.g. I suspect special functions likealways()
,success()
are supported forruns.pre-if
but I can't proof it.color
andicon
) are currently hardcoded. I suspect, a script to extracted them from GitHub's docs should be added?