- Run a job after all the jobs in the dynamically built test matrix run
to completion. This job is useful for branch protection rules that
that need the whole test suite to run successfully.
- Fix linting issues.
Fix#5686
This directory contains test cases that super-linter uses to validate if a
particular linter is working.
These test cases focus on how super-linter invokes each linter and their exit
codes. We deliberately avoid to verify if the output of a given linter matches
the expectations because it's the responsibility of each linter to do so.
Test case format
Each super-linter language should have its own directory, named after the
language they refer to.
The name of each test case denotes its nature:
Test cases that are expected to pass validation contain the good string in
their filename, or path. Example: markdown_good_5.md
Test cases that are expected to fail validation contain the bad string in
their filename, or path. Example: markdown_bad_5.md
Notes about specific tests
In this section, we explain the peculiarities of certain test cases.
SQL Fluff test cases
From version 0.12.0 SQLFluff requires a dialect to be set, and no longer sets a
default. This can be provided as a command-line argument, or a .sqlfluff
config file (either in the usualy place for SQLFluff config files, or within the
folder containg the SQL).
For SQLFluff we have added a default .sqlfluff config file in its test
directory.
OpenAPI test cases
The _bad_ tests are valid .yml/.json but invalid OpenAPI specs.
The test extensions used are .ymlopenapi/.jsonopenapi instead of
.yml/.json. This is to prevent the YAML and JSON tests from picking them
up.
ARM test cases
apiVersions older than 2 years (730 days) are treated as errors by the ARM linter if there is a newer version available.
a86fbaf65e