diff --git a/.devcontainer/devcontainer.json b/.devcontainer/devcontainer.json index 1cf16457..2ed06c64 100644 --- a/.devcontainer/devcontainer.json +++ b/.devcontainer/devcontainer.json @@ -1,32 +1,48 @@ { + "$schema": "https://raw.githubusercontent.com/devcontainers/spec/main/schemas/devContainer.schema.json", "name": "Super-Linter", "image": "ghcr.io/super-linter/super-linter:latest", "customizations": { "vscode": { "settings": { - "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.formatOnSave": true, "editor.formatOnSaveMode": "file", "editor.wordWrap": "off", + "hadolint.cliOptions": [ + "--config", + "/workspaces/super-linter/.github/linters/.hadolint.yaml" + ], + "markdownlint.config": { + "extends": "${workspaceFolder}/.github/linters/.markdown-lint.yml" + }, "prettier.resolveGlobalModules": true, + "redhat.telemetry.enabled": false, + "telemetry.telemetryLevel": "off", + "[javascript]": { + "editor.defaultFormatter": "esbenp.prettier-vscode" + }, + "[json]": { + "editor.defaultFormatter": "esbenp.prettier-vscode" + }, + "[jsonc]": { + "editor.defaultFormatter": "esbenp.prettier-vscode" + }, "[markdown]": { + "editor.defaultFormatter": "esbenp.prettier-vscode", "editor.wordWrap": "off" }, "[shellscript]": { "editor.defaultFormatter": "mkhl.shfmt" }, - "[terraform]": { - "editor.defaultFormatter": "hashicorp.terraform" - }, - "[terraform-vars]": { - "editor.defaultFormatter": "hashicorp.terraform" + "[yaml]": { + "editor.defaultFormatter": "esbenp.prettier-vscode" } }, "extensions": [ "DavidAnson.vscode-markdownlint", "EditorConfig.EditorConfig", - "HashiCorp.terraform", "esbenp.prettier-vscode", + "exiasr.hadolint", "GitHub.vscode-github-actions", "GitHub.vscode-pull-request-github", "mads-hartmann.bash-ide-vscode", @@ -89,5 +105,5 @@ "type": "bind" } ], - "runArgs": ["--env-file", ".devcontainer/devcontainer.env"] + "runArgs": ["--env-file", ".devcontainer/devcontainer.env", "--rm"] } diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index a56b4cee..b96980d3 100644 --- a/.github/CONTRIBUTING.md +++ b/.github/CONTRIBUTING.md @@ -2,8 +2,8 @@ :wave: Hi there! -We're thrilled that you'd like to contribute to this project. -Your help is essential for keeping it great. +We're thrilled that you'd like to contribute to this project. Your help is +essential for keeping it great. ## Submitting a pull request @@ -16,7 +16,8 @@ request being accepted: - Keep your change as focused as possible. If there are multiple changes you would like to make that are not dependent upon each other, submit them as separate pull requests. -- Write [descriptive commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). +- Write + [descriptive commit messages](https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html). Draft pull requests are also welcome to get feedback early on, or if there is something blocking you. diff --git a/.github/pull_request-template.md b/.github/pull_request-template.md index 72b972cf..d2baca79 100644 --- a/.github/pull_request-template.md +++ b/.github/pull_request-template.md @@ -17,14 +17,20 @@ In order to have this pull request merged, complete the following tasks. - [ ] I included all the needed documentation for this change. - [ ] I provided the necessary tests. - [ ] I squashed all the commits into a single commit. -- [ ] I followed the [Conventional Commit v1.0.0 spec](https://www.conventionalcommits.org/en/v1.0.0/). -- [ ] I wrote the necessary upgrade instructions in the [upgrade guide](../docs/upgrade-guide.md). -- [ ] If this pull request is about and existing issue, - I added the `Fix #ISSUE_NUMBER` or `Close #ISSUE_NUMBER` text to the description of the pull request. +- [ ] I followed the + [Conventional Commit v1.0.0 spec](https://www.conventionalcommits.org/en/v1.0.0/). +- [ ] I wrote the necessary upgrade instructions in the + [upgrade guide](../docs/upgrade-guide.md). +- [ ] If this pull request is about and existing issue, I added the + `Fix #ISSUE_NUMBER` or `Close #ISSUE_NUMBER` text to the description of + the pull request. ### Super-linter maintainer tasks -- [ ] Label as `breaking` if this change breaks compatibility with the previous released version. -- [ ] Label as either: `automation`, `bug`, `documentation`, `enhancement`, `infrastructure`. +- [ ] Label as `breaking` if this change breaks compatibility with the previous + released version. +- [ ] Label as either: `automation`, `bug`, `documentation`, `enhancement`, + `infrastructure`. - [ ] Add the pull request to a milestone, eventually creating one, that matches - with the version that release-please proposes in the `preview-release-notes` CI job. + with the version that release-please proposes in the + `preview-release-notes` CI job. diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 9073c523..98ab615f 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -207,6 +207,7 @@ jobs: FILTER_REGEX_EXCLUDE: ".*(/test/linters/|CHANGELOG.md).*" RENOVATE_SHAREABLE_CONFIG_PRESET_FILE_NAMES: "default.json,hoge.json" TYPESCRIPT_STANDARD_TSCONFIG_FILE: ".github/linters/tsconfig.json" + VALIDATE_JAVASCRIPT_STANDARD: false - name: Get the contents of the log file run: | @@ -221,6 +222,7 @@ jobs: GITLEAKS_CONFIG_FILE: .gitleaks-ignore-tests.toml FILTER_REGEX_EXCLUDE: ".*(/test/linters/|CHANGELOG.md).*" TYPESCRIPT_STANDARD_TSCONFIG_FILE: ".github/linters/tsconfig.json" + VALIDATE_JAVASCRIPT_STANDARD: false build-test-suite-matrix: name: Build test suite matrix diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 5c633b21..5c2f935d 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -5,9 +5,9 @@ In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body -size, disability, ethnicity, sex characteristics, gender identity and expression, -level of experience, education, socio-economic status, nationality, personal -appearance, race, religion, or sexual identity and orientation. +size, disability, ethnicity, sex characteristics, gender identity and +expression, level of experience, education, socio-economic status, nationality, +personal appearance, race, religion, or sexual identity and orientation. ## Our Standards @@ -37,11 +37,11 @@ Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior. -Project maintainers have the right and responsibility to remove, edit, or -reject comments, commits, code, wiki edits, issues, and other contributions -that are not aligned to this Code of Conduct, or to ban temporarily or -permanently any contributor for other behaviors that they deem inappropriate, -threatening, offensive, or harmful. +Project maintainers have the right and responsibility to remove, edit, or reject +comments, commits, code, wiki edits, issues, and other contributions that are +not aligned to this Code of Conduct, or to ban temporarily or permanently any +contributor for other behaviors that they deem inappropriate, threatening, +offensive, or harmful. ## Scope @@ -58,8 +58,9 @@ Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at . All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is -obligated to maintain confidentiality with regard to the reporter of an incident. -Further details of specific enforcement policies may be posted separately. +obligated to maintain confidentiality with regard to the reporter of an +incident. Further details of specific enforcement policies may be posted +separately. Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other @@ -67,11 +68,13 @@ members of the project's leadership. ## Attribution -This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, +This Code of Conduct is adapted from the [Contributor Covenant][homepage], +version 1.4, -available at [https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct/) +available at +[https://www.contributor-covenant.org/version/1/4/code-of-conduct.html](https://www.contributor-covenant.org/version/1/4/code-of-conduct/) diff --git a/Makefile b/Makefile index 13375ba2..e2dddc9d 100644 --- a/Makefile +++ b/Makefile @@ -242,6 +242,7 @@ test-git-flags: ## Run super-linter with different git-related flags -e IGNORE_GENERATED_FILES=true \ -e IGNORE_GITIGNORED_FILES=true \ -e VALIDATE_ALL_CODEBASE=true \ + -e VALIDATE_JAVASCRIPT_STANDARD=false \ -v "$(CURDIR)":/tmp/lint \ --rm \ $(SUPER_LINTER_TEST_CONTAINER_URL) @@ -260,6 +261,7 @@ lint-codebase: ## Lint the entire codebase -e SAVE_SUPER_LINTER_OUTPUT=true \ -e SAVE_SUPER_LINTER_SUMMARY=true \ -e VALIDATE_ALL_CODEBASE=true \ + -e VALIDATE_JAVASCRIPT_STANDARD=false \ -v "$(CURDIR):/tmp/lint" \ --rm \ $(SUPER_LINTER_TEST_CONTAINER_URL) @@ -288,6 +290,7 @@ fix-codebase: ## Fix and format the entire codebase -e SAVE_SUPER_LINTER_OUTPUT=true \ -e SAVE_SUPER_LINTER_SUMMARY=true \ -e VALIDATE_ALL_CODEBASE=true \ + -e VALIDATE_JAVASCRIPT_STANDARD=false \ -v "$(CURDIR):/tmp/lint" \ --rm \ $(SUPER_LINTER_TEST_CONTAINER_URL) \ @@ -618,3 +621,13 @@ release-please-dry-run: build-dev-container-image check-github-token ## Run rele --target-branch ${RELEASE_PLEASE_TARGET_BRANCH} \ --token "${GITHUB_TOKEN}" \ --trace + +.PHONY: open-shell-dev-container +open-shell-dev-container: build-dev-container-image ## Open a shell in the dev tools container + docker run $(DOCKER_FLAGS) \ + --interactive \ + --entrypoint /bin/bash \ + --rm \ + -v "$(CURDIR)/dev-dependencies/package-lock.json":/package-lock.json \ + -v "$(CURDIR)/dev-dependencies/package.json":/package.json \ + $(DEV_CONTAINER_URL) diff --git a/README.md b/README.md index 1449e8c9..21761d29 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ # Super-Linter -Super-linter is a ready-to-run collection of linters and code analyzers, to -help validate and fix your source code. +Super-linter is a ready-to-run collection of linters and code analyzers, to help +validate and fix your source code. The goal of super-linter is to help you establish best practices and consistent formatting across multiple programming languages, and ensure developers are @@ -10,9 +10,11 @@ adhering to those conventions. Super-linter analyzes source code files using several tools, and reports the issues that those tools find as console output, and as [GitHub Actions status checks](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/collaborating-on-repositories-with-code-quality-features/about-status-checks). -You can also [run super-linter outside GitHub Actions](#run-super-linter-outside-github-actions). +You can also +[run super-linter outside GitHub Actions](#run-super-linter-outside-github-actions). -Super-linter can also help you [fix linting and formatting issues](#fix-linting-and-formatting-issues). +Super-linter can also help you +[fix linting and formatting issues](#fix-linting-and-formatting-issues). Super-linter is licensed under an [MIT License](https://github.com/super-linter/super-linter/blob/main/LICENSE). @@ -29,9 +31,9 @@ Here are some notable Super-linter features: [most widely used](https://github.com/super-linter/super-linter/network/dependents) and [forked](https://github.com/super-linter/super-linter/forks) project of this kind. -- **Runs linters in parallel**: Since `v6`, Super-linter parallelizes - running all the included linters, leading to scanning massive code - repositories in seconds. +- **Runs linters in parallel**: Since `v6`, Super-linter parallelizes running + all the included linters, leading to scanning massive code repositories in + seconds. - **Highly curated set of linters**: Avoid including linters that implement overlapping checks, reducing bloat, scanning times, and container image size. - **Run on GitHub Actions or other environments**: Super-linter runs @@ -114,11 +116,14 @@ Super-linter supports the following tools: ## Get started -More in-depth [tutorial](https://www.youtube.com/watch?v=EDAmFKO4Zt0&t=118s) available +More in-depth [tutorial](https://www.youtube.com/watch?v=EDAmFKO4Zt0&t=118s) +available To run super-linter as a GitHub Action, you do the following: -1. Create a new [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows/about-workflows#about-workflows) in your repository with the following content: +1. Create a new + [GitHub Actions workflow](https://docs.github.com/en/actions/using-workflows/about-workflows#about-workflows) + in your repository with the following content: ```yaml --- @@ -182,8 +187,10 @@ For more information, see Super-Linter provides several variants: -- `standard`: `super-linter/super-linter@[VERSION]`: includes all supported linters. -- `slim`: `super-linter/super-linter/slim@[VERSION]`: includes all supported linters except: +- `standard`: `super-linter/super-linter@[VERSION]`: includes all supported + linters. +- `slim`: `super-linter/super-linter/slim@[VERSION]`: includes all supported + linters except: - Rustfmt - Rust Clippy @@ -419,9 +426,13 @@ You can configure Super-linter using the following environment variables: The `VALIDATE_[LANGUAGE]` variables work as follows: - super-linter runs all supported linters by default. -- If you set any of the `VALIDATE_[LANGUAGE]` variables to `true`, super-linter defaults to leaving any unset variable to false (only validate those languages). -- If you set any of the `VALIDATE_[LANGUAGE]` variables to `false`, super-linter defaults to leaving any unset variable to true (only exclude those languages). -- If you set any of the `VALIDATE_[LANGUAGE]` variables to both `true` and `false`, super-linter fails reporting an error. +- If you set any of the `VALIDATE_[LANGUAGE]` variables to `true`, super-linter + defaults to leaving any unset variable to false (only validate those + languages). +- If you set any of the `VALIDATE_[LANGUAGE]` variables to `false`, super-linter + defaults to leaving any unset variable to true (only exclude those languages). +- If you set any of the `VALIDATE_[LANGUAGE]` variables to both `true` and + `false`, super-linter fails reporting an error. For more information about reusing Super-linter configuration across environments, see @@ -430,9 +441,9 @@ environments, see ## Fix linting and formatting issues All the linters and formatters that Super-linter runs report errors if they -detect linting or formatting issues without modifying your source -code (_check only mode_). Check only mode is the default for all linters and -formatters that Super-linter runs. +detect linting or formatting issues without modifying your source code (_check +only mode_). Check only mode is the default for all linters and formatters that +Super-linter runs. Certain linters and formatters support automatically fixing issues in your code (_fix mode_). You can enable fix mode for a particular linter or formatter by @@ -467,8 +478,8 @@ configuration that doesn't ignore the `yaml` rule. ### Fix mode file and directory ownership When fix mode is enabled, some linters and formatters don't maintain the -original file or directory ownership, and use the user that Super-linter uses -to run the linter or formatter. +original file or directory ownership, and use the user that Super-linter uses to +run the linter or formatter. ### Fix mode examples and workflows @@ -487,6 +498,7 @@ automatically fix linting and formatting issues, commit changes in the current branch, and push commits to the remote branch tracking the current branch whenever a pull request is created or updated: + ```yaml --- name: Lint @@ -538,6 +550,7 @@ jobs: commit_user_name: super-linter commit_user_email: super-linter@super-linter.dev ``` + This example uses [GitHub Actions automatic token authentication](https://docs.github.com/en/actions/security-for-github-actions/security-guides/automatic-token-authentication) @@ -570,10 +583,11 @@ To work around these limitations, you do the following: ## Configure linters -Super-linter provides default configurations for some linters in the [`TEMPLATES/`](./TEMPLATES/) -directory. You can customize the configuration for the linters that support -this by placing your own configuration files in the `LINTER_RULES_PATH` -directory. `LINTER_RULES_PATH` is relative to the `DEFAULT_WORKSPACE` directory. +Super-linter provides default configurations for some linters in the +[`TEMPLATES/`](./TEMPLATES/) directory. You can customize the configuration for +the linters that support this by placing your own configuration files in the +`LINTER_RULES_PATH` directory. `LINTER_RULES_PATH` is relative to the +`DEFAULT_WORKSPACE` directory. Super-linter supports customizing the name of these configuration files. For more information, refer to [Configure super-linter](#configure-super-linter). @@ -601,15 +615,17 @@ For example: - Lint only the `src` folder: `FILTER_REGEX_INCLUDE: .*src/.*` - Do not lint files inside test folder: `FILTER_REGEX_EXCLUDE: .*test/.*` -- Do not lint JavaScript files inside test folder: `FILTER_REGEX_EXCLUDE: .*test/.*.js` -- Do not lint files named `gradlew` and JavaScript files inside a specific directory: `.*/gradlew|.*/specific/directory/*.js` +- Do not lint JavaScript files inside test folder: + `FILTER_REGEX_EXCLUDE: .*test/.*.js` +- Do not lint files named `gradlew` and JavaScript files inside a specific + directory: `.*/gradlew|.*/specific/directory/*.js` Additionally, if you set `IGNORE_GENERATED_FILES` to `true`, super-linter -ignores any file with `@generated` string in it, unless the file -also has `@not-generated` marker. For example, super-linter considers a file -with the following contents as generated: +ignores any file with `@generated` string in it, unless the file also has +`@not-generated` marker. For example, super-linter considers a file with the +following contents as generated: ```bash #!/bin/sh @@ -665,7 +681,8 @@ env: If you need to inject a SSL certificate into the trust store, you can use the `SSL_CERT_SECRET` variable. The value of that variable is expected to be the -path to the files that contains a CA that can be used to validate the certificate: +path to the files that contains a CA that can be used to validate the +certificate: ```yaml env: @@ -674,15 +691,15 @@ env: ## Outputs -Super-linter supports generating several outputs, and also supports exposing -the output of individual linters. +Super-linter supports generating several outputs, and also supports exposing the +output of individual linters. ### Summary outputs Super-linter writes a summary of all the checks: -- If `SAVE_SUPER_LINTER_SUMMARY` is set to `true`, Super-linter writes - a summary to +- If `SAVE_SUPER_LINTER_SUMMARY` is set to `true`, Super-linter writes a summary + to `${DEFAULT_WORKSPACE}/${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/${SUPER_LINTER_SUMMARY_FILE_NAME}`. - If `ENABLE_GITHUB_ACTIONS_STEP_SUMMARY` is set to `true`, Super-linter writes a GitHub Actions job summary. Setting `ENABLE_GITHUB_ACTIONS_STEP_SUMMARY` to @@ -697,8 +714,8 @@ The summary output of previous Super-linter runs is not preserved. ### Super-linter outputs If you set `SAVE_SUPER_LINTER_OUTPUT` to `true`, Super-linter saves its output -to `${DEFAULT_WORKSPACE}/${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/super-linter`, so you -can further process it, if needed. +to `${DEFAULT_WORKSPACE}/${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/super-linter`, so +you can further process it, if needed. Most outputs are in JSON format. diff --git a/TEMPLATES/README.md b/TEMPLATES/README.md index ba155cb7..2f2d1613 100644 --- a/TEMPLATES/README.md +++ b/TEMPLATES/README.md @@ -1,6 +1,10 @@ # TEMPLATES -The files in this folder are template rules for the linters that will run against your codebase. If you choose to copy these to your local repository in the `.github/linters/` directory, they will be used at runtime. If rule files are not present locally, the templates will be used by default. +The files in this folder are template rules for the linters that will run +against your codebase. If you choose to copy these to your local repository in +the `.github/linters/` directory, they will be used at runtime. If rule files +are not present locally, the templates will be used by default. -The file(s) will be parsed at runtime on the local branch to load all rules needed to run the **Super-Linter** **GitHub** Action. -The **GitHub** Action will inform the user via the **Checks API** on the status and success of the process. +The file(s) will be parsed at runtime on the local branch to load all rules +needed to run the **Super-Linter** **GitHub** Action. The **GitHub** Action will +inform the user via the **Checks API** on the status and success of the process. diff --git a/docs/add-new-linter.md b/docs/add-new-linter.md index 956cc121..451c64e1 100644 --- a/docs/add-new-linter.md +++ b/docs/add-new-linter.md @@ -1,39 +1,50 @@ # How to add support for a new tool to super-linter -If you want to propose a _Pull Request_ to add **new** language support or a -new tool, it should include: +If you want to propose a _Pull Request_ to add **new** language support or a new +tool, do the following. -- Update documentation: - - `README.md` -- Provide test cases: +## Update documentation - 1. Create the `test/linters/` directory. - 2. Provide at least one test case with a file that is supposed to pass validation, - with the right file extension if needed: `test/linters//-good` - 3. Provide at least one test case with a file that is supposed to fail validation, - with the right file extension if needed: `test/linters//-bad`. - If the linter supports fix mode, the test case supposed to fail validation - should only contain violations that the fix mode can automatically fix. - Avoid test cases that fail only because of syntax errors, when possible. - 4. Update expected summary reports: `test/data/super-linter-summary`. - 5. If the linter supports check-only mode or fix mode, add the `` - to the `LANGUAGES_WITH_FIX_MODE` array in `test/testUtils.sh` +- `README.md` -- Update the test suite to check for installed packages, the commands that your new tool needs in the `PATH`, and the expected version command: +## Provide test cases - - `test/inspec/super-linter/controls/super_linter.rb` +1. Create the `test/linters/` directory. +2. Provide at least one test case with a file that is supposed to pass + validation, with the right file extension if needed: + `test/linters//-good` +3. Provide at least one test case with a file that is supposed to fail + validation, with the right file extension if needed: + `test/linters//-bad`. If the tool supports fix + mode, the test case supposed to fail validation should only contain + violations that the fix mode can automatically fix. Avoid test cases that + fail only because of syntax errors, when possible. +4. Update expected summary reports: `test/data/super-linter-summary`. +5. If the tool supports check-only mode or fix mode, add the `` to + the `LANGUAGES_WITH_FIX_MODE` array in `test/testUtils.sh` + +## Update the test suite + +Update the test suite to check for installed packages, the commands that your +new tool needs in the `PATH`, and the expected version command: + +- `test/inspec/super-linter/controls/super_linter.rb` + +## Install the tool - Install the tool by pointing to specific package or container image versions: - - If there are PyPi packages, create a text file named `dependencies/python/.txt` - and list the packages there. - - If there are npm packages, update `dependencies/package.json` and `dependencies/package-lock.json`. - by adding the new packages. - - If there are Ruby Gems, update `dependencies/Gemfile` and `dependencies/Gemfile.lock` + - If there are PyPi packages, create a text file named + `dependencies/python/.txt` and list the packages there. + - If there are npm packages, update `dependencies/package.json` and + `dependencies/package-lock.json`. by adding the new packages. + - If there are Ruby Gems, update `dependencies/Gemfile` and + `dependencies/Gemfile.lock` - If there are Maven or Java packages: 1. Create a directory named `dependencies/`. - 2. Create a `dependencies//build.gradle` file with the following contents: + 2. Create a `dependencies//build.gradle` file with the + following contents: ```gradle repositories { @@ -50,8 +61,8 @@ new tool, it should include: version '1.0.0-SNAPSHOT' ``` - 3. Update the `dependencies` section in `dependencies//build.gradle` to - install your dependencies. + 3. Update the `dependencies` section in + `dependencies//build.gradle` to install your dependencies. 4. Add the following content to the `Dockerfile`: ```dockerfile @@ -59,8 +70,9 @@ new tool, it should include: RUN --mount=type=secret,id=GITHUB_TOKEN /.sh && rm -rf /.sh ``` - 5. Create `scripts/install-.sh`, and implement the logic to install your tool. - You get the version of a dependency from `build.gradle`. Example: + 5. Create `scripts/install-.sh`, and implement the logic to + install your tool. You get the version of a dependency from + `build.gradle`. Example: ```sh GOOGLE_JAVA_FORMAT_VERSION="$(grep <"google-java-format/build.gradle" "google-java-format" | awk -F ':' '{print $3}' | tr -d "'")" @@ -84,89 +96,119 @@ new tool, it should include: FROM your/image:version as ``` - 1. Copy the necessary binaries and libraries to the relevant locations. Example: + 1. Copy the necessary binaries and libraries to the relevant locations. + Example: ```sh COPY --from= /usr/local/bin/ /usr/bin/ ``` -- Configure the new tool: - - - Provide a default configuration file only if the tool cannot function without one: `TEMPLATES/