Bump github/super-linter from 7c7c4e9dead657c5f7ddf55eedc1667067fd2e87 to aad87c569b8a3de467bf6504c06127822e2845aa

[dependabot]

Bumps github/super-linter from 7c7c4e9dead657c5f7ddf55eedc1667067fd2e87 to aad87c569b8a3de467bf6504c06127822e2845aa.

Changelog

Sourced from github/super-linter's changelog.

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
• 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

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.

Commits

• aad87c5 add jenkinsfile to groovy files
• e69db3d Fix main branch concurrency group
• de0d0f7 Add missing secrets
• e5cf70e Address review comments
• 06de195 Fix Dockerfile conflict
• fe9b1b8 Fix concurrency group name
• 994e7ba Add concurrency group to CI to reduce duplication
• bc174e3 Use concurrency group for CD to limit wasteful runs
• b7edcbf Fix step name
• fd22cff Update workflow name
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Superseded by #36.