Bump github/super-linter from 7c7c4e9dead657c5f7ddf55eedc1667067fd2e87 to c26ca9fb2cce9f169fcb81077bb93017d7fe8fe5

[dependabot]

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

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

• c26ca9f Address linting issues
• 2cdffd7 Bump rubocop-github from 0.18.0 to 0.20.0 in /dependencies
• 6d7a7b4 Bump hashicorp/terraform from 1.3.6 to 1.3.7
• 42f676b Update Python dependencies
• fb52bf4 Fix JSON security flaw in npm
• 30b4d61 Update NPM dependencies
• 7af33d1 Update Python dependencies
• 9bcd243 Remove unneeded eslint configuration files
• b03920b Don't ignore dotfiles when running eslint
• aad87c5 add jenkinsfile to groovy files
• 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 #38.