Validate Release YAML with Replicated's Linter

Packaging an application
1

Use Replicated’s linting tools enable you to script and automate validation of your YAML.

Overview

The Replicated Vendor UI will automatically validate your yaml as you write it in the release editor. Replicated ships this same validation functionality as a standalone NPM Package and CLI toolkit.

Usage

Install the CLI executable with

npm install -g replicated-lint

Lint with replicated-lint validate

replicated-lint validate -f my-app.yml

or pipe from stdin:

cat my-app.yml | replicated-lint validate -f -

Results that have issues will look something like:

{ type: 'info',
  rule: 'prop-configitem-testproc-run-on-save',
  message: 'If a config item\'s test_proc.run_on_save is not set to \'true\', test_proc\'s will not be checked automatically. Consider setting your test_proc\'s run_on_save to automatically validate inputs',
  positions:
   [ { path: 'config.1.items.2.test_proc',
       start: { position: 8130, line: 325, column: 4 },
       end: { position: 8322, line: 331, column: 0 } },
     { path: 'config.3.test_proc',
       start: { position: 8692, line: 346, column: 2 },
       end: { position: 9141, line: 365, column: 2 } } ],
  links: [ 'https://www.replicated.com/docs/packaging-an-application/test-procs/' ] }

# prop-configitem-testproc-run-on-save continued from line 321
322
323    - name: phone_number
324      type: text
325      test_proc:
326        display_name: Is this a Phone Number?
327        command: regex_match
328        args:
329        - "([0-9]{3})[-]([0-9]{3})[-]([0-9]{4})$"
330        - "That doesn't seem to be a phone number!"
331  - name: auth
332    title: Authentication
333    description: Where will user accounts be provisioned
334    items:

Extending the CLI with custom rules

replicated-lint rules can be expressed as JSON, so it is easy to add your own custom rules.

If you have a custom rule set in no-latest.json, you can pass it to replicated-lint using

cat my-app.yml | replicated-lint validate -f - --extraRules no-latest.json

--extraRules can be specified multiple times. An example JSON rule set might look something like

[
  {
    "name": "custom-no-latest",
    "type": "error",
    "message": "Dont use `latest` for container versions",
    "test": {
      "AnyOf": {
        "path": "components",
        "pred": {
          "AnyOf": {
            "path": "containers",
            "pred": {
              "Eq": {
                "path": "version",
                "value": "latest"
              }
            }
          }
        }
      }
    }
  }
]

replicated-lint validate supports the following options:

Options:
  --version         Show version number                                [boolean]
  --help            Show help                                          [boolean]
  --infile, -f      Input file to validate. Use "-" for stdin
                                                         [string] [default: "-"]
  --threshold, -t   Threshold of of issues to report
                  [string] [choices: "info", "warn", "error"] [default: "error"]
  --extraRules, -e  Path to file containing JSON definitions for additional yaml
                    rules. Can be specified multiple times.[array] [default: []]
  --reporter, -r    Output Format to use
                     [string] [choices: "console", "junit"] [default: "console"]
  --outputDir, -o   junit reporter only -- path to directory to output junit xml
                    reports                   [string] [default: "test-results"]

Integrating with CI

By default, replicated-lint validate will output results to the console, but it is also possible to output machine-readable results as JUnit XML. For example, to output results to a folder /ci/test-reports, you could use the following:

replicated-lint validate -f my-app.yml --reporter junit --outputDir /ci/test-reports

This will result in the creation of a file at

/ci/test-reports/replicated-lint-results.xml

For end-to-end examples of using replicated lint with Circle CI or Travis CI, check out the Automate Your Workflow guide.

2

Is it possible to include a switch allowing validation of multi-part YAML files such as used for releases? This currently results in :

user@host:~/replicated$ replicated release inspect 1|replicated-lint validate
{ type: 'error',
  rule: 'mesg-yaml-valid',
  message: 'expected a single document in the stream, but found more',
  positions: [] }


Found 1 issues.
3

The replicated-lint cli does not currently support multi-doc yaml as inputs.

If your # kind: replicated yaml is first in the YAML documents, you can use yq to extract the first document from the multidoc yaml.

For example, with yq installed, you could use something like the following:

replicated release inspect 1 | tail -n +5 | yq read - | replicated-lint validate -f -