Feature Request: Support linting action metadata files

[mike-stewart]

It would be great to have support for linting action files as well as workflow files.

Especially with the recent release of composite actions, it seems that building private actions will be a common way to DRY up workflow files. Currently there is a gap in linting, because the workflow files are covered but anything moved to an action is not.

[rhysd]

References:

• Changelog: https://github.blog/changelog/2021-08-25-github-actions-reduce-duplication-with-action-composition/
• Document: https://docs.github.com/en/actions/creating-actions/creating-a-composite-action

[steve-viso]

Hey, I was wondering if there is any plans to implement this?

[krisrecur]

+1. This would be very useful!

[andyfeller]

@rhysd : truly appreciate your good work here! ✨ 🙇

if someone was interested in contributing support for this feature, what would be some considerations for adding this that someone unfamiliar with the project might review?

1. Would actionlint be invoked with an arbitrary path containing composite action(s) and workflows, not simply .github/workflows/?

   From /command.go, it seems this would need some minor rework as I'd would like to pass one or more directories on the command line to workflows and/or composite actions:

   func (cmd *Command) runLinter(args []string, opts *LinterOptions, initConfig bool) ([]*Error, error) {
      l, err := NewLinter(cmd.Stdout, opts)
      if err != nil {
    	  return nil, err
      }
   
      if initConfig {
    	  return nil, l.GenerateDefaultConfig(".")
      }
   
      if len(args) == 0 {
    	  return l.LintRepository(".")
      }
   
      if len(args) == 1 && args[0] == "-" {
    	  b, err := io.ReadAll(cmd.Stdin)
    	  if err != nil {
    		  return nil, fmt.Errorf("could not read stdin: %w", err)
    	  }
    	  n := "<stdin>"
    	  if opts.StdinFileName != "" {
    		  n = opts.StdinFileName
    	  }
    	  return l.Lint(n, b, nil)
      }
   
      return l.LintFiles(args, nil)
   }

2. How difficult is it to account for a similar but different schema for composite actions versus a workflow file?

   It seems parser.go is very specifically for workflow parsing. Some of this would be useful for parsing and validating composite files, however I don't know how you might want to restructure the detection of files to be parsed to use the right parser.

Thank you for discussing what this might entail as I genuinely want to see if we can help explain to someone who might be willing and capable of doing the work. 😹

[SimonHeimberg]

Some ideas:

• distinguish between workflow and action:
  • workflow has top level keys jobs and on
  • action has top level key runs
• find action files:
  • maybe those referenced in the workflow files
  • maybe **/action.yaml (to find public actions)
  • maybe .github/action*/*.yaml
• what to check:
  • runs.using is composite or a node version (nodeXX) or docker
  • runs.steps of composite actions like steps of a job (p.parseSteps()) (but shell is required if run is set)
  • ??? for docker actions
  • ??? for JavaScript actions
  • inputs (probably similar to inputs in "on")
  • outputs (for composite actions probably like output of jobs)
  • description exists (is mandatory)
  • ???

[karlbrown-va]

one thing that might help is this: https://check-jsonschema.readthedocs.io/en/stable/usage.html

pre-commit example:

  - repo: https://github.com/python-jsonschema/check-jsonschema
    rev: 315c23f8562a5bafa15ab448ff542abe02d9e439  # frozen: 0.28.2
    hooks:
      - id: check-github-actions

Note however that this will not lint the inside of scripts, it will just confirm that your action.yaml schema is correct.