Follow up with several more documentation and automation renames for …

…the org move from github to super-linter (super-linter#4543)

* move from github org to super-linter org

* rename to super-linter org

* rename to super-linter org

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter and remove dockerhub reference

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rename org to super-linter

* rm dockerhub section link

.automation/cleanup-docker.sh

@@ -63,7 +63,7 @@ ValidateInput() {
     # No repo was pulled
     error "Failed to get [IMAGE_REPO]!"
     fatal "[${IMAGE_REPO}]"
-  elif [[ ${IMAGE_REPO} == "github/super-linter" ]]; then
+  elif [[ ${IMAGE_REPO} == "super-linter/super-linter" ]]; then
     # Found our main repo
     info "Successfully found:[IMAGE_REPO], value:[${IMAGE_REPO}]"
   else

.automation/test/go.mod

@@ -1,4 +1,4 @@
-module github.com/github/super-linter
+module github.com/super-linter/super-linter
 
 go 1.17
 

.automation/validate-docker-labels.sh

@@ -13,7 +13,7 @@
 IMAGE="${1}"                                                                         # Image of the super-linter we build
 BUILD_REVISION="${GITHUB_SHA}"                                                       # GitHub Sha
 BUILD_VERSION="${GITHUB_SHA}"                                                        # Version of the container
-ORG_REPO="github/super-linter"                                                       # Org/repo
+ORG_REPO="super-linter/super-linter"                                                 # Org/repo
 REGISTRY='ghcr.io'                                                                   # Docker Registry
 ((LOG_TRACE = LOG_DEBUG = LOG_VERBOSE = LOG_NOTICE = LOG_WARN = LOG_ERROR = "true")) # Enable all loging
 ERROR=0                                                                              # Error count

.devcontainer/devcontainer.json

@@ -1,7 +1,7 @@
 {
   "name": "Super-Linter",
   "context": "..",
-  "image": "ghcr.io/github/super-linter:latest",
+  "image": "ghcr.io/super-linter/super-linter:latest",
   "extensions": [
     "github.vscode-pull-request-github",
     "rogalmic.bash-debug",

.github/CONTRIBUTING.md

@@ -62,6 +62,6 @@ If you are the current maintainer of this action you can create releases from th
 - [Using Pull Requests](https://docs.github.com/en/github/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests)
 - [GitHub Help](https://docs.github.com/en)
 
-[pulls]: https://github.com/github/super-linter/pulls
-[pr]: https://github.com/github/super-linter/compare
-[fork]: https://github.com/github/super-linter/fork
+[pulls]: https://github.com/super-linter/super-linter/pulls
+[pr]: https://github.com/super-linter/super-linter/compare
+[fork]: https://github.com/super-linter/super-linter/fork

.github/ISSUE_TEMPLATE/bug_report.md

@@ -31,7 +31,7 @@ docker run \
   -e MULTI_STATUS=false \
   -e VALIDATE_ALL_CODEBASE=true \
   -v $(pwd):/tmp/lint \
-  ghcr.io/github/super-linter:v3.13.5
+  ghcr.io/super-linter/super-linter:v3.13.5
 -->
 
 1. Go to '...'

.github/ISSUE_TEMPLATE/feature_request.md

@@ -20,4 +20,4 @@ A clear and concise description of any alternative solutions or features you've
 Add any other context or screenshots about the feature request here.
 
 **Note**
-If this is a request to add a new language, after submitting this issue check out [the wiki](https://github.com/github/super-linter/wiki/Adding-new-language-support) for more info on how to accomplish that.
+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) for more info on how to accomplish that.

.github/release-drafter.yml

@@ -5,7 +5,7 @@ template: |
   # Changelog
   $CHANGES
 
-  See details of [all code changes](https://github.com/github/super-linter/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION) since previous release
+  See details of [all code changes](https://github.com/super-linter/super-linter/compare/$PREVIOUS_TAG...v$RESOLVED_VERSION) since previous release
 
 categories:
   - title: '🚀 Features'
@@ -28,13 +28,13 @@ change-template: '- $TITLE @$AUTHOR (#$NUMBER)'
 version-resolver:
   major:
     labels:
-      - 'type: breaking'
+      - 'breaking'
   minor:
     labels:
-      - 'type: enhancement'
+      - 'enhancement'
   patch:
     labels:
-      - 'type: bug'
-      - 'type: maintenance'
-      - 'type: documentation'
+      - 'bug'
+      - 'maintenance'
+      - 'documentation'
   default: patch

.github/workflows/ci.yml

@@ -27,7 +27,7 @@ jobs:
           fetch-depth: 0
 
       - name: Update action.yml
-        run: yq '.runs.image = "docker://ghcr.io/github/super-linter:${{ matrix.images.target }}"' -i action.yml
+        run: yq '.runs.image = "docker://ghcr.io/super-linter/super-linter:${{ matrix.images.target }}"' -i action.yml
 
       - name: Retrieve Datetime
         run: echo "BUILD_DATE=$(date -u +'%Y-%m-%dT%H:%M:%SZ')" >> "${GITHUB_ENV}"
@@ -45,7 +45,7 @@ jobs:
           push: false
           secrets: |
             GITHUB_TOKEN=${{ secrets.GITHUB_TOKEN }}
-          tags: ghcr.io/github/super-linter:${{ matrix.images.target }}
+          tags: ghcr.io/super-linter/super-linter:${{ matrix.images.target }}
           target: "${{ matrix.images.target }}"
 
       - name: Test Local Action
@@ -77,7 +77,7 @@ jobs:
           -e ACTIONS_RUNNER_DEBUG=true \
           -e ERROR_ON_MISSING_EXEC_BIT=true \
           -v "${GITHUB_WORKSPACE}:/tmp/lint" \
-          "ghcr.io/github/super-linter:${tag}"
+          "ghcr.io/super-linter/super-linter:${tag}"
         env:
           tag: ${{ matrix.images.target }}
 
@@ -89,6 +89,6 @@ jobs:
           -e ACTIONS_RUNNER_DEBUG=true \
           -e ERROR_ON_MISSING_EXEC_BIT=true \
           -v "${GITHUB_WORKSPACE}:/tmp/lint" \
-          "ghcr.io/github/super-linter:${tag}"
+          "ghcr.io/super-linter/super-linter:${tag}"
         env:
           tag: ${{ matrix.images.target }}

Dockerfile

@@ -98,7 +98,7 @@ COPY dependencies/* /
 ###################################################################
 # Install Dependencies                                            #
 # The chown fixes broken uid/gid in ast-types-flow dependency     #
-# (see https://github.com/github/super-linter/issues/3901)        #
+# (see https://github.com/super-linter/super-linter/issues/3901)  #
 ###################################################################
 RUN npm install && chown -R "$(id -u)":"$(id -g)" node_modules && bundle install
 
@@ -281,9 +281,9 @@ LABEL com.github.actions.name="GitHub Super-Linter" \
     org.opencontainers.image.revision=$BUILD_REVISION \
     org.opencontainers.image.version=$BUILD_VERSION \
     org.opencontainers.image.authors="GitHub DevOps <[email protected]>" \
-    org.opencontainers.image.url="https://github.com/github/super-linter" \
-    org.opencontainers.image.source="https://github.com/github/super-linter" \
-    org.opencontainers.image.documentation="https://github.com/github/super-linter" \
+    org.opencontainers.image.url="https://github.com/super-linter/super-linter" \
+    org.opencontainers.image.source="https://github.com/super-linter/super-linter" \
+    org.opencontainers.image.documentation="https://github.com/super-linter/super-linter" \
     org.opencontainers.image.vendor="GitHub" \
     org.opencontainers.image.description="Lint your code base with GitHub Actions"
 

Makefile

@@ -75,16 +75,16 @@ SUPER_LINTER_TEST_CONTINER_URL := ''
 DOCKERFILE := ''
 IMAGE := ''
 ifeq ($(IMAGE),slim)
-	SUPER_LINTER_TEST_CONTINER_URL := "ghcr.io/github/super-linter:slim"
+	SUPER_LINTER_TEST_CONTINER_URL := "ghcr.io/super-linter/super-linter:slim"
 	IMAGE := "slim"
 else
-	SUPER_LINTER_TEST_CONTINER_URL := "ghcr.io/github/super-linter:standard"
+	SUPER_LINTER_TEST_CONTINER_URL := "ghcr.io/super-linter/super-linter:standard"
 	IMAGE := "standard"
 endif
 
 .PHONY: inspec
 inspec: inspec-check ## Run InSpec tests
-	LOCAL_IMAGE="$$(docker images $(SUPER_LINTER_TEST_CONTINER_URL) |grep 'ghcr.io/github/super-linter')"; \
+	LOCAL_IMAGE="$$(docker images $(SUPER_LINTER_TEST_CONTINER_URL) |grep 'ghcr.io/super-linter/super-linter')"; \
 	if [ "$$?" -ne 0 ]; then docker build -t $(SUPER_LINTER_TEST_CONTINER_URL) -f Dockerfile .; fi && \
 	DOCKER_CONTAINER_STATE="$$(docker inspect --format "{{.State.Running}}" "$(SUPER_LINTER_TEST_CONTAINER_NAME)" 2>/dev/null || echo "")"; \
 	if [ "$$DOCKER_CONTAINER_STATE" = "true" ]; then docker kill "$(SUPER_LINTER_TEST_CONTAINER_NAME)"; fi && \
@@ -112,4 +112,4 @@ docker:
 		--build-arg BUILD_REVISION=$(shell git rev-parse --short HEAD) \
 		--build-arg BUILD_VERSION=$(shell git rev-parse --short HEAD) \
 		--secret id=GITHUB_TOKEN,env=GITHUB_TOKEN \
-		-t ghcr.io/github/super-linter .
+		-t ghcr.io/super-linter/super-linter .

README.md

@@ -5,7 +5,7 @@
 This repository is for the **GitHub Action** to run a **Super-Linter**.
 It is a simple combination of various linters, written in `bash`, to help validate your source code.
 
-[![Codacy Badge](https://app.codacy.com/project/badge/Grade/51071879604e4f319859d4daf91c68f5)](https://app.codacy.com/gh/github/super-linter/dashboard?utm_source=github.com&utm_medium=referral&utm_content=github/super-linter&utm_campaign=Badge_Grade)
+[![Codacy Badge](https://app.codacy.com/project/badge/Grade/51071879604e4f319859d4daf91c68f5)](https://app.codacy.com/gh/super-linter/super-linter/dashboard?utm_source=github.com&utm_medium=referral&utm_content=super-linter/super-linter&utm_campaign=Badge_Grade)
 
 **The end goal of this tool:**
 
@@ -32,7 +32,6 @@ It is a simple combination of various linters, written in `bash`, to help valida
     - [Disabling rules](#disabling-rules)
     - [Using your own SSH key](#using-your-own-ssh-key)
   - [Filter linted files](#filter-linted-files)
-  - [Docker Hub](#docker-hub)
   - [Run Super-Linter outside GitHub Actions](#run-super-linter-outside-github-actions)
     - [Local (troubleshooting/debugging/enhancements)](#local-troubleshootingdebuggingenhancements)
     - [Azure](#azure)
@@ -525,10 +524,6 @@ And this file is considered not generated:
 echo "@generated" # @not-generated
 ```
 
-## Docker Hub
-
-The **Docker** container that is built from this repository is located at [github/super-linter](https://hub.docker.com/r/github/super-linter)
-
 ## Run Super-Linter outside GitHub Actions
 
 ### Local (troubleshooting/debugging/enhancements)

TEMPLATES/linter.yml

@@ -57,7 +57,7 @@ jobs:
       # Run Linter against code base #
       ################################
       - name: Lint Code Base
-        uses: github/super-linter@v5
+        uses: super-linter/super-linter@v5
         env:
           VALIDATE_ALL_CODEBASE: false
           # Change to 'master' if your main branch differs

action.yml

@@ -8,5 +8,5 @@ runs:
 branding:
   icon: 'check-square'
   color: 'white'
-# You can view https://github.com/github/super-linter#environment-variables
+# You can view https://github.com/super-linter/super-linter#environment-variables
 # to see a comprehensive list of all environment variables that can be passed

docs/disabling-linters.md

@@ -2,14 +2,14 @@
 
 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.
 
-To run with your own configuration for a linter, copy the relevant [`TEMPLATE` configuration file for the linter you are using from this repository](https://github.com/github/super-linter/tree/main/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.
+To run with your own configuration for a linter, copy the relevant [`TEMPLATE` configuration file for the linter you are using from this repository](https://github.com/super-linter/super-linter/tree/main/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/main/TEMPLATES/.python-lint)), there may be a large configuration file. For others (e.g. [stylelint for CSS](https://github.com/github/super-linter/blob/main/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.
+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/super-linter/super-linter/blob/main/TEMPLATES/.python-lint)), there may be a large configuration file. For others (e.g. [stylelint for CSS](https://github.com/super-linter/super-linter/blob/main/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 repository, 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 repository 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.
 
-**NOTE: Please view each linters source and web page from the [Supported Linters README](https://github.com/github/super-linter#supported-linters) to see additional information on how to configure, disable, or tune additional rules.**
+**NOTE: Please view each linters source and web page from the [Supported Linters README](https://github.com/super-linter/super-linter#supported-linters) to see additional information on how to configure, disable, or tune additional rules.**

docs/release-process.md

@@ -1,28 +1,28 @@
 # Creating GitHub Super-Linter Release
 
-The Process to create a `Release` of the **GitHub/Super-Linter** is as follows:
+The Process to create a `Release` of the **super-linter/super-linter** is as follows:
 
-- Every push to `master/main` triggers a build and deploy of the **GitHub/Super-linter**
+- Every push to `master/main` triggers a build and deploy of the **super-linter/super-linter**
 - This creates the following images:
-  - `github/super-linter:latest`
-  - `github/super-linter:slim-latest`
+  - `super-linter/super-linter:latest`
+  - `super-linter/super-linter:slim-latest`
 - This also causes the `Release drafter` action to update a new draft Release
 
 When an *Admin* wants to create a Release, the process is as follows:
 
 - The *Admin* pushes an update to `master/main` and updates the `action.yml` to point to the next **Release** version
-  - Example: `image: 'docker://ghcr.io/github/super-linter:v4.6.2'` becomes: `image: 'docker://ghcr.io/github/super-linter:v4.6.3'`
+  - Example: `image: 'docker://ghcr.io/super-linter/super-linter:v4.6.2'` becomes: `image: 'docker://ghcr.io/super-linter/super-linter:v4.6.3'`
 - Then the *admin* can go to the Release page and update the current `draft Release`
 - The *Admin* will set the correct version strings, and update any additional information in the current `draft Release`
 - Once the *Admin* is ready, they will select **Publish Release**
 - This triggers the **GitHub Actions** to take the current codebase, and build the containers, and deploy to their locations
 - This creates and pushes the following container images:
-  - `github/super-linter:latest`
-  - `github/super-linter:v4`
-  - `github/super-linter:v4.6.3`
-  - `github/super-linter:slim-latest`
-  - `github/super-linter:slim-v4`
-  - `github/super-linter:slim-v4.6.3`
+  - `super-linter/super-linter:latest`
+  - `super-linter/super-linter:v4`
+  - `super-linter/super-linter:v4.6.3`
+  - `super-linter/super-linter:slim-latest`
+  - `super-linter/super-linter:slim-v4`
+  - `super-linter/super-linter:slim-v4.6.3`
 - This also updates the `latest` and `vMAJOR` Git tags to point to the same commit that the release Git tag is pointing at.
 - At this point, the Release is complete and images are available for general consumption
 

docs/run-linter-locally.md

@@ -17,14 +17,14 @@ You can follow the link below on how to install and configure **Docker** on your
 ## Download the latest Super-Linter Docker container
 
 - Pull the latest **Docker** container down from **DockerHub**
-  - `docker pull github/super-linter:latest`
+  - `docker pull super-linter/super-linter:latest`
     Once the container has been downloaded to your local environment, you can then begin the process, or running the container against your codebase.
 
 ## Run the container Locally
 
 - You can run the container locally with the following **Base** flags to run your code:
-  - `docker run -e RUN_LOCAL=true -e USE_FIND_ALGORITHM=true -v /path/to/local/codebase:/tmp/lint github/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 github/super-linter`
+  - `docker run -e RUN_LOCAL=true -e USE_FIND_ALGORITHM=true -v /path/to/local/codebase:/tmp/lint super-linter/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 super-linter/super-linter`
   - **NOTE:** You need to pass the `RUN_LOCAL` flag to bypass some of the GitHub Actions checks, as well as the mapping of your local codebase to `/tmp/lint` so that the linter can pick up the code
   - **NOTE:** 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.
   - **NOTE:** The flag:`RUN_LOCAL` will set: `VALIDATE_ALL_CODEBASE` to true. This means it will scan **all** the files in the directory you have mapped. If you want to only validate a subset of your codebase, map a folder with only the files you wish to have linted
@@ -57,7 +57,7 @@ This always runs the local docker based linting.
 docker run --rm \
     -e RUN_LOCAL=true \
     --env-file ".github/super-linter.env" \
-    -v "$PWD":/tmp/lint github/super-linter:v5
+    -v "$PWD":/tmp/lint super-linter/super-linter:v5
 ```
 
 ### scripts/test
@@ -91,7 +91,7 @@ jobs:
       - uses: actions/checkout@v3
       - run: cat .github/super-linter.env >> "$GITHUB_ENV"
       - name: Lint Code Base
-        uses: github/super-linter@v5
+        uses: super-linter/super-linter@v5
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           DEFAULT_BRANCH: develop
@@ -103,9 +103,9 @@ jobs:
 
 If you need to run the container locally and gain access to its command-line, you can run the following command:
 
-- `docker run -it --entrypoint /bin/bash github/super-linter`
+- `docker run -it --entrypoint /bin/bash super-linter/super-linter`
 - This will drop you in the command-line of the docker container for any testing or troubleshooting that may be needed.
 
 ### Found issues
 
-If you find a _bug_ or _issue_, please open a **GitHub** issue at: [github/super-linter/issues](https://github.com/github/super-linter/issues)
+If you find a _bug_ or _issue_, please open a **GitHub** issue at: [super-linter/super-linter/issues](https://github.com/super-linter/super-linter/issues)

lib/functions/buildFileList.sh

@@ -12,7 +12,7 @@
 #### Function BuildFileList ####################################################
 function IssueHintForFullGitHistory() {
   info "Check that you have the full git history, the checkout is not shallow, etc"
-  info "See https://github.com/github/super-linter#example-connecting-github-action-workflow"
+  info "See https://github.com/super-linter/super-linter#example-connecting-github-action-workflow"
 }
 
 ################################################################################