Move instructions from the wiki to docs (#4957)

* Move instructions from the wiki to docs

* Add missing code

* Fix linting errors

* Fix indentation

* Don't add deleted docs back

* Remove slim readme

.github/ISSUE_TEMPLATE/feature_request.yml

@@ -9,7 +9,7 @@ body:
       value: |
         Thanks for taking the time to fill out this feature request!
         If this is a request to add a new language, after submitting this issue
-        check out [the wiki](https://github.com/super-linter/super-linter/wiki/Adding-new-language-support-to-Super-Linter)
+        check out [the instructions](https://github.com/super-linter/super-linter/blob/main/docs/add-new-linter.md)
         for more information on how to accomplish that.
   - type: checkboxes
     attributes:

.github/linters/.sqlfluff

@@ -1,8 +1,8 @@
 ## This /.sqlfluff file can be used to configure the SQLFluff linter when
-## used via the GitHub Super Linter. Copy it to the .github/linters folder of
+## used via the Super Linter. Copy it to the .github/linters folder of
 ## your repo, and uncomment the necessary lines to configure the Super Linter.
 ##
-## IMPORTANT NOTE: The GitHub Super Linter configuration file for SQLFluff
+## IMPORTANT NOTE: The Super Linter configuration file for SQLFluff
 ## supersedes any local configuration files you might have in within your
 ## codebase. For this reason it should only be used when you want the same
 ## configuration for your entire code base. If you need different configuration

TEMPLATES/.sqlfluff

@@ -1,8 +1,8 @@
 ## This /.sqlfluff file can be used to configure the SQLFluff linter when
-## used via the GitHub Super Linter. Copy it to the .github/linters folder of
+## used via the Super Linter. Copy it to the .github/linters folder of
 ## your repo, and uncomment the necessary lines to configure the Super Linter.
 ##
-## IMPORTANT NOTE: The GitHub Super Linter configuration file for SQLFluff
+## IMPORTANT NOTE: The Super Linter configuration file for SQLFluff
 ## supersedes any local configuration files you might have in within your
 ## codebase. For this reason it should only be used when you want the same
 ## configuration for your entire code base. If you need different configuration

TEMPLATES/phpcs.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8" ?>
 
 <ruleset name="super-linter">
-    <description>The default coding standard for usage with GitHub Super-Linter. It just includes PSR12.</description>
+    <description>The default coding standard for usage with Super-Linter. It just includes PSR12.</description>
     <rule ref="PSR12" />
 </ruleset>

docs/add-new-linter.md

@@ -0,0 +1,100 @@
+# 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:
+
+- Update documentation:
+  - `README.md`
+- Provide test cases:
+
+  1. Create the `.automation/test/<LANGUGAGE>` directory.
+  2. Provide at least one test case with a file that is supposed to pass validation: `.automation/test/<LANGUAGE>/<name-of-tool>-good.ext`
+  3. Provide at least one test case with a file that is supposed to fail validation: `.automation/test/<LANGUAGE>/<name-of-tool>-bad.ext`
+
+- 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 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 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:
+
+        ```gradle
+        repositories {
+          mavenLocal()
+          mavenCentral()
+        }
+
+        // Hold this dependency here so we can get automated updates using DependaBot
+        dependencies {
+          implementation 'your:dependency-here:version'
+        }
+
+        group 'com.github.super-linter'
+        version '1.0.0-SNAPSHOT'
+        ```
+
+    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
+        COPY scripts/install-<name-of-tool>.sh /
+        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:
+
+        ```sh
+        GOOGLE_JAVA_FORMAT_VERSION="$(grep <"google-java-format/build.gradle" "google-java-format" | awk -F ':' '{print $3}' | tr -d "'")"
+        ```
+
+    6. Add the new to DependaBot configuration:
+
+        ```yaml
+          - package-ecosystem: "gradle"
+            directory: "/dependencies/<name-of-tool>"
+            schedule:
+              interval: "weekly"
+            open-pull-requests-limit: 10
+        ```
+
+  - If there is a container (Docker) image:
+
+    1. Add a new build stage to get the image:
+
+        ```dockerfile
+        FROM your/image:version as <name-of-tool>
+        ```
+
+    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>`
+
+- Update the orchestration scripts to run the new tool:
+
+  - `lib/linter.sh`
+  - Provide the logic to populate the list of files or directories to examine: `lib/buildFileList.sh`
+  - If necessary, provide elaborate logic to detect if the tool should examine a file or a directory: `lib/detectFiles.sh`
+  - If the tool needs to take into account special cases:
+
+    - Provide new runtime validation checks in `lib/validation.sh`.
+    - Customize the logic to get the installed version of the tool: `lib/linterVersions.sh`
+    - Provide custom logic to load configuration files: `lib/linterRules.sh`
+    - Provide custom logic for test cases and to run the tool: `lib/worker.sh`

docs/release-process.md

@@ -1,4 +1,4 @@
-# Creating GitHub Super-Linter Release
+# Creating Super-Linter Release
 
 The Process to create a `Release` of the **super-linter/super-linter** is as follows:
 

slim/README.md

@@ -1,34 +0,0 @@
-# GitHub Super-Linter Slim Image Action
-
-The **GitHub Super-Linter** maintains `two` major images:
-
-- `super-linter/super-linter:v5`
-- `super-linter/super-linter:slim-v5`
-
-In order to help users pull this image more naturally, the `action.yml` in this directory can help users pull the `slim image`.
-
-## Slim Image
-
-The slim `super-linter/super-linter:slim-v5` comes with all supported linters but removes the following:
-
-- `rust` linters
-- `dotenv` linters
-- `armttk` linters
-- `pwsh` linters
-- `c#` linters
-
-By removing these linters, we were able to bring the image size down by `2gb` and drastically speed up the build and download time.
-The behavior will be the same for non-supported languages, and will skip languages at runtime.
-Example usage:
-
-```yml
-################################
-# Run Linter against code base #
-################################
-- name: Lint Code Base
-  uses: super-linter/super-linter/slim@v5
-  env:
-    VALIDATE_ALL_CODEBASE: false
-    DEFAULT_BRANCH: main
-    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-```