diff --git a/website/docs/docker.md b/website/docs/docker.md index bcbaaacb635317545e1c030d11e6355b2ca94009..5eb574d364bacf6dfb20fea564cebc2382463619 100644 --- a/website/docs/docker.md +++ b/website/docs/docker.md @@ -11,6 +11,7 @@ Renovate supports upgrading dependencies in various types of Docker definition f - Docker Compose files - CircleCI config files - Kubernetes manifests +- Ansible configuration iles ## How It Works @@ -22,7 +23,7 @@ Renovate supports upgrading dependencies in various types of Docker definition f Pinning your docker images to an exact digest is recommended for reasons of **immutability**. In short: so every time you `pull`, you get the same content. -If your experience with dependency versioning comes from a place like javascript/npm, you might be used to knowing that exact versions are immutable, e.g. if you specify a version like `2.0.1` then you and your colleagues will always get the exact same "code". What you may not expect is that Docker's tags are not immutable versions even if they look like a version. e.g. you probably expect that `node:8` and `node:8.9` will change over time, but you might incorrectly assume that `node:8.9.0` would never change. Although it probably _shouldn't_, the reality is that it _can_. +If your experience with dependency versioning comes from a place like javascript/npm, you might be used to exact versions being immutable, e.g. if you specify a version like `2.0.1` then you and your colleagues will always get the exact same "code". What you may not expect is that Docker's tags are not immutable versions even if they look like a version. e.g. you probably expect that `node:8` and `node:8.9` will change over time, but you might incorrectly assume that `node:8.9.0` would never change. Although it probably _shouldn't_, the reality is that any Docker image tag _can_ change content, and potentially break. Using a docker digest as the image's primary identifier instead of docker tag will achieve immutability but as a human it's quite inconvenient to deal with strings like `FROM node@sha256:552348163f074034ae75643c01e0ba301af936a898d778bb4fc16062917d0430`. The good news is that, as a human you no longer need to manually update such digests once you have Renovate on the job. @@ -38,7 +39,7 @@ Instead, you will now receive these updates via Pull Requests, or perhaps commit ## Version Upgrading -Renovate also supports _upgrading_ versions in Docker tags, e.g. from `node:8.9.0` to `node:8.9.1`. If your tags looks like a version, Renovate will upgrade it like a version. +Renovate also supports _upgrading_ versions in Docker tags, e.g. from `node:8.9.0` to `node:8.9.1` or `node:8.9` to `node:8.10`. If your tags looks like a version, Renovate will upgrade it like a version. Thanks to this, you may wish to change the way you tag your image dependencies to be more specific, e.g. change from `node:8` to `node:8.9.1` so that every Renovate PR will be more human friendly, e.g. you can know that you are getting a PR because `node` upgraded from `8.9.1` to `8.9.2` and not because `8.9.1` somehow changed. diff --git a/website/docs/java.md b/website/docs/java.md index 8493515fa8cc09f4def696916ae798c658edc81e..50bff064e751300472d9903ca1fbc51b76a911da 100644 --- a/website/docs/java.md +++ b/website/docs/java.md @@ -5,18 +5,17 @@ description: Java versions support in Renovate # Java Versions -Renovate can update the version used in gradle projects. This includes libraries and plugins. +Renovate can update the version used in Gradle projects. This includes libraries and plugins. It detects versions specified as string `'group:artifact:version'` and as a map `(group:groupName, name:ArtifactName, version:Version)` ## File Support -Renovate can update build.gradle files in the root of the repository and any .gradle file inside any subdirectory as -multi-project configurations. +Renovate can update `build.gradle` files in the root of the repository and any `*.gradle` file inside any subdirectory as multi-project configurations. Renovate does not support: -- Projects without a build.gradle file in the root of the repository. +- Projects without a `build.gradle` file in the root of the repository. - Android projects that requires extra configuration to run. (e.g. setting the android SDK) ## How It Works @@ -27,3 +26,9 @@ replaces the version. It automatically configures [gradle-versions-plugin](https://github.com/ben-manes/gradle-versions-plugin) so you don't need to have it configured as a dependency. + +## Future Work + +Gradle support is currently being rewritten to be compatible with Renovate's other package managers, and no longer require the use of `gradle-versions-plugin`. With this will come Android support as well. + +Maven support is also in development and anticipated to be ready soon. diff --git a/website/docs/javascript.md b/website/docs/javascript.md index 952ae5f0afe9fd72039fafe6372658e75fd2ef66..4d7d23294403f9dc4701b77f272496c49bd89775 100644 --- a/website/docs/javascript.md +++ b/website/docs/javascript.md @@ -6,3 +6,5 @@ description: JavaScript (npm/yarn) Package Manager Support in Renovate # JavaScript Renovate supports upgrading JavaScript dependencies specified in `package.json` files. + +`npm`, `yarn`, and `pnpm` are all supported. diff --git a/website/docs/node.md b/website/docs/node.md index 587958947b560c948a984f2fe9f727963a7d49e8..d37bad2ac97e64a26e2e37b7b0882ac5a9f8d0c1 100644 --- a/website/docs/node.md +++ b/website/docs/node.md @@ -34,11 +34,11 @@ Renovate supports a [`supportPolicy`](configuration-options/#supportpolicy) opti | supportPolicy | versions | description | | ------------- | -------- | --------------------------------------------------------- | -| lts | 4,6,8 | All releases classified as LTS, including in maintenance | -| active | 6,8,9 | All releases classified as active and not maintenance | -| current | 9 | The latest Node.js classified as "current" | -| lts_active | 6,8 | All releases classified as Active LTS and not maintenance | -| lts_latest | 8 | The latest LTS release | +| lts | 6,8,10 | All releases classified as LTS, including in maintenance | +| active | 8,10,11 | All releases classified as active and not maintenance | +| current | 11 | The latest Node.js classified as "current" | +| lts_active | 8,10 | All releases classified as Active LTS and not maintenance | +| lts_latest | 10 | The latest LTS release | The version numbers associated with each support policy will be updated as new versions of Node.js are released, moved to LTS or maintenance, etc. diff --git a/website/docs/php.md b/website/docs/php.md new file mode 100644 index 0000000000000000000000000000000000000000..b0e38031ebc9c578251a37d49d38272bb01a764a --- /dev/null +++ b/website/docs/php.md @@ -0,0 +1,20 @@ +--- +title: PHP Composer Support +description: PHP Composer support in Renovate +--- + +# Automated Dependency Updates for PHP Composer Dependencies + +Renovate supports upgrading dependencies in PHP's `composer.json` files and their accompanying `composer.lock` lock files. + +## How It Works + +1. Renovate will search each repository for any `composer.json` files. +2. Existing dependencies will be extracted from the relevant sections of the JSON +3. Renovate will resolve the dependency on Packagist or elsewhere if configured, and filter for semver versions +4. A PR will be created with `composer.json` and `composer.lock` updated in the same commit +5. If the source repository has either a "changelog" file or uses GitHub releases, then Release Notes for each version will be embedded in the generated PR. + +## Enabling + +Either install the [Renovate App](https://github.com/apps/renovate) on GitHub, or check out [Renovate OSS](https://github.com/renovatebot/renovate) or [Renovate Pro](https://renovatebot.com/pro) for self-hosted options.