mirror of
https://github.com/actions/setup-java.git
synced 2024-08-16 10:19:51 +02:00
Fixes from VS Code MD Linter
This commit is contained in:
Martijn Verburg
parent
19eeec562b
commit
2035861ae2
7 changed files with 131 additions and 86 deletions
|
|
@ -68,9 +68,9 @@ members of the project's leadership.
|
|||
## Attribution
|
||||
|
||||
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
|
||||
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.html)
|
||||
|
||||
[homepage]: https://www.contributor-covenant.org
|
||||
|
||||
For answers to common questions about this code of conduct, see
|
||||
https://www.contributor-covenant.org/faq
|
||||
[https://www.contributor-covenant.org/faq](https://www.contributor-covenant.org/faq)
|
||||
|
|
|
|||
51
README.md
51
README.md
|
|
@ -3,6 +3,7 @@
|
|||
[](https://github.com/actions/setup-java/actions/workflows/workflow.yml)
|
||||
|
||||
The `setup-java` action provides the following functionality for GitHub Actions runners:
|
||||
|
||||
- Downloading and setting up a requested version of Java. See [Usage](#Usage) for a list of supported distributions
|
||||
- Extracting and caching custom version of Java from a local file
|
||||
- Configuring runner for publishing using Apache Maven
|
||||
|
|
@ -23,44 +24,46 @@ This action allows you to work with Java and Scala projects.
|
|||
|
||||
## Usage
|
||||
|
||||
- `java-version`: _(required)_ The Java version to set up. Takes a whole or [semver](#supported-version-syntax) Java version.
|
||||
- `java-version`: _(required)_ The Java version to set up. Takes a whole or [semver](#supported-version-syntax) Java version.
|
||||
|
||||
- `distribution`: _(required)_ Java [distribution](#supported-distributions).
|
||||
- `distribution`: _(required)_ Java [distribution](#supported-distributions).
|
||||
|
||||
- `java-package`: The packaging variant of the choosen distribution. Possible values: `jdk`, `jre`, `jdk+fx`, `jre+fx`. Default value: `jdk`.
|
||||
- `java-package`: The packaging variant of the chosen distribution. Possible values: `jdk`, `jre`, `jdk+fx`, `jre+fx`. Default value: `jdk`.
|
||||
|
||||
- `architecture`: The target architecture of the package. Possible values: `x86`, `x64`, `armv7`, `aarch64`, `ppc64le`. Default value: `x64`.
|
||||
- `architecture`: The target architecture of the package. Possible values: `x86`, `x64`, `armv7`, `aarch64`, `ppc64le`. Default value: `x64`.
|
||||
|
||||
- `jdkFile`: If a use-case requires a custom distribution setup-java uses the compressed JDK from the location pointed by this input and will take care of the installation and caching on the VM.
|
||||
- `jdkFile`: If a use-case requires a custom distribution setup-java uses the compressed JDK from the location pointed by this input and will take care of the installation and caching on the VM.
|
||||
|
||||
- `check-latest`: Setting this option makes the action to check for the latest available version for the version spec.
|
||||
- `check-latest`: Setting this option makes the action to check for the latest available version for the version spec.
|
||||
|
||||
- `cache`: Quick [setup caching](#caching-packages-dependencies) for the dependencies managed through one of the predifined package managers. It can be one of "maven", "gradle" or "sbt".
|
||||
- `cache`: Quick [setup caching](#caching-packages-dependencies) for the dependencies managed through one of the predefined package managers. It can be one of "maven", "gradle" or "sbt".
|
||||
|
||||
#### Maven options
|
||||
The action has a bunch of inputs to generate maven's [settings.xml](https://maven.apache.org/settings.html) on the fly and pass the values to Apache Maven GPG Plugin as well as Apache Maven Toolchains. See [advanced usage](docs/advanced-usage.md) for more.
|
||||
### Maven options
|
||||
|
||||
- `overwrite-settings`: By default action overwrites the settings.xml. In order to skip generation of file if it exists set this to `false`.
|
||||
The action has a bunch of inputs to generate maven's [settings.xml](https://maven.apache.org/settings.html) on the fly and pass the values to Apache Maven GPG Plugin as well as Apache Maven Toolchains. See [advanced usage](docs/advanced-usage.md) for more.
|
||||
|
||||
- `server-id`: ID of the distributionManagement repository in the pom.xml file. Default is `github`.
|
||||
- `overwrite-settings`: By default action overwrites the settings.xml. In order to skip generation of file if it exists set this to `false`.
|
||||
|
||||
- `server-username`: Environment variable name for the username for authentication to the Apache Maven repository. Default is GITHUB_ACTOR.
|
||||
- `server-id`: ID of the distributionManagement repository in the pom.xml file. Default is `github`.
|
||||
|
||||
- `server-password`: Environment variable name for password or token for authentication to the Apache Maven repository. Default is GITHUB_TOKEN.
|
||||
- `server-username`: Environment variable name for the username for authentication to the Apache Maven repository. Default is GITHUB_ACTOR.
|
||||
|
||||
- `settings-path`: Maven related setting to point to the diractory where the settings.xml file will be written. Default is ~/.m2.
|
||||
- `server-password`: Environment variable name for password or token for authentication to the Apache Maven repository. Default is GITHUB_TOKEN.
|
||||
|
||||
- `gpg-private-key`: GPG private key to import. Default is empty string.'
|
||||
- `settings-path`: Maven related setting to point to the directory where the settings.xml file will be written. Default is ~/.m2.
|
||||
|
||||
- `gpg-passphrase`: description: 'Environment variable name for the GPG private key passphrase. Default is GPG_PASSPHRASE.
|
||||
- `gpg-private-key`: GPG private key to import. Default is empty string.'
|
||||
|
||||
- `mvn-toolchain-id`: Name of Maven Toolchain ID if the default name of `${distribution}_${java-version}` is not wanted.
|
||||
- `gpg-passphrase`: description: 'Environment variable name for the GPG private key passphrase. Default is GPG_PASSPHRASE.
|
||||
|
||||
- `mvn-toolchain-vendor`: Name of Maven Toolchain Vendor if the default name of `${distribution}` is not wanted.
|
||||
- `mvn-toolchain-id`: Name of Maven Toolchain ID if the default name of `${distribution}_${java-version}` is not wanted.
|
||||
|
||||
- `mvn-toolchain-vendor`: Name of Maven Toolchain Vendor if the default name of `${distribution}` is not wanted.
|
||||
|
||||
### Basic Configuration
|
||||
|
||||
#### Eclipse Temurin
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -72,6 +75,7 @@ steps:
|
|||
```
|
||||
|
||||
#### Azul Zulu OpenJDK
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -83,12 +87,15 @@ steps:
|
|||
```
|
||||
|
||||
#### Supported version syntax
|
||||
|
||||
The `java-version` input supports an exact version or a version range using [SemVer](https://semver.org/) notation:
|
||||
|
||||
- major versions: `8`, `11`, `16`, `17`
|
||||
- more specific versions: `17.0`, `11.0`, `11.0.4`, `8.0.232`, `8.0.282+8`
|
||||
- early access (EA) versions: `15-ea`, `15.0.0-ea`, `15.0.0-ea.2`, `15.0.0+2-ea`
|
||||
|
||||
#### Supported distributions
|
||||
|
||||
Currently, the following distributions are supported:
|
||||
| Keyword | Distribution | Official site | License
|
||||
|-|-|-|-|
|
||||
|
|
@ -108,7 +115,9 @@ Currently, the following distributions are supported:
|
|||
**NOTE:** For Azul Zulu OpenJDK architectures x64 and arm64 are mapped to x86 / arm with proper hw_bitness.
|
||||
|
||||
### Caching packages dependencies
|
||||
|
||||
The action has a built-in functionality for caching and restoring dependencies. It uses [actions/cache](https://github.com/actions/cache) under hood for caching dependencies but requires less configuration settings. Supported package managers are gradle, maven and sbt. The format of the used cache key is `setup-java-${{ platform }}-${{ packageManager }}-${{ fileHash }}`, where the hash is based on the following files:
|
||||
|
||||
- gradle: `**/*.gradle*`, `**/gradle-wrapper.properties`, `buildSrc/**/Versions.kt`, `buildSrc/**/Dependencies.kt`, and `gradle/*.versions.toml`
|
||||
- maven: `**/pom.xml`
|
||||
- sbt: all sbt build definition files `**/*.sbt`, `**/project/build.properties`, `**/project/**.{scala,sbt}`
|
||||
|
|
@ -118,6 +127,7 @@ The workflow output `cache-hit` is set to indicate if an exact match was found f
|
|||
The cache input is optional, and caching is turned off by default.
|
||||
|
||||
#### Caching gradle dependencies
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -130,6 +140,7 @@ steps:
|
|||
```
|
||||
|
||||
#### Caching maven dependencies
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -143,6 +154,7 @@ steps:
|
|||
```
|
||||
|
||||
#### Caching sbt dependencies
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -163,7 +175,6 @@ If `check-latest` is set to `true`, the action first checks if the cached versio
|
|||
|
||||
For Java distributions that are not cached on Hosted images, `check-latest` always behaves as `true` and downloads Java on-flight. Check out [Hosted Tool Cache](docs/advanced-usage.md#Hosted-Tool-Cache) for more details about pre-cached Java versions.
|
||||
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -176,6 +187,7 @@ steps:
|
|||
```
|
||||
|
||||
### Testing against different Java versions
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build:
|
||||
|
|
@ -210,6 +222,7 @@ All versions are added to the PATH. The last version will be used and available
|
|||
```
|
||||
|
||||
### Using Maven Toolchains
|
||||
|
||||
In the example above multiple JDKs are installed for the same job. The result after the last JDK is installed is a Maven Toolchains declaration containing references to all three JDKs. The values for `id`, `version`, and `vendor` of the individual Toolchain entries are the given input values for `distribution` and `java-version` (`vendor` being the combination of `${distribution}_${java-version}`) by default.
|
||||
|
||||
### Advanced Configuration
|
||||
|
|
|
|||
|
|
@ -4,17 +4,17 @@ Date: 2020-08-24
|
|||
|
||||
Status: Proposed
|
||||
|
||||
# Context
|
||||
## Context
|
||||
|
||||
- The `v1` version of `setup-java` downloads and installs Zulu builds of OpenJDK. There is a huge ask from customers to offer AdoptOpenJDK/Adoptium builds of OpenJDK: https://github.com/actions/setup-java/issues/13
|
||||
- The `v1` version of `setup-java` downloads and installs Zulu builds of OpenJDK. There is a huge ask from customers to offer AdoptOpenJDK/Adoptium builds of OpenJDK: [https://github.com/actions/setup-java/issues/13](https://github.com/actions/setup-java/issues/13)
|
||||
|
||||
- Zulu and AdoptOpenJDK aren't the only distributions of Java though. Other providers include Oracle OpenJDK or Amazon Corretto and ideally it would be nice to support downloading Java from all providers.
|
||||
|
||||
- GitHub Actions virtual environments install and default to AdoptOpenJDK builds of OpenJDK. `setup-java` should give users an option to download and use other distributions that may not be be installed
|
||||
|
||||
# Decision
|
||||
## Decision
|
||||
|
||||
## New input
|
||||
### New input
|
||||
|
||||
A new required input parameter (titled `distribution`) will be added to `setup-java` that will allow users to specify the distribution that they would like to download
|
||||
|
||||
|
|
@ -24,13 +24,13 @@ A new required input parameter (titled `distribution`) will be added to `setup-j
|
|||
distribution: adoptium
|
||||
```
|
||||
|
||||
## Default Behavior
|
||||
### Default Behavior
|
||||
|
||||
There will be no default distribution that we pick for the user. Users will have to specify a distribution in their YAML or else the action will fail.
|
||||
|
||||
Requiring a default version will break users that are pinned to `@main` as they will have no `distribution` specified in their YAML. Telemetry indicates that only a small percentage of users would be effected though. Users pinned to `v1` will be uneffected. This change is meant to not be backward compatible and it is acceptable to change the default behavior because a new major version will be released alongside these changes.
|
||||
Requiring a default version will break users that are pinned to `@main` as they will have no `distribution` specified in their YAML. Telemetry indicates that only a small percentage of users would be effected though. Users pinned to `v1` will be unaffected. This change is meant to not be backward compatible and it is acceptable to change the default behavior because a new major version will be released alongside these changes.
|
||||
|
||||
## Extensibility & Documentation
|
||||
### Extensibility & Documentation
|
||||
|
||||
`setup-java` should be structured in such a way that will allow the open source community to easily add support for extra distributions.
|
||||
|
||||
|
|
@ -47,17 +47,17 @@ Existing code will be restructured so that distribution specific code will be ea
|
|||
|
||||
The contribution doc (`CONTRIBUTING.md`) will describe how a new distribution should be added and how everything should be structured.
|
||||
|
||||
## v2-preview
|
||||
### v2-preview
|
||||
|
||||
There will be a `v2-preview` branch that will be created for development and testing. Any changes will first be merged into `v2-preview` branch. After a period of testing & verification, the `v2-preview` branch will be merged into the `main` branch and a `v2` tag will be created. Any [GitHub public documentation](https://docs.github.com/en/actions/language-and-framework-guides/github-actions-for-java) and [starter workflows](https://github.com/actions/starter-workflows) that mention `setup-java` will then be updated to use `v2` instead of `v1`.
|
||||
|
||||
## Goals & Anti-Goals
|
||||
### Goals & Anti-Goals
|
||||
|
||||
The main focus of the `v2` version of `setup-java` will be to add support for adoptium builds of openJDK in addition to Zulu builds of openJDK. In addition, extensibility will be a priority so that other distributions can be added in the future.
|
||||
|
||||
The `setup-java` action has some logic that creates a `settings.xml` file so that it is easier to publish packages. Any improvements or modifications to this logic or anything Gradle/Maven specific will be avoided during the development of the `v2-preview`.
|
||||
|
||||
# Consequences
|
||||
## Consequences
|
||||
|
||||
- Users will have more flexibility and the freedom to choose a specific distribution that they would like (AdoptOpenJDK builds of OpenJDK in addition or Zulu builds of OpenJDK)
|
||||
- `setup-java` will be structured in such a way that will allow for more distributions to be easily added in the future
|
||||
|
|
|
|||
|
|
@ -16,4 +16,4 @@ This folder includes ADRs for the setup-java action. ADRs are proposed in the fo
|
|||
|
||||
---
|
||||
|
||||
- More information about ADRs can be found [here](https://github.com/joelparkerhenderson/architecture_decision_record).
|
||||
* More information about ADRs can be found [here](https://github.com/joelparkerhenderson/architecture_decision_record).
|
||||
|
|
|
|||
|
|
@ -1,4 +1,5 @@
|
|||
# Usage
|
||||
|
||||
- [Selecting a Java distribution](#Selecting-a-Java-distribution)
|
||||
- [Eclipse Temurin](#Eclipse-Temurin)
|
||||
- [Adopt](#Adopt)
|
||||
|
|
@ -20,9 +21,11 @@
|
|||
See [action.yml](../action.yml) for more details on task inputs.
|
||||
|
||||
## Selecting a Java distribution
|
||||
|
||||
Inputs `java-version` and `distribution` are mandatory and needs to be provided. See [Supported distributions](../README.md#Supported-distributions) for a list of available options.
|
||||
|
||||
### Eclipse Temurin
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -34,6 +37,7 @@ steps:
|
|||
```
|
||||
|
||||
### Adopt
|
||||
|
||||
**NOTE:** Adopt OpenJDK got moved to Eclipse Temurin and won't be updated anymore. It is highly recommended to migrate workflows from `adopt` to `temurin` to keep receiving software and security updates. See more details in the [Good-bye AdoptOpenJDK post](https://blog.adoptopenjdk.net/2021/08/goodbye-adoptopenjdk-hello-adoptium/).
|
||||
|
||||
```yaml
|
||||
|
|
@ -47,6 +51,7 @@ steps:
|
|||
```
|
||||
|
||||
### Zulu
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -59,6 +64,7 @@ steps:
|
|||
```
|
||||
|
||||
### Liberica
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -71,6 +77,7 @@ steps:
|
|||
```
|
||||
|
||||
### Microsoft
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -98,6 +105,7 @@ with:
|
|||
If the runner is not able to access github.com, any Java versions requested during a workflow run must come from the runner's tool cache. See "[Setting up the tool cache on self-hosted runners without internet access](https://docs.github.com/en/enterprise-server@3.2/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access)" for more information.
|
||||
|
||||
### Amazon Corretto
|
||||
|
||||
**NOTE:** Amazon Corretto only supports the major version specification.
|
||||
|
||||
```yaml
|
||||
|
|
@ -111,6 +119,7 @@ steps:
|
|||
```
|
||||
|
||||
### Oracle
|
||||
|
||||
**NOTE:** Oracle Java SE Development Kit is only available for version 17 and later.
|
||||
|
||||
```yaml
|
||||
|
|
@ -124,6 +133,7 @@ steps:
|
|||
```
|
||||
|
||||
## Installing custom Java package type
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
|
@ -135,7 +145,6 @@ steps:
|
|||
- run: java -cp java HelloWorldApp
|
||||
```
|
||||
|
||||
|
||||
## Installing custom Java architecture
|
||||
|
||||
```yaml
|
||||
|
|
@ -150,6 +159,7 @@ steps:
|
|||
```
|
||||
|
||||
## Installing Java from local file
|
||||
|
||||
If your use-case requires a custom distribution or a version that is not provided by setup-java, you can download it manually and setup-java will take care of the installation and caching on the VM:
|
||||
|
||||
```yaml
|
||||
|
|
@ -168,7 +178,9 @@ steps:
|
|||
```
|
||||
|
||||
## Testing against different Java distributions
|
||||
|
||||
**NOTE:** The different distributors can provide discrepant list of available versions / supported configurations. Please refer to the official documentation to see the list of supported versions.
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build:
|
||||
|
|
@ -188,7 +200,8 @@ jobs:
|
|||
- run: java -cp java HelloWorldApp
|
||||
```
|
||||
|
||||
#### Testing against different platforms
|
||||
### Testing against different platforms
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build:
|
||||
|
|
@ -209,7 +222,9 @@ jobs:
|
|||
```
|
||||
|
||||
## Publishing using Apache Maven
|
||||
### Yaml example:
|
||||
|
||||
### Yaml example
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
build:
|
||||
|
|
@ -253,6 +268,7 @@ jobs:
|
|||
The two `settings.xml` files created from the above example look like the following.
|
||||
|
||||
`settings.xml` file created for the first deploy to GitHub Packages
|
||||
|
||||
```xml
|
||||
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
|
|
@ -272,6 +288,7 @@ The two `settings.xml` files created from the above example look like the follow
|
|||
```
|
||||
|
||||
`settings.xml` file created for the second deploy to Apache Maven Central
|
||||
|
||||
```xml
|
||||
<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
|
||||
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
|
||||
|
|
@ -294,7 +311,7 @@ The two `settings.xml` files created from the above example look like the follow
|
|||
|
||||
If you don't want to overwrite the `settings.xml` file, you can set `overwrite-settings: false`
|
||||
|
||||
### Extra setup for pom.xml:
|
||||
### Extra setup for pom.xml
|
||||
|
||||
The Maven GPG Plugin configuration in the pom.xml file should contain the following structure to avoid possible issues like `Inappropriate ioctl for device` or `gpg: signing failed: No such file or directory`:
|
||||
|
||||
|
|
@ -307,6 +324,7 @@ The Maven GPG Plugin configuration in the pom.xml file should contain the follow
|
|||
</gpgArguments>
|
||||
</configuration>
|
||||
```
|
||||
|
||||
GPG 2.1 requires `--pinentry-mode` to be set to `loopback` in order to pick up the `gpg.passphrase` value defined in Maven `settings.xml`.
|
||||
|
||||
### GPG
|
||||
|
|
@ -346,6 +364,7 @@ jobs:
|
|||
```
|
||||
|
||||
## Publishing using Gradle
|
||||
|
||||
```yaml
|
||||
jobs:
|
||||
|
||||
|
|
@ -376,6 +395,7 @@ jobs:
|
|||
See the help docs on [Publishing a Package with Gradle](https://help.github.com/en/github/managing-packages-with-github-packages/configuring-gradle-for-use-with-github-packages#example-using-gradle-groovy-for-a-single-package-in-a-repository) for more information on the `build.gradle` configuration file.
|
||||
|
||||
## Hosted Tool Cache
|
||||
|
||||
GitHub Hosted Runners have a tool cache that comes with some Java versions pre-installed. This tool cache helps speed up runs and tool setup by not requiring any new downloads. There is an environment variable called `RUNNER_TOOL_CACHE` on each runner that describes the location of this tools cache and this is where you can find the pre-installed versions of Java. `setup-java` works by taking a specific version of Java in this tool cache and adding it to PATH if the version, architecture and distribution match.
|
||||
|
||||
Currently, LTS versions of Eclipse Temurin (`temurin`) are cached on the GitHub Hosted Runners.
|
||||
|
|
@ -383,9 +403,11 @@ Currently, LTS versions of Eclipse Temurin (`temurin`) are cached on the GitHub
|
|||
The tools cache gets updated on a weekly basis. For information regarding locally cached versions of Java on GitHub hosted runners, check out [GitHub Actions Virtual Environments](https://github.com/actions/virtual-environments).
|
||||
|
||||
## Modifying Maven Toolchains
|
||||
|
||||
The `setup-java` action generates a basic [Maven Toolchains declaration](https://maven.apache.org/guides/mini/guide-using-toolchains.html) for specified Java versions by either creating a minimal toolchains file or extending an existing declaration with the additional JDKs.
|
||||
|
||||
### Installing Multiple JDKs With Toolchains
|
||||
|
||||
Subsequent calls to `setup-java` with distinct distribution and version parameters will continue to extend the toolchains declaration and make all specified Java versions available.
|
||||
|
||||
```yaml
|
||||
|
|
@ -417,9 +439,10 @@ The result is a Toolchain with entries for JDKs 8, 11 and 15. You can even combi
|
|||
architecture: x64
|
||||
```
|
||||
|
||||
This will generate a Toolchains entry with the following values: `version: 1.6`, `vendor: jkdfile`, `id: Oracle_1.6`.
|
||||
This will generate a Toolchains entry with the following values: `version: 1.6`, `vendor: jdkfile`, `id: Oracle_1.6`.
|
||||
|
||||
### Modifying The Toolchain Vendor For JDKs
|
||||
|
||||
Each JDK provider will receive a default `vendor` using the `distribution` input value but this can be overridden with the `mvn-toolchain-vendor` parameter as follows.
|
||||
|
||||
```yaml
|
||||
|
|
@ -451,6 +474,7 @@ steps:
|
|||
```
|
||||
|
||||
### Modifying The Toolchain ID For JDKs
|
||||
|
||||
Each JDK provider will receive a default `id` based on the combination of `distribution` and `java-version` in the format of `distribution_java-version` (e.g. `temurin_11`) but this can be overridden with the `mvn-toolchain-id` parameter as follows.
|
||||
|
||||
```yaml
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@ Thank you for contributing!
|
|||
|
||||
We have prepared a short guide so that the process of making your contribution is as simple and clear as possible. Please check it out before you contribute!
|
||||
|
||||
## How can I contribute...
|
||||
## How can I contribute?
|
||||
|
||||
* [Contribute Documentation:green_book:](#contribute-documentation)
|
||||
|
||||
|
|
@ -22,20 +22,21 @@ Documentation contributions of any size are welcome! Feel free to contribute eve
|
|||
|
||||
**How to contribute:**
|
||||
|
||||
Pull requests are the easiest way to contribute changes to git repos at GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes.
|
||||
Pull requests are the easiest way to contribute changes to git repos at GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes
|
||||
|
||||
- Please check that no one else has already created a pull request with these or similar changes
|
||||
- Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request
|
||||
- Make sure your changes are formatted properly and consistently with the rest of the documentation
|
||||
- Re-read what you wrote, and run a spellchecker on it to make sure you didn't miss anything
|
||||
- If your pull request is connected to an open issue, please, leave a link to this issue in the `Related issue:` section
|
||||
- If you later need to add new commits to the pull request, you can simply commit the changes to the local branch and then push them. The pull request gets automatically updated
|
||||
* Please check that no one else has already created a pull request with these or similar changes
|
||||
* Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request
|
||||
* Make sure your changes are formatted properly and consistently with the rest of the documentation
|
||||
* Re-read what you wrote, and run a spellchecker on it to make sure you didn't miss anything
|
||||
* If your pull request is connected to an open issue, please, leave a link to this issue in the `Related issue:` section
|
||||
* If you later need to add new commits to the pull request, you can simply commit the changes to the local branch and then push them. The pull request gets automatically updated
|
||||
|
||||
**Once you've filed the pull request:**
|
||||
|
||||
- Maintainers will review your pull request
|
||||
- If a maintainer requests changes, first of all, try to think about this request critically and only after that implement and request another review
|
||||
- If your PR gets accepted, it will soon be merged into the main branch. But your contribution will take effect only after the release of a new version of the action and updating the major tag
|
||||
* Maintainers will review your pull request
|
||||
* If a maintainer requests changes, first of all, try to think about this request critically and only after that implement and request another review
|
||||
* If your PR gets accepted, it will soon be merged into the main branch. But your contribution will take effect only after the release of a new version of the action and updating the major tag
|
||||
|
||||
> Sometimes maintainers reject pull requests and that's ok! Usually, along with rejection, we supply the reason for it. Nonetheless, we still really appreciate you taking the time to do it, and we don't take that lightly :heart:
|
||||
|
||||
## Contribute code
|
||||
|
|
@ -50,33 +51,34 @@ The main difference between code contributions and documentation contributions i
|
|||
|
||||
Pull requests are the easiest way to contribute changes to git repos at GitHub. They are the preferred contribution method, as they offer a convenient way of commenting and amending the proposed changes.
|
||||
|
||||
- Please check that no one else has already created a pull request with these or similar changes
|
||||
- Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request
|
||||
- Make sure your changes are well formatted and that all tests are passing
|
||||
- If your pull request is connected to an open issue, please, leave a link to this issue in the `Related issue:` section
|
||||
- If you later need to add new commits to the pull request, you can simply commit the changes to the local branch and then push them. The pull request gets automatically updated
|
||||
* Please check that no one else has already created a pull request with these or similar changes
|
||||
* Use a "feature branch" for your changes. That separates the changes in the pull request from your other changes and makes it easy to edit/amend commits in the pull request
|
||||
* Make sure your changes are well formatted and that all tests are passing
|
||||
* If your pull request is connected to an open issue, please, leave a link to this issue in the `Related issue:` section
|
||||
* If you later need to add new commits to the pull request, you can simply commit the changes to the local branch and then push them. The pull request gets automatically updated
|
||||
|
||||
**Learn more about how to work with the repository:**
|
||||
|
||||
- To implement new features or fix bugs, you need to make changes to the `.ts` files, which are located in the `src` folder
|
||||
- To comply with the code style, **you need to run the `format` script**
|
||||
- To transpile source code to `javascript` we use [NCC](https://github.com/vercel/ncc). **It is very important to run the `build` script after making changes**, otherwise your changes will not get into the final `javascript` build
|
||||
* To implement new features or fix bugs, you need to make changes to the `.ts` files, which are located in the `src` folder
|
||||
* To comply with the code style, **you need to run the `format` script**
|
||||
* To transpile source code to `javascript` we use [NCC](https://github.com/vercel/ncc). **It is very important to run the `build` script after making changes**, otherwise your changes will not get into the final `javascript` build
|
||||
|
||||
**Learn more about how to implement tests:**
|
||||
|
||||
Adding or changing tests is an integral part of making a change to the code.
|
||||
Unit tests are in the `__tests__` folder, and end-to-end tests are in the `workflows` folder, particularly take a look at the files with `e2e` prefix, for instance, [e2e-cache.yml](https://github.com/actions/setup-java/blob/main/.github/workflows/e2e-cache.yml).
|
||||
|
||||
- The contributor can add various types of tests (like unit tests or end-to-end tests), which, in his opinion, will be necessary and sufficient for testing new or changed functionality
|
||||
- Tests should cover a successful execution, as well as some edge cases and possible errors
|
||||
- As already mentioned, pull requests without tests will be considered more carefully by maintainers. If you are sure that in this situation the tests are not needed or cannot be implemented with a commensurate effort - please add this clarification message to your pull request
|
||||
* The contributor can add various types of tests (like unit tests or end-to-end tests), which, in his opinion, will be necessary and sufficient for testing new or changed functionality
|
||||
* Tests should cover a successful execution, as well as some edge cases and possible errors
|
||||
* As already mentioned, pull requests without tests will be considered more carefully by maintainers. If you are sure that in this situation the tests are not needed or cannot be implemented with a commensurate effort - please add this clarification message to your pull request
|
||||
|
||||
**Once you've filed the pull request:**
|
||||
|
||||
- CI will start automatically with some checks. Wait until the end of the execution and make sure that all checks passed successfully. If some checks fail, you can open them one by one, try to find the reason for failing and make changes to your code to resolve the problem
|
||||
- Maintainers will review your pull request
|
||||
- If a maintainer requests changes, first of all, try to think about his request critically and only after that implement and request another review
|
||||
- If your PR gets accepted, it will soon be merged into the main branch. But your contribution will take effect only after the release of a new version of the action and updating the major tag
|
||||
* CI will start automatically with some checks. Wait until the end of the execution and make sure that all checks passed successfully. If some checks fail, you can open them one by one, try to find the reason for failing and make changes to your code to resolve the problem
|
||||
* Maintainers will review your pull request
|
||||
* If a maintainer requests changes, first of all, try to think about his request critically and only after that implement and request another review
|
||||
* If your PR gets accepted, it will soon be merged into the main branch. But your contribution will take effect only after the release of a new version of the action and updating the major tag
|
||||
|
||||
> Sometimes maintainers reject pull requests and that's ok! Usually, along with rejection, we supply the reason for it. Nonetheless, we still really appreciate you taking the time to do it, and we don't take that lightly :heart:
|
||||
|
||||
## Provide support on issues
|
||||
|
|
@ -85,29 +87,29 @@ Helping out other users with their questions is an awesome way of contributing t
|
|||
|
||||
**To help other folks out with their questions:**
|
||||
|
||||
- Go to the [issue tracker](https://github.com/actions/setup-java/issues)
|
||||
- Read through the list until you find something that you're familiar enough with to answer to
|
||||
- Respond to the issue with whatever details are needed to clarify the question, or get more details about what's going on
|
||||
- Once the discussion wraps up and things are clarified, ask the original issue filer (or a maintainer) to close it for you
|
||||
* Go to the [issue tracker](https://github.com/actions/setup-java/issues)
|
||||
* Read through the list until you find something that you're familiar enough with to answer to
|
||||
* Respond to the issue with whatever details are needed to clarify the question, or get more details about what's going on
|
||||
* Once the discussion wraps up and things are clarified, ask the original issue filer (or a maintainer) to close it for you
|
||||
|
||||
*Some notes on picking up support issues:*
|
||||
|
||||
- Avoid responding to issues you don't know you can answer accurately
|
||||
- Try to refer to past issues with accepted answers as much as possible. Link to them from your replies
|
||||
- Be kind and patient with users. Often, folks who have run into confusing things might be upset or impatient. This is natural. If you feel uncomfortable in conversation with them, it's better to stay away or withdraw from the issue.
|
||||
* Avoid responding to issues you don't know you can answer accurately
|
||||
* Try to refer to past issues with accepted answers as much as possible. Link to them from your replies
|
||||
* Be kind and patient with users. Often, folks who have run into confusing things might be upset or impatient. This is natural. If you feel uncomfortable in conversation with them, it's better to stay away or withdraw from the issue.
|
||||
|
||||
> If some user is violating our code of conduct [standards](https://github.com/actions/setup-java/blob/main/CODE_OF_CONDUCT.md#our-standards), refer to the [enforcement](https://github.com/actions/setup-java/blob/main/CODE_OF_CONDUCT.md#enforcement) section of the Code of Conduct to resolve the conflict
|
||||
|
||||
|
||||
## Review pull requests
|
||||
|
||||
|
||||
Another great way to contribute is is to review pull request. Please, be extra kind: people who submit code/doc contributions are putting themselves in a pretty vulnerable position, and have put time and care into what they've done (even if that's not obvious to you!) Please, always respond with respect, and be understanding, but don't feel like you need to sacrifice your standards for their sake, either.
|
||||
|
||||
**How to review:**
|
||||
|
||||
- Go to the [pull requests](https://github.com/actions/setup-java/pulls)
|
||||
- Make sure you're familiar with the code or documentation is updated, unless it's a minor change (spellchecking, minor formatting, etc.)
|
||||
- Review changes using the GitHub functionality. You can ask a clarifying question, point out an error or suggest an alternative.
|
||||
* Go to the [pull requests](https://github.com/actions/setup-java/pulls)
|
||||
* Make sure you're familiar with the code or documentation is updated, unless it's a minor change (spellchecking, minor formatting, etc.)
|
||||
* Review changes using the GitHub functionality. You can ask a clarifying question, point out an error or suggest an alternative.
|
||||
|
||||
> Note: You may ask for minor changes - "nitpicks", but consider whether they are real blockers to merging or not
|
||||
- Submit your review, which may include comments, an approval, or a changes request
|
||||
|
||||
* Submit your review, which may include comments, an approval, or a changes request
|
||||
|
|
|
|||
|
|
@ -1,7 +1,10 @@
|
|||
# Switching to V2
|
||||
|
||||
## Java distribution
|
||||
|
||||
The major breaking change in V2 is the new mandatory `distribution` input. This field should be specified with one of supported distributions. See [Supported distributions](../README.md#Supported-distributions) for a list of available options.
|
||||
Use the `zulu` keyword if you would like to continue using the same distribution as in V1.
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- uses: actions/checkout@v2
|
||||
|
|
@ -16,7 +19,9 @@ steps:
|
|||
**General recommendation** — configure CI with the same distribution that is used on your local dev machine.
|
||||
|
||||
## Installing custom Java distribution from local file
|
||||
|
||||
Since the `distribution` input is required in V2, you should specify it using `jdkfile` to continue installing Java from a local file on the runner
|
||||
|
||||
```yaml
|
||||
steps:
|
||||
- run: |
|
||||
|
|
@ -31,5 +36,6 @@ steps:
|
|||
```
|
||||
|
||||
## Dropping legacy Java version syntax 1.x
|
||||
|
||||
V1 supported legacy Java syntax such as `1.8` (same as `8`) and `1.8.0.212` (same as `8.0.212`).
|
||||
V2 dropped support for legacy syntax so workflows should be updated accordingly.
|
||||
|
|
|
|||
Loading…
Reference in a new issue