Feature Request: Support linting action metadata files about actionlint

[steve-viso]

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

[krisrecur]

+1. This would be very useful!

[ChrisCarini]

I'm very interested in seeing this feature added. I started working on it, then realized that @msw-kialo already had a completely functional PR of it: #366

I pulled this PR locally, and merged in the ~250 updates from rhysd/actionlint (there were a handful of fairly easy merge conflicts to deal with), and was able to successfully test the PR locally.

I'd encourage others to also test the change and provide feedback in the PR.

[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. 😹

[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.

[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

[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)
  • ???