Merge pull request #1 from github/master

Update github-issue-318 from upstream

.automation/upload-docker.sh

@@ -151,7 +151,7 @@ ValidateInput()
     # Need to see if GPR registry and update name #
     ###############################################
     if [[ "$REGISTRY" == "GPR" ]]; then
-      NAME="docker.pkg.github.com/$IMAGE_REPO"
+      NAME="docker.pkg.github.com/$IMAGE_REPO/super-linter"
       IMAGE_REPO="$NAME"
       echo "Updated [IMAGE_REPO] to:[$IMAGE_REPO] for GPR"
     fi

.github/workflows/stack-linter.yml

@@ -15,8 +15,8 @@
 #############################
 on:
   push:
-    branches-ignore:
+    branches: master
-      - 'master'
+  pull_request: []
 
 ###############
 # Set the Job #

Dockerfile

@@ -145,7 +145,7 @@ RUN wget "https://github.com/dotenv-linter/dotenv-linter/releases/latest/downloa
 #####################
 # Install clj-kondo #
 #####################
-ARG CLJ_KONDO_VERSION='2020.06.12'
+ARG CLJ_KONDO_VERSION='2020.06.21'
 RUN curl -sLO https://github.com/borkdude/clj-kondo/releases/download/v${CLJ_KONDO_VERSION}/clj-kondo-${CLJ_KONDO_VERSION}-linux-static-amd64.zip \
     && unzip clj-kondo-${CLJ_KONDO_VERSION}-linux-static-amd64.zip \
     && rm clj-kondo-${CLJ_KONDO_VERSION}-linux-static-amd64.zip \

README.md

@@ -125,7 +125,8 @@ jobs:
 ...
 ```
 
-**NOTE:** Using the line:`uses: docker://github/super-linter:v3` will pull the image down from **DockerHub** and run the **GitHub Super-Linter**. Using the line: `uses: github/super-linter@v3` will build and compile the **GitHub Super-Linter** at build time. This can be far more costly in time...
+**NOTE:**  
+Using the line:`uses: docker://github/super-linter:v3` will pull the image down from **DockerHub** and run the **GitHub Super-Linter**.   Using the line: `uses: github/super-linter@v3` will build and compile the **GitHub Super-Linter** at build time. *This can be far more costly in time...*
 
 ## Environment variables
 The super-linter allows you to pass the following `ENV` variables to be able to trigger different functionality.
@@ -204,7 +205,7 @@ The **Super-Linter** has *CI/CT/CD* configured utilizing **GitHub** Actions.
 ## Limitations
 Below are a list of the known limitations for the **GitHub Super-Linter**:
 - Due to being completely packaged at run time, you will not be able to update dependencies or change versions of the enclosed linters and binaries
-- Reading additional details from `package.json` are not read by the **GitHub Super-Linter**
+- Additional details from `package.json` are not read by the **GitHub Super-Linter**
 - Downloading additional codebases as dependencies from private repositories will fail due to lack of permissions
 
 ## How to contribute

docs/disabling-linters.md

@@ -1,6 +1,15 @@
 # Disabling linters and Rules
-If you find you need to ignore certain **errors** and **warnings**, you will need to know the *format* to disable the **Super-Linter** rules.  
+Linters can often require additional configuration to ensure they work with your codebase and your team's coding style, to avoid flagging false-positives. The **GitHub Super-Linter** has set up some default configurations for each linter which should work reasonably well with common code bases, but many of the linters can be configured to disable certain rules or configure the rules to ignore certain pieces of codes.
-Below are examples and documentation for each language and the various methods to disable.
+
+To run with your own configuration for a linter, copy the relevant [`TEMPLATE` configuration file for the linter you are using from this repo](https://github.com/github/super-linter/tree/master/TEMPLATES) into the `.github/linters` folder in your own repository, and then edit it to modify, disable - or even add - rules and configuration to suit how you want your code checked.
+
+How the changes are made differ for each linter, and also how much the **Github Super-Linter** has decided to change the linter's defaults. So, for some linters (e.g. [pylint for python](https://github.com/github/super-linter/blob/master/TEMPLATES/.python-lint)), there may be a large configuration file. For others (e.g. [stylelint for CSS](https://github.com/github/super-linter/blob/master/TEMPLATES/.stylelintrc.json)) the default configuration file may initially be nearly empty. And for some (e.g. StandardJS) it may not be possible to change configuration at all so there is no Template file.
+
+Where a configuration file exists in your repo, it will be used in preference to the default one in the **GitHub Super-Linter** `TEMPLATES` directory (not in addition to it), and where one doesn't exist the `TEMPLATES` version will be used. So you should copy the complete configuration file you require to change from the `TEMPLATES` directory and not just the lines of config you want to change.
+
+It is possible to have custom configurations for some linters, and continue to use the default from `TEMPLATES` directory for others, so if you use `Python` and `JavaScript` and only need to tweak the `Python` rules, then you only need to have a custom configuration for *pylint* and continue to use the default `TEMPLATE` from the main repo for *ESLint*, for example.
+
+For some linters it is also possible to override rules on a case by case level with directives in your code. Where this is possible we try to note how to do this in the specific linter sections below, but the official linter documentation will likely give more detail on this.
 
 ## Table of Linters
 - [Ruby](#ruby)

lib/linter.sh

@@ -491,7 +491,7 @@ DetectCloudFormationFile()
   ################################
   # See if it contains resources #
   ################################
-  if shyaml values-0 Resources | grep -q -E "Type: (AWS|Alexa|Custom)" < "$FILE"; then
+  if shyaml values-0 Resources 2> /dev/null | grep -q -E "Type: (AWS|Alexa|Custom)" < "$FILE"; then
     # Found it
     return 0
   fi