actions/superlint
1
0
Fork 0
mirror of https://github.com/super-linter/super-linter.git synced 2024-11-21 08:11:05 -05:00
Code Issues Projects Releases Packages Wiki Activity

chore: devcontainer, docs, prettier config (#6119)

Browse source 
- Update devcontainer by setting Prettier as a formatter only for
  supported languages.
- Install only the VS Code extensions that we need for Super-linter
  development.
- Remove the devcontainer as soon as it's not needed to avoid leaving
  leftovers behind.
- Enable proseWrap in Prettier configuration.
- Update documentation about how to configure new linters.
- Fix linting issues.
This commit is contained in:
Marco Ferrari 2024-09-13 14:37:48 +02:00 committed by GitHub
parent 72a4884f7a
commit 170cabf92b
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
14 changed files with 302 additions and 179 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

32
.devcontainer/devcontainer.json
View file

@ -1,32 +1,48 @@
{
"$schema": "https://raw.githubusercontent.com/devcontainers/spec/main/schemas/devContainer.schema.json",
"name": "Super-Linter",
"image": "ghcr.io/super-linter/super-linter:latest",
"customizations": {
"vscode": {
"settings": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,
"editor.formatOnSaveMode": "file",
"editor.wordWrap": "off",
"hadolint.cliOptions": [
"--config",
"/workspaces/super-linter/.github/linters/.hadolint.yaml"
],
"markdownlint.config": {
"extends": "${workspaceFolder}/.github/linters/.markdown-lint.yml"
},
"prettier.resolveGlobalModules": true,
"redhat.telemetry.enabled": false,
"telemetry.telemetryLevel": "off",
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[json]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[jsonc]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[markdown]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.wordWrap": "off"
},
"[shellscript]": {
"editor.defaultFormatter": "mkhl.shfmt"
},
"[terraform]": {
"editor.defaultFormatter": "hashicorp.terraform"
},
"[terraform-vars]": {
"editor.defaultFormatter": "hashicorp.terraform"
"[yaml]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
},
"extensions": [
"DavidAnson.vscode-markdownlint",
"EditorConfig.EditorConfig",
"HashiCorp.terraform",
"esbenp.prettier-vscode",
"exiasr.hadolint",
"GitHub.vscode-github-actions",
"GitHub.vscode-pull-request-github",
"mads-hartmann.bash-ide-vscode",
@ -89,5 +105,5 @@
"type": "bind"
}
],
"runArgs": ["--env-file", ".devcontainer/devcontainer.env"]
"runArgs": ["--env-file", ".devcontainer/devcontainer.env", "--rm"]
}

7
.github/CONTRIBUTING.md vendored
View file

@ -2,8 +2,8 @@
:wave: Hi there!
We're thrilled that you'd like to contribute to this project.
Your help is essential for keeping it great.
We're thrilled that you'd like to contribute to this project. Your help is
essential for keeping it great.
## Submitting a pull request
@ -16,7 +16,8 @@ request being accepted:
- Keep your change as focused as possible. If there are multiple changes you
would like to make that are not dependent upon each other, submit them as
separate pull requests.
- Write [descriptive commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
- Write
[descriptive commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html).
Draft pull requests are also welcome to get feedback early on, or if there is
something blocking you.

20
.github/pull_request-template.md vendored
View file

@ -17,14 +17,20 @@ In order to have this pull request merged, complete the following tasks.
- [ ] I included all the needed documentation for this change.
- [ ] I provided the necessary tests.
- [ ] I squashed all the commits into a single commit.
- [ ] I followed the [Conventional Commit v1.0.0 spec](https://www.conventionalcommits.org/en/v1.0.0/).
- [ ] I wrote the necessary upgrade instructions in the [upgrade guide](../docs/upgrade-guide.md).
- [ ] If this pull request is about and existing issue,
I added the `Fix #ISSUE_NUMBER` or `Close #ISSUE_NUMBER` text to the description of the pull request.
- [ ] I followed the
[Conventional Commit v1.0.0 spec](https://www.conventionalcommits.org/en/v1.0.0/).
- [ ] I wrote the necessary upgrade instructions in the
[upgrade guide](../docs/upgrade-guide.md).
- [ ] If this pull request is about and existing issue, I added the
`Fix #ISSUE_NUMBER` or `Close #ISSUE_NUMBER` text to the description of
the pull request.
### Super-linter maintainer tasks
- [ ] Label as `breaking` if this change breaks compatibility with the previous released version.
- [ ] Label as either: `automation`, `bug`, `documentation`, `enhancement`, `infrastructure`.
- [ ] Label as `breaking` if this change breaks compatibility with the previous
released version.
- [ ] Label as either: `automation`, `bug`, `documentation`, `enhancement`,
`infrastructure`.
- [ ] Add the pull request to a milestone, eventually creating one, that matches
with the version that release-please proposes in the `preview-release-notes` CI job.
with the version that release-please proposes in the
`preview-release-notes` CI job.

2
.github/workflows/ci.yml vendored
View file

@ -207,6 +207,7 @@ jobs:
FILTER_REGEX_EXCLUDE: ".*(/test/linters/|CHANGELOG.md).*"
RENOVATE_SHAREABLE_CONFIG_PRESET_FILE_NAMES: "default.json,hoge.json"
TYPESCRIPT_STANDARD_TSCONFIG_FILE: ".github/linters/tsconfig.json"
VALIDATE_JAVASCRIPT_STANDARD: false
- name: Get the contents of the log file
run: |
@ -221,6 +222,7 @@ jobs:
GITLEAKS_CONFIG_FILE: .gitleaks-ignore-tests.toml
FILTER_REGEX_EXCLUDE: ".*(/test/linters/|CHANGELOG.md).*"
TYPESCRIPT_STANDARD_TSCONFIG_FILE: ".github/linters/tsconfig.json"
VALIDATE_JAVASCRIPT_STANDARD: false
build-test-suite-matrix:
name: Build test suite matrix

27
CODE_OF_CONDUCT.md
View file

@ -5,9 +5,9 @@
In the interest of fostering an open and welcoming environment, we as
contributors and maintainers pledge to making participation in our project and
our community a harassment-free experience for everyone, regardless of age, body
size, disability, ethnicity, sex characteristics, gender identity and expression,
level of experience, education, socio-economic status, nationality, personal
appearance, race, religion, or sexual identity and orientation.
size, disability, ethnicity, sex characteristics, gender identity and
expression, level of experience, education, socio-economic status, nationality,
personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
@ -37,11 +37,11 @@ Project maintainers are responsible for clarifying the standards of acceptable
behavior and are expected to take appropriate and fair corrective action in
response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or
reject comments, commits, code, wiki edits, issues, and other contributions
that are not aligned to this Code of Conduct, or to ban temporarily or
permanently any contributor for other behaviors that they deem inappropriate,
threatening, offensive, or harmful.
Project maintainers have the right and responsibility to remove, edit, or reject
comments, commits, code, wiki edits, issues, and other contributions that are
not aligned to this Code of Conduct, or to ban temporarily or permanently any
contributor for other behaviors that they deem inappropriate, threatening,
offensive, or harmful.
## Scope
@ -58,8 +58,9 @@ Instances of abusive, harassing, or otherwise unacceptable behavior may be
reported by contacting the project team at <opensource@github.com>. All
complaints will be reviewed and investigated and will result in a response that
is deemed necessary and appropriate to the circumstances. The project team is
obligated to maintain confidentiality with regard to the reporter of an incident.
Further details of specific enforcement policies may be posted separately.
obligated to maintain confidentiality with regard to the reporter of an
incident. Further details of specific enforcement policies may be posted
separately.
Project maintainers who do not follow or enforce the Code of Conduct in good
faith may face temporary or permanent repercussions as determined by other
@ -67,11 +68,13 @@ members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4,
This Code of Conduct is adapted from the [Contributor Covenant][homepage],
version 1.4,
<!-- textlint-disable -->
available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct/)
available at
[https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct/)
<!-- textlint-enable -->

13
Makefile
View file

@ -242,6 +242,7 @@ test-git-flags: ## Run super-linter with different git-related flags
-e IGNORE_GENERATED_FILES=true \
-e IGNORE_GITIGNORED_FILES=true \
-e VALIDATE_ALL_CODEBASE=true \
-e VALIDATE_JAVASCRIPT_STANDARD=false \
-v "$(CURDIR)":/tmp/lint \
--rm \
$(SUPER_LINTER_TEST_CONTAINER_URL)
@ -260,6 +261,7 @@ lint-codebase: ## Lint the entire codebase
-e SAVE_SUPER_LINTER_OUTPUT=true \
-e SAVE_SUPER_LINTER_SUMMARY=true \
-e VALIDATE_ALL_CODEBASE=true \
-e VALIDATE_JAVASCRIPT_STANDARD=false \
-v "$(CURDIR):/tmp/lint" \
--rm \
$(SUPER_LINTER_TEST_CONTAINER_URL)
@ -288,6 +290,7 @@ fix-codebase: ## Fix and format the entire codebase
-e SAVE_SUPER_LINTER_OUTPUT=true \
-e SAVE_SUPER_LINTER_SUMMARY=true \
-e VALIDATE_ALL_CODEBASE=true \
-e VALIDATE_JAVASCRIPT_STANDARD=false \
-v "$(CURDIR):/tmp/lint" \
--rm \
$(SUPER_LINTER_TEST_CONTAINER_URL) \
@ -618,3 +621,13 @@ release-please-dry-run: build-dev-container-image check-github-token ## Run rele
--target-branch ${RELEASE_PLEASE_TARGET_BRANCH} \
--token "${GITHUB_TOKEN}" \
--trace
.PHONY: open-shell-dev-container
open-shell-dev-container: build-dev-container-image ## Open a shell in the dev tools container
docker run $(DOCKER_FLAGS) \
--interactive \
--entrypoint /bin/bash \
--rm \
-v "$(CURDIR)/dev-dependencies/package-lock.json":/package-lock.json \
-v "$(CURDIR)/dev-dependencies/package.json":/package.json \
$(DEV_CONTAINER_URL)

87
README.md
View file

@ -1,7 +1,7 @@
# Super-Linter
Super-linter is a ready-to-run collection of linters and code analyzers, to
help validate and fix your source code.
Super-linter is a ready-to-run collection of linters and code analyzers, to help
validate and fix your source code.
The goal of super-linter is to help you establish best practices and consistent
formatting across multiple programming languages, and ensure developers are
@ -10,9 +10,11 @@ adhering to those conventions.
Super-linter analyzes source code files using several tools, and reports the
issues that those tools find as console output, and as
[GitHub Actions status checks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks).
You can also [run super-linter outside GitHub Actions](#run-super-linter-outside-github-actions).
You can also
[run super-linter outside GitHub Actions](#run-super-linter-outside-github-actions).
Super-linter can also help you [fix linting and formatting issues](#fix-linting-and-formatting-issues).
Super-linter can also help you
[fix linting and formatting issues](#fix-linting-and-formatting-issues).
Super-linter is licensed under an
[MIT License](https://github.com/super-linter/super-linter/blob/main/LICENSE).
@ -29,9 +31,9 @@ Here are some notable Super-linter features:
[most widely used](https://github.com/super-linter/super-linter/network/dependents)
and [forked](https://github.com/super-linter/super-linter/forks) project of
this kind.
- **Runs linters in parallel**: Since `v6`, Super-linter parallelizes
running all the included linters, leading to scanning massive code
repositories in seconds.
- **Runs linters in parallel**: Since `v6`, Super-linter parallelizes running
all the included linters, leading to scanning massive code repositories in
seconds.
- **Highly curated set of linters**: Avoid including linters that implement
overlapping checks, reducing bloat, scanning times, and container image size.
- **Run on GitHub Actions or other environments**: Super-linter runs
@ -114,11 +116,14 @@ Super-linter supports the following tools:
## Get started
More in-depth [tutorial](https://www.youtube.com/watch?v=EDAmFKO4Zt0&t=118s) available
More in-depth [tutorial](https://www.youtube.com/watch?v=EDAmFKO4Zt0&t=118s)
available
To run super-linter as a GitHub Action, you do the following:
1. Create a new [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows/about-workflows#about-workflows) in your repository with the following content:
1. Create a new
[GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows/about-workflows#about-workflows)
in your repository with the following content:
```yaml
---
@ -182,8 +187,10 @@ For more information, see
Super-Linter provides several variants:
- `standard`: `super-linter/super-linter@[VERSION]`: includes all supported linters.
- `slim`: `super-linter/super-linter/slim@[VERSION]`: includes all supported linters except:
- `standard`: `super-linter/super-linter@[VERSION]`: includes all supported
linters.
- `slim`: `super-linter/super-linter/slim@[VERSION]`: includes all supported
linters except:
- Rustfmt
- Rust Clippy
@ -419,9 +426,13 @@ You can configure Super-linter using the following environment variables:
The `VALIDATE_[LANGUAGE]` variables work as follows:
- super-linter runs all supported linters by default.
- If you set any of the `VALIDATE_[LANGUAGE]` variables to `true`, super-linter defaults to leaving any unset variable to false (only validate those languages).
- If you set any of the `VALIDATE_[LANGUAGE]` variables to `false`, super-linter defaults to leaving any unset variable to true (only exclude those languages).
- If you set any of the `VALIDATE_[LANGUAGE]` variables to both `true` and `false`, super-linter fails reporting an error.
- If you set any of the `VALIDATE_[LANGUAGE]` variables to `true`, super-linter
defaults to leaving any unset variable to false (only validate those
languages).
- If you set any of the `VALIDATE_[LANGUAGE]` variables to `false`, super-linter
defaults to leaving any unset variable to true (only exclude those languages).
- If you set any of the `VALIDATE_[LANGUAGE]` variables to both `true` and
`false`, super-linter fails reporting an error.
For more information about reusing Super-linter configuration across
environments, see
@ -430,9 +441,9 @@ environments, see
## Fix linting and formatting issues
All the linters and formatters that Super-linter runs report errors if they
detect linting or formatting issues without modifying your source
code (_check only mode_). Check only mode is the default for all linters and
formatters that Super-linter runs.
detect linting or formatting issues without modifying your source code (_check
only mode_). Check only mode is the default for all linters and formatters that
Super-linter runs.
Certain linters and formatters support automatically fixing issues in your code
(_fix mode_). You can enable fix mode for a particular linter or formatter by
@ -467,8 +478,8 @@ configuration that doesn't ignore the `yaml` rule.
### Fix mode file and directory ownership
When fix mode is enabled, some linters and formatters don't maintain the
original file or directory ownership, and use the user that Super-linter uses
to run the linter or formatter.
original file or directory ownership, and use the user that Super-linter uses to
run the linter or formatter.
### Fix mode examples and workflows
@ -487,6 +498,7 @@ automatically fix linting and formatting issues, commit changes in the current
branch, and push commits to the remote branch tracking the current branch
whenever a pull request is created or updated:
<!-- prettier-ignore-start -->
```yaml
---
name: Lint
@ -538,6 +550,7 @@ jobs:
commit_user_name: super-linter
commit_user_email: super-linter@super-linter.dev
```
<!-- prettier-ignore-end -->
This example uses
[GitHub Actions automatic token authentication](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication)
@ -570,10 +583,11 @@ To work around these limitations, you do the following:
## Configure linters
Super-linter provides default configurations for some linters in the [`TEMPLATES/`](./TEMPLATES/)
directory. You can customize the configuration for the linters that support
this by placing your own configuration files in the `LINTER_RULES_PATH`
directory. `LINTER_RULES_PATH` is relative to the `DEFAULT_WORKSPACE` directory.
Super-linter provides default configurations for some linters in the
[`TEMPLATES/`](./TEMPLATES/) directory. You can customize the configuration for
the linters that support this by placing your own configuration files in the
`LINTER_RULES_PATH` directory. `LINTER_RULES_PATH` is relative to the
`DEFAULT_WORKSPACE` directory.
Super-linter supports customizing the name of these configuration files. For
more information, refer to [Configure super-linter](#configure-super-linter).
@ -601,15 +615,17 @@ For example:
- Lint only the `src` folder: `FILTER_REGEX_INCLUDE: .*src/.*`
- Do not lint files inside test folder: `FILTER_REGEX_EXCLUDE: .*test/.*`
- Do not lint JavaScript files inside test folder: `FILTER_REGEX_EXCLUDE: .*test/.*.js`
- Do not lint files named `gradlew` and JavaScript files inside a specific directory: `.*/gradlew|.*/specific/directory/*.js`
- Do not lint JavaScript files inside test folder:
`FILTER_REGEX_EXCLUDE: .*test/.*.js`
- Do not lint files named `gradlew` and JavaScript files inside a specific
directory: `.*/gradlew|.*/specific/directory/*.js`
<!-- This `README.md` has both markers in the text, so it is considered not generated. -->
Additionally, if you set `IGNORE_GENERATED_FILES` to `true`, super-linter
ignores any file with `@generated` string in it, unless the file
also has `@not-generated` marker. For example, super-linter considers a file
with the following contents as generated:
ignores any file with `@generated` string in it, unless the file also has
`@not-generated` marker. For example, super-linter considers a file with the
following contents as generated:
```bash
#!/bin/sh
@ -665,7 +681,8 @@ env:
If you need to inject a SSL certificate into the trust store, you can use the
`SSL_CERT_SECRET` variable. The value of that variable is expected to be the
path to the files that contains a CA that can be used to validate the certificate:
path to the files that contains a CA that can be used to validate the
certificate:
```yaml
env:
@ -674,15 +691,15 @@ env:
## Outputs
Super-linter supports generating several outputs, and also supports exposing
the output of individual linters.
Super-linter supports generating several outputs, and also supports exposing the
output of individual linters.
### Summary outputs
Super-linter writes a summary of all the checks:
- If `SAVE_SUPER_LINTER_SUMMARY` is set to `true`, Super-linter writes
a summary to
- If `SAVE_SUPER_LINTER_SUMMARY` is set to `true`, Super-linter writes a summary
to
`${DEFAULT_WORKSPACE}/${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/${SUPER_LINTER_SUMMARY_FILE_NAME}`.
- If `ENABLE_GITHUB_ACTIONS_STEP_SUMMARY` is set to `true`, Super-linter writes
a GitHub Actions job summary. Setting `ENABLE_GITHUB_ACTIONS_STEP_SUMMARY` to
@ -697,8 +714,8 @@ The summary output of previous Super-linter runs is not preserved.
### Super-linter outputs
If you set `SAVE_SUPER_LINTER_OUTPUT` to `true`, Super-linter saves its output
to `${DEFAULT_WORKSPACE}/${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/super-linter`, so you
can further process it, if needed.
to `${DEFAULT_WORKSPACE}/${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/super-linter`, so
you can further process it, if needed.
Most outputs are in JSON format.

10
TEMPLATES/README.md
View file

@ -1,6 +1,10 @@
# TEMPLATES
The files in this folder are template rules for the linters that will run against your codebase. If you choose to copy these to your local repository in the `.github/linters/` directory, they will be used at runtime. If rule files are not present locally, the templates will be used by default.
The files in this folder are template rules for the linters that will run
against your codebase. If you choose to copy these to your local repository in
the `.github/linters/` directory, they will be used at runtime. If rule files
are not present locally, the templates will be used by default.
The file(s) will be parsed at runtime on the local branch to load all rules needed to run the **Super-Linter** **GitHub** Action.
The **GitHub** Action will inform the user via the **Checks API** on the status and success of the process.
The file(s) will be parsed at runtime on the local branch to load all rules
needed to run the **Super-Linter** **GitHub** Action. The **GitHub** Action will
inform the user via the **Checks API** on the status and success of the process.

204
docs/add-new-linter.md
View file

@ -1,39 +1,50 @@
# How to add support for a new tool to super-linter
If you want to propose a _Pull Request_ to add **new** language support or a
new tool, it should include:
If you want to propose a _Pull Request_ to add **new** language support or a new
tool, do the following.
## Update documentation
- Update documentation:
- `README.md`
- Provide test cases:
## Provide test cases
1. Create the `test/linters/<LANGUAGE_NAME>` directory.
2. Provide at least one test case with a file that is supposed to pass validation,
with the right file extension if needed: `test/linters/<LANGUAGE_NAME>/<name-of-tool>-good`
3. Provide at least one test case with a file that is supposed to fail validation,
with the right file extension if needed: `test/linters/<LANGUAGE_NAME>/<name-of-tool>-bad`.
If the linter supports fix mode, the test case supposed to fail validation
should only contain violations that the fix mode can automatically fix.
Avoid test cases that fail only because of syntax errors, when possible.
2. Provide at least one test case with a file that is supposed to pass
validation, with the right file extension if needed:
`test/linters/<LANGUAGE_NAME>/<name-of-tool>-good`
3. Provide at least one test case with a file that is supposed to fail
validation, with the right file extension if needed:
`test/linters/<LANGUAGE_NAME>/<name-of-tool>-bad`. If the tool supports fix
mode, the test case supposed to fail validation should only contain
violations that the fix mode can automatically fix. Avoid test cases that
fail only because of syntax errors, when possible.
4. Update expected summary reports: `test/data/super-linter-summary`.
5. If the linter supports check-only mode or fix mode, add the `<LANGUGAGE>`
to the `LANGUAGES_WITH_FIX_MODE` array in `test/testUtils.sh`
5. If the tool supports check-only mode or fix mode, add the `<LANGUGAGE>` to
the `LANGUAGES_WITH_FIX_MODE` array in `test/testUtils.sh`
- Update the test suite to check for installed packages, the commands that your new tool needs in the `PATH`, and the expected version command:
## Update the test suite
Update the test suite to check for installed packages, the commands that your
new tool needs in the `PATH`, and the expected version command:
- `test/inspec/super-linter/controls/super_linter.rb`
## Install the tool
- Install the tool by pointing to specific package or container image versions:
- If there are PyPi packages, create a text file named `dependencies/python/<name-of-tool>.txt`
and list the packages there.
- If there are npm packages, update `dependencies/package.json` and `dependencies/package-lock.json`.
by adding the new packages.
- If there are Ruby Gems, update `dependencies/Gemfile` and `dependencies/Gemfile.lock`
- If there are PyPi packages, create a text file named
`dependencies/python/<name-of-tool>.txt` and list the packages there.
- If there are npm packages, update `dependencies/package.json` and
`dependencies/package-lock.json`. by adding the new packages.
- If there are Ruby Gems, update `dependencies/Gemfile` and
`dependencies/Gemfile.lock`
- If there are Maven or Java packages:
1. Create a directory named `dependencies/<name-of-tool>`.
2. Create a `dependencies/<name-of-tool>/build.gradle` file with the following contents:
2. Create a `dependencies/<name-of-tool>/build.gradle` file with the
following contents:
```gradle
repositories {
@ -50,8 +61,8 @@ new tool, it should include:
version '1.0.0-SNAPSHOT'
```
3. Update the `dependencies` section in `dependencies/<name-of-tool>/build.gradle` to
install your dependencies.
3. Update the `dependencies` section in
`dependencies/<name-of-tool>/build.gradle` to install your dependencies.
4. Add the following content to the `Dockerfile`:
```dockerfile
@ -59,8 +70,9 @@ new tool, it should include:
RUN --mount=type=secret,id=GITHUB_TOKEN /<name-of-tool>.sh && rm -rf /<name-of-tool>.sh
```
5. Create `scripts/install-<name-of-tool>.sh`, and implement the logic to install your tool.
You get the version of a dependency from `build.gradle`. Example:
5. Create `scripts/install-<name-of-tool>.sh`, and implement the logic to
install your tool. You get the version of a dependency from
`build.gradle`. Example:
```sh
GOOGLE_JAVA_FORMAT_VERSION="$(grep <"google-java-format/build.gradle" "google-java-format" | awk -F ':' '{print $3}' | tr -d "'")"
@ -84,89 +96,119 @@ new tool, it should include:
FROM your/image:version as <name-of-tool>
```
1. Copy the necessary binaries and libraries to the relevant locations. Example:
1. Copy the necessary binaries and libraries to the relevant locations.
Example:
```sh
COPY --from=<name-of-tool> /usr/local/bin/<name-of-command> /usr/bin/
```
- Configure the new tool:
- Provide a default configuration file only if the tool cannot function without one: `TEMPLATES/<template file for language>`
- Provide a configuration file for the new linter only if the default configuration is unsuitable for the super-linter repository: `.github/linters/.<lintrc>`
## Run the new tool
- Update the orchestration scripts to run the new tool:
- `lib/globals/languages.sh`: add a new item to `LANGUAGES_ARRAY` array. Use the
"name" of the language, then a `_`, and finally the name of the linter. Example: `PYTHON_RUFF`.
In the context of this document, to avoid repetitions we reference this new
item as `<LANGUAGE_NAME>`.
- `lib/globals/languages.sh`: add a new item to `LANGUAGES_ARRAY` array. Use
the "name" of the language, then a `_`, and finally the name of the tool. To
allow for future additions, use a language name and a tool name for the new
item. Example: `PYTHON_RUFF`. In the context of this document, to avoid
repetitions we reference this new item as `<LANGUAGE_NAME>`.
- Linter configuration:
- Define the command to invoke the new tool:
- Create a new minimal configuration file in the `TEMPLATES` directory with the same name as the
default configuration filename. Example: `TEMPLATES/.ruff.toml`.
- `lib/globals/linterRules.sh`:
- `lib/functions/linterCommands.sh`: add the command to invoke the tool.
Define a new variable: `LINTER_COMMANDS_ARRAY_<LANGUAGE_NAME>`. Example:
`LINTER_COMMANDS_ARRAY_GO_MODULES=(golangci-lint run --allow-parallel-runners)`
- If the new linter accepts a configuration files from the command line,
define a new variable:
`<LANGUAGE_NAME>_FILE_NAME="${<LANGUAGE_NAME>_CONFIG_FILE:-"default-config-file-name.conf"}"`
where `default-config-file-name.conf` is the name of the new,
minimal configuration for the linter. Example:
`PYTHON_RUFF_FILE_NAME="${PYTHON_RUFF_CONFIG_FILE:-.ruff.toml}"`.
- If there are arguments that you can only pass using the command line, and you think users
might want to customize them, define a new variable using
`<LANGUAGE_NAME>_COMMAND_ARGS` and add it to the command if the
- If there are arguments that you can only pass using the command line,
and you think users might want to customize them, define a new variable
using `<LANGUAGE_NAME>_COMMAND_ARGS` and add it to the command if the
configuration provides it. Example:
```bash
<LANGUAGE_NAME>_COMMAND_ARGS="${<LANGUAGE_NAME>_COMMAND_ARGS:-""}"
if [ -n "${<LANGUAGE_NAME>_COMMAND_ARGS:-}" ]; then
export <LANGUAGE_NAME>_COMMAND_ARGS
LINTER_COMMANDS_ARRAY_<LANGUAGE_NAME>+=("${<LANGUAGE_NAME>_COMMAND_ARGS}")
AddOptionsToCommand "LINTER_COMMANDS_ARRAY_<LANGUAGE_NAME>" "${<LANGUAGE_NAME>_COMMAND_ARGS}"
fi
```
- Define the command to invoke the new linter:
- `lib/functions/linterCommands.sh`: add the command to invoke the linter.
Define a new variable: `LINTER_COMMANDS_ARRAY_<LANGUAGE_NAME>`.
Example:
`LINTER_COMMANDS_ARRAY_GO_MODULES=(golangci-lint run --allow-parallel-runners -c "${GO_LINTER_RULES}")`
If the linter needs to load a configuration file, add the relevant options
and paths to the command you just defined. The path to the configuration
file is automatically initialized by Super-linter using in the
`<LANGUAGE_NAME>_LINTER_RULES` variable, as in the `GO_LINTER_RULES`
example above for the `GO` language.
- `lib/globals/linterCommandsOptions.sh`: add "check only mode" and "fix
linting and formatting issues mode" options if the linter supports it.
Super-linter will automatically add them to the command to run the linter.
linting and formatting issues mode" options if the tool supports it.
Super-linter will automatically add them to the command to run the tool.
- If the linter runs in "fix linting and formatting issues mode" by
default, define a new variable with the options to add to the linter
command to enable "check only mode":
`<LANGUAGE_NAME>_CHECK_ONLY_MODE_OPTIONS=(....)`.
Example: `PYTHON_BLACK_CHECK_ONLY_MODE_OPTIONS=(--diff --check)`
- If the tool runs in "fix linting and formatting issues mode" by default,
define a new variable with the options to add to the tool command to
enable "check only mode":
`<LANGUAGE_NAME>_CHECK_ONLY_MODE_OPTIONS=(....)`. Example:
`PYTHON_BLACK_CHECK_ONLY_MODE_OPTIONS=(--diff --check)`
- If the linter runs in "check only mode" by
default, define a new variable with the options to add to the linter
command to enable "fix linting and formatting issues mode":
`<LANGUAGE_NAME>_FIX_MODE_OPTIONS=(...)`.
- If the tool runs in "check only mode" by default, define a new variable
with the options to add to the tool command to enable "fix linting and
formatting issues mode": `<LANGUAGE_NAME>_FIX_MODE_OPTIONS=(...)`.
Example: `ANSIBLE_FIX_MODE_OPTIONS=(--fix)`
- Provide the logic to populate the list of files or directories to examine: `lib/functions/buildFileList.sh`
- Provide the logic to populate the versions file: `scripts/linterVersions.sh`
- If necessary, provide elaborate logic to detect if the tool should examine a file or a directory: `lib/functions/detectFiles.sh`
- If the tool needs to take into account special cases, reach out to the
maintainers by creating a draft pull request and ask relevant questions
there. For example, you might need to provide new logic or customize
the existing one to:
- If the tool needs option for both the "check only mode" and the fix
mode, define both variables as described in the previous points.
## Configure the new tool
If the new tool doesn't support a configuration file search mechanism, update
the command to run the new tool to set the path to the configuration file:
1. Define a new variable in `lib/globals/linterRules.sh`:
`<LANGUAGE_NAME>_FILE_NAME="${<LANGUAGE_NAME>_CONFIG_FILE:-"default-config-file-name.conf"}"`
where `default-config-file-name.conf` is the name of the new configuration
file for the new tool. Use one of the default recommended configurationfile
names for the new tool. Example:
`PYTHON_RUFF_FILE_NAME="${PYTHON_RUFF_CONFIG_FILE:-.ruff.toml}"`.
Super-linter automatically initializes the path to the configuration file in
the `<LANGUAGE_NAME>_LINTER_RULES` variable using the
`<LANGUAGE_NAME>_FILE_NAME`. Example: `PYTHON_RUFF_LINTER_RULES`
1. Create a new minimal configuration file in the `TEMPLATES` directory.
Example: `TEMPLATES/default-config-file-name.conf`.
1. Update `lib/functions/linterCommands.sh` to set the path to the configuration
file path. Example: `htmlhint --config "${HTML_LINTER_RULES}"`
### Configure the new tool for the Super-linter repository
If the default configuration of the new tool is unsuitable for the Super-linter
repository, create a new configuration file for the new tool using the default
filename:
- If the new tool supports a configuration file search mechanism, create the
configuration file in a location where the new tool will find it.
- If the new tool doesn't support a configuration file search mechanism and you
updated the new tool command to set the configuration file path, create the
configuration file in the `.github/linters` directory using its default
filename.
## Populate the file list
Provide the logic to populate the list of files or directories to examine:
`lib/functions/buildFileList.sh`
## Get the tool version
Provide the logic to populate the versions file: `scripts/linterVersions.sh`
## Detection logic
If necessary, provide elaborate logic to detect if the tool should examine a
file or a directory: `lib/functions/detectFiles.sh`
## Special cases
If the tool needs to take into account special cases, reach out to the
maintainers by creating a draft pull request and ask relevant questions there.
For example, you might need to provide new logic or customize the existing one
to:
- Validate the runtime environment: `lib/functions/validation.sh`.
- Get the installed version of the linter: `scripts/linterVersions.sh`
- Get the installed version of the tool: `scripts/linterVersions.sh`
- Load configuration files: `lib/functions/linterRules.sh`
- Run the linter: `lib/functions/worker.sh`
- Compose the linter command: `lib/functions/linterCommands.sh`
- Run the tool: `lib/functions/worker.sh`
- Compose the tool command: `lib/functions/linterCommands.sh`
- Modify the core Super-linter logic: `lib/linter.sh`

6
docs/release-process.md
View file

@ -6,9 +6,9 @@ The Process to create a super-linter release is as follows:
## Preview the release pull request
In order to have a preview of the next release before merging a pull
request that updates the configuration of the tooling that we use to create
releases, do the following:
In order to have a preview of the next release before merging a pull request
that updates the configuration of the tooling that we use to create releases, do
the following:
1. Run:

29
docs/run-linter-locally.md
View file

@ -5,7 +5,8 @@ runtime engine to run the super-linter container image.
## Run super-linter Locally
You can run the container locally with the following configuration options to run your code:
You can run the container locally with the following configuration options to
run your code:
```bash
docker run \
@ -16,16 +17,21 @@ docker run \
ghcr.io/super-linter/super-linter:latest
```
This example uses the `latest` container image version. If you're trying to reproduce
an issue, or running super-linter as part of your CI pipeline, we recommend that
you **refer to a specific version instead**.
This example uses the `latest` container image version. If you're trying to
reproduce an issue, or running super-linter as part of your CI pipeline, we
recommend that you **refer to a specific version instead**.
Notes:
- To run against a single file you can use: `docker run -e RUN_LOCAL=true -e USE_FIND_ALGORITHM=true -v /path/to/local/codebase/file:/tmp/lint/file ghcr.io/super-linter/super-linter`
- You need to pass the `RUN_LOCAL` option to bypass some of the GitHub Actions checks, as well as the mapping of your local codebase to `/tmp/lint`.
- If you want to override the `/tmp/lint` folder, you can set the `DEFAULT_WORKSPACE` environment variable to point to the folder you'd prefer to scan.
- You can add as many configuration options as needed. Configuration options are documented in the [readme](../README.md#configure-super-linter).
- To run against a single file you can use:
`docker run -e RUN_LOCAL=true -e USE_FIND_ALGORITHM=true -v /path/to/local/codebase/file:/tmp/lint/file ghcr.io/super-linter/super-linter`
- You need to pass the `RUN_LOCAL` option to bypass some of the GitHub Actions
checks, as well as the mapping of your local codebase to `/tmp/lint`.
- If you want to override the `/tmp/lint` folder, you can set the
`DEFAULT_WORKSPACE` environment variable to point to the folder you'd prefer
to scan.
- You can add as many configuration options as needed. Configuration options are
documented in the [readme](../README.md#configure-super-linter).
### GitLab
@ -48,7 +54,8 @@ Note that this is a high-level example that you should customize for your needs.
### Run on Codespaces and Visual Studio Code
This repository provides a DevContainer for [remote development](https://code.visualstudio.com/docs/remote/containers).
This repository provides a DevContainer for
[remote development](https://code.visualstudio.com/docs/remote/containers).
## Share Environment variables between environments
@ -122,8 +129,8 @@ make
You can run the test suite against an arbitrary super-linter container image.
Here is an example that runs the test suite against the `v5.4.3` container
image version.
Here is an example that runs the test suite against the `v5.4.3` container image
version.
```shell
CONTAINER_IMAGE_ID="ghcr.io/super-linter/super-linter:v5.4.3" \

18
docs/upgrade-guide.md
View file

@ -13,9 +13,9 @@ This section helps you upgrade from super-linter `v6` to `v7`.
### sql-lint, VALIDATE_SQL and SQL_CONFIG_FILE
[sql-lint](https://github.com/joereynolds/sql-lint) appears to be unmaintained,
and its dependencies are affected by known security vulnerabilities.
For this reason, Super-linter `v7` doesn't include sql-lint anymore. If you
are using sql-lint to check your SQL files, we recommend that you evaluate
and its dependencies are affected by known security vulnerabilities. For this
reason, Super-linter `v7` doesn't include sql-lint anymore. If you are using
sql-lint to check your SQL files, we recommend that you evaluate
[sqlfluff](https://sqlfluff.com/), included in Super-linter since `v4.6.0`.
You can remove the `VALIDATE_SQL` and `SQL_CONFIG_FILE` because they have no
@ -62,8 +62,8 @@ This section helps you upgrade from super-linter `v6.7.0` to `v6.8.0`.
- If you set `TYPESCRIPT_DEFAULT_STYLE=prettier`, set
`VALIDATE_TYPESCRIPT_STANDARD=false`
Finally, remove both `JAVASCRIPT_DEFAULT_STYLE` and
`TYPESCRIPT_DEFAULT_STYLE` from your Super-linter configuration.
Finally, remove both `JAVASCRIPT_DEFAULT_STYLE` and `TYPESCRIPT_DEFAULT_STYLE`
from your Super-linter configuration.
## Upgrade from v5 to v6
@ -120,8 +120,8 @@ This section helps you upgrade from super-linter `v5` to `v6`.
entire workspace instead of linting files one by one. You can safely remove
the `VALIDATE_JSCPD_ALL_CODEBASE` variable from your configuration.
- Jscpd doesn't consider the `FILTER_REGEX_EXCLUDE`, `FILTER_REGEX_INCLUDE`,
`IGNORE_GENERATED_FILES` variables. For more
information about how to ignore files with Jscpd, see
`IGNORE_GENERATED_FILES` variables. For more information about how to ignore
files with Jscpd, see
[the Jscpd documentation](https://github.com/kucherenko/jscpd/tree/master/apps/jscpd).
### USE_FIND_ALGORITHM and VALIDATE_ALL_CODEBASE used together
@ -137,6 +137,6 @@ This section helps you upgrade from super-linter `v5` to `v6`.
- The `VALIDATE_KOTLIN_ANDROID` variable has been deprecated because ktlint
handles linting Kotlin files for Android using a configuration option, so
super-linter doesn't need to account for this special case anymore. If you
set `VALIDATE_KOTLIN_ANDROID` in your configuration, change it to
super-linter doesn't need to account for this special case anymore. If you set
`VALIDATE_KOTLIN_ANDROID` in your configuration, change it to
`VALIDATE_KOTLIN` and configure ktlint to lint Android files.

11
prettier.config.js Normal file
View file

@ -0,0 +1,11 @@
module.exports = {
// Overrides for specific file types
overrides: [
{
files: ["**/*.md"],
options: {
proseWrap: "always",
},
},
],
};

1
test/run-super-linter-tests.sh
View file

@ -154,6 +154,7 @@ run_test_case_use_find_and_ignore_gitignored_files() {
ignore_test_cases
COMMAND_TO_RUN+=(-e IGNORE_GITIGNORED_FILES="true")
COMMAND_TO_RUN+=(-e USE_FIND_ALGORITHM="true")
COMMAND_TO_RUN+=(--env VALIDATE_JAVASCRIPT_STANDARD="false")
}
run_test_cases_save_super_linter_output() {