# Creating GitHub Super-Linter Release

The Process to create a `Release` of the **GitHub/Super-Linter** is as follows:

- Every push to `master/main` triggers a build and deploy of the **GitHub/Super-linter**
- This creates the following images:
  - `github/super-linter:latest`
  - `github/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'`
- 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`
- The `versioning.yml` workflow is also triggered to update 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

## Pitfalls and Issues

If the *Admin* Does not update the `action.yml` to the new version before the Release is published, then the Release will point back to the old version, and any Images will also be sent back to the previous version.
This is very much a chicken and the egg issue, but seems to be easily resolved by following the correct path.