diff --git a/.editorconfig b/.editorconfig index 7d2edde437ad4e..a34a3c225ae9c2 100644 --- a/.editorconfig +++ b/.editorconfig @@ -14,3 +14,6 @@ indent_style = tab [*.{yaml,yml,conf}] indent_size = 2 + +[*.md] +indent_size = 4 diff --git a/.github/contributing.md b/.github/contributing.md index 20bdc16f0416ae..72e756d5c6123e 100644 --- a/.github/contributing.md +++ b/.github/contributing.md @@ -37,34 +37,34 @@ Pull Requests can only be merged once all status checks are green, which means ` Use these commands to help run your tests: -- To run a single test folder, specify the path +- To run a single test folder, specify the path - ```bash - pnpm jest platform/gitlab - ``` + ```bash + pnpm jest platform/gitlab + ``` -- To run against a single test file, specify down to the filename (suffix is not necessary) +- To run against a single test file, specify down to the filename (suffix is not necessary) - ```bash - pnpm jest platform/gitlab/index - ``` + ```bash + pnpm jest platform/gitlab/index + ``` -- To run a single test batch, the `-t` value must be part of the `describe` value of the test batch +- To run a single test batch, the `-t` value must be part of the `describe` value of the test batch - ```bash - pnpm jest platform/gitlab/index -t "getJsonFile" - ``` + ```bash + pnpm jest platform/gitlab/index -t "getJsonFile" + ``` -- To run a single test, the `-t` value must be part of the `it` value of the test batch +- To run a single test, the `-t` value must be part of the `it` value of the test batch - ```bash - pnpm jest platform/gitlab/index -t "returns file content from given repo" - ``` + ```bash + pnpm jest platform/gitlab/index -t "returns file content from given repo" + ``` And some options: -- `--verbose=false` to avoid the test list -- `--collectCoverage=false` to avoid collecting coverage, faster for the part you need the test to pass +- `--verbose=false` to avoid the test list +- `--collectCoverage=false` to avoid collecting coverage, faster for the part you need the test to pass ## Do not force push to your pull request branch @@ -78,8 +78,8 @@ This is the "Update with merge commit" option in the dropdown. Force pushing a PR, or using the "Update with rebase" button is OK when you: -- make large changes on a PR which require a full review anyway -- bring the branch up-to-date with the target branch and incorporating the changes is more work than to create a new PR +- make large changes on a PR which require a full review anyway +- bring the branch up-to-date with the target branch and incorporating the changes is more work than to create a new PR ## Apply maintainer provided review suggestions diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md index 4bb1e5a1f26ac2..982d682f85b21e 100644 --- a/.github/pull_request_template.md +++ b/.github/pull_request_template.md @@ -14,17 +14,17 @@ ## Documentation (please check one with an [x]) -- [ ] I have updated the documentation, or -- [ ] No documentation update is required +- [ ] I have updated the documentation, or +- [ ] No documentation update is required ## How I've tested my work (please select one) I have verified these changes via: -- [ ] Code inspection only, or -- [ ] Newly added/modified unit tests, or -- [ ] No unit tests but ran on a real repository, or -- [ ] Both unit tests + ran on a real repository +- [ ] Code inspection only, or +- [ ] Newly added/modified unit tests, or +- [ ] No unit tests but ran on a real repository, or +- [ ] Both unit tests + ran on a real repository diff --git a/CODE_OF_CONDUCT.md b/CODE_OF_CONDUCT.md index 4be7f647231a35..f7f87418de8969 100644 --- a/CODE_OF_CONDUCT.md +++ b/CODE_OF_CONDUCT.md @@ -2,10 +2,10 @@ To help us deliver great features and support the Renovate Open Source project we ask that you: -- are polite -- pay attention to details -- keep in mind that most maintainers are volunteers -- are respectful of the time and effort of the maintainers +- are polite +- pay attention to details +- keep in mind that most maintainers are volunteers +- are respectful of the time and effort of the maintainers ## Our priorities @@ -43,9 +43,9 @@ Remember, most of the support provided by our team, including the Mend.io staff, We quickly deal with rudeness in the community with: -- automated comments -- temporary blocks -- permanent bans +- automated comments +- temporary blocks +- permanent bans If you keep breaking the rules or challenge our guidelines openly, you will be blocked. For example: if you keep spamming the maintainers with `@mentions` or challenge our rules openly, you will be blocked. @@ -59,11 +59,11 @@ Simply put: we block and unblock swiftly, what matters is how you follow the rul Renovate's core contributors and maintainers focus on work that: -- Helps a lot of users, or -- Fixes regressions (errors introduced by recent changes), or -- Is required by a customer of Mend.io, or -- Is sponsored by third parties after independent validation, or -- We personally need or want to implement +- Helps a lot of users, or +- Fixes regressions (errors introduced by recent changes), or +- Is required by a customer of Mend.io, or +- Is sponsored by third parties after independent validation, or +- We personally need or want to implement You may be disappointed when we focus on other work ahead of your feature or bug, but you should understand and accept this. diff --git a/docs/development/adding-a-package-manager.md b/docs/development/adding-a-package-manager.md index 75ee581750e8b5..db6049e5476362 100644 --- a/docs/development/adding-a-package-manager.md +++ b/docs/development/adding-a-package-manager.md @@ -32,8 +32,8 @@ The manager's `index.ts` file supports the following values or functions: Use this function to allow version bumps of updated packages. For example: -- to increase the version of a Maven module if a package has been updated -- to bump the Helm chart version, if a subchart version has been updated +- to increase the version of a Maven module if a package has been updated +- to bump the Helm chart version, if a subchart version has been updated ### `extractPackageFile(content, packageFile, config)` (async, semi-mandatory) @@ -41,10 +41,10 @@ This function is mandatory, unless you use `extractAllPackageFiles` instead. It takes as arguments the file's content and optionally the file's full file pathname and config. The function returns an array of detected or extracted dependencies, including the: -- dependency name -- dependency type (dependencies, devDependencies, etc) -- currentValue -- versioning used (like SemVer, PEP 440) +- dependency name +- dependency type (dependencies, devDependencies, etc) +- currentValue +- versioning used (like SemVer, PEP 440) The `extractPackageFile` function doesn't need to fully _understand_ the file or syntax that it gets. It needs to understand enough to extract a correct list of dependencies. @@ -95,15 +95,15 @@ To _directly_ update dependencies in lock files: use `updateLockedDependency` in `updateArtifacts` gets triggered: -- after a dependency update (for a package file), or -- during `lockfileMaintenance` +- after a dependency update (for a package file), or +- during `lockfileMaintenance` ### `updateDependency` (optional) Use `updateDependency` if _both_ conditions apply: -- the manager can't be updated to use the standard replacing mechanism -- a custom replacement has to be provided +- the manager can't be updated to use the standard replacing mechanism +- a custom replacement has to be provided ### `updateLockedDependency` (optional) diff --git a/docs/development/best-practices.md b/docs/development/best-practices.md index 3b1e3f265e085a..cf3dacede0a40e 100644 --- a/docs/development/best-practices.md +++ b/docs/development/best-practices.md @@ -11,10 +11,10 @@ Finally, describe the changes in the branch in a few words. Some good branch names: -- `feat/13732-cacache-cleanup` -- `fix/15431-gitea-automerge-strategy` -- `refactor/jest-reset-mocks` -- `docs/rewrite-packageRules-section` +- `feat/13732-cacache-cleanup` +- `fix/15431-gitea-automerge-strategy` +- `refactor/jest-reset-mocks` +- `docs/rewrite-packageRules-section` Avoid branch names like `patch-1`. @@ -25,15 +25,15 @@ Read the [GitHub Docs, renaming a branch](https://docs.github.com/en/repositorie ## General -- Prefer full function declarations for readability and better stack traces, so avoid `const func = ():void => {}` -- Prefer `interface` over `type` for TypeScript type declarations -- Avoid [Enums](https://github.com/renovatebot/renovate/issues/13743), use unions or [immutable objects](https://github.com/renovatebot/renovate/blob/5043379847818ac1fa71ff69c098451975e95710/lib/modules/versioning/pep440/range.ts#L8-L20) instead -- Always add unit tests for full code coverage - - Only use `istanbul` comments for unreachable code coverage that is needed for `codecov` completion - - Use descriptive `istanbul` comments -- Avoid cast or prefer `x as T` instead of `x` cast -- Prefer `satisfies` operator over `as`, read the [TypeScript release notes for `satisfies` operator](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html#the-satisfies-operator) to learn more -- Avoid `Boolean` instead use `is` functions from `@sindresorhus/is` package, for example: `is.string` +- Prefer full function declarations for readability and better stack traces, so avoid `const func = ():void => {}` +- Prefer `interface` over `type` for TypeScript type declarations +- Avoid [Enums](https://github.com/renovatebot/renovate/issues/13743), use unions or [immutable objects](https://github.com/renovatebot/renovate/blob/5043379847818ac1fa71ff69c098451975e95710/lib/modules/versioning/pep440/range.ts#L8-L20) instead +- Always add unit tests for full code coverage + - Only use `istanbul` comments for unreachable code coverage that is needed for `codecov` completion + - Use descriptive `istanbul` comments +- Avoid cast or prefer `x as T` instead of `x` cast +- Prefer `satisfies` operator over `as`, read the [TypeScript release notes for `satisfies` operator](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-4-9.html#the-satisfies-operator) to learn more +- Avoid `Boolean` instead use `is` functions from `@sindresorhus/is` package, for example: `is.string` ```ts // istanbul ignore next: can never happen @@ -41,11 +41,11 @@ Read the [GitHub Docs, renaming a branch](https://docs.github.com/en/repositorie ### Functions -- Use `function foo(){...}` to declare named functions -- Use function declaration instead of assigning function expression into local variables (`const f = function(){...}`) (TypeScript already prevents rebinding functions) - - Exception: if the function accesses the outer scope's `this` then use arrow functions assigned to variables instead of function declarations -- Regular functions _should not_ access `this`, but arrow functions and methods may access `this` -- Only use nested functions when the [lexical scope](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures) is used +- Use `function foo(){...}` to declare named functions +- Use function declaration instead of assigning function expression into local variables (`const f = function(){...}`) (TypeScript already prevents rebinding functions) + - Exception: if the function accesses the outer scope's `this` then use arrow functions assigned to variables instead of function declarations +- Regular functions _should not_ access `this`, but arrow functions and methods may access `this` +- Only use nested functions when the [lexical scope](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures) is used #### Use arrow functions in expressions @@ -59,7 +59,7 @@ Use: ```ts bar(() => { - this.doSomething(); + this.doSomething(); }); ``` @@ -116,15 +116,15 @@ Nested code logic is hard to read and prone to logic mistakes. ```ts function foo(str: string): boolean { - let result = false; - if (condition(str)) { - const x = extractData(str); - if (x) { - // do something - result = true; + let result = false; + if (condition(str)) { + const x = extractData(str); + if (x) { + // do something + result = true; + } } - } - return result; + return result; } ``` @@ -132,17 +132,17 @@ Simplified code: ```ts function foo(str: string): boolean { - if (!condition(str)) { - return false; - } + if (!condition(str)) { + return false; + } - const x = extractData(str); - if (!x) { - return false; - } + const x = extractData(str); + if (!x) { + return false; + } - // do something - return true; + // do something + return true; } ``` @@ -203,9 +203,9 @@ Array.from({ length: 5 }).fill(0); Use `for ( ... of ...)` loops instead of `[Array|Set|Map].prototype.forEach` and `for ( ... in ...)`. -- Using `for ( ... in ...)` for objects is error-prone. It will include enumerable properties from the prototype chain -- Using `for ( ... in ...)` to iterate over arrays, will counterintuitively return the array's indices -- Avoid `[Array|Set|Map].prototype.forEach`. It makes code harder to debug and defeats some useful compiler checks like reachability +- Using `for ( ... in ...)` for objects is error-prone. It will include enumerable properties from the prototype chain +- Using `for ( ... in ...)` to iterate over arrays, will counterintuitively return the array's indices +- Avoid `[Array|Set|Map].prototype.forEach`. It makes code harder to debug and defeats some useful compiler checks like reachability Only use `Array.prototype.map()` when the return value is used, otherwise use `for ( ... of ...)`. @@ -270,30 +270,30 @@ Use `UTC` to be time zone independent. ```ts if (end) { - const now = DateTime.now().toUTC(); - const eol = DateTime.fromISO(end, { zone: 'utc' }); - return eol < now; + const now = DateTime.now().toUTC(); + const eol = DateTime.fromISO(end, { zone: 'utc' }); + return eol < now; } ``` ## Unit testing -- Separate the _Arrange_, _Act_ and _Assert_ phases with newlines -- Use `it.each` rather than `test.each` -- Prefer [Tagged Template Literal](https://jestjs.io/docs/api#2-testeachtablename-fn-timeout) style for `it.each`, Prettier will help with formatting - - See [Example](https://github.com/renovatebot/renovate/blob/768e178419437a98f5ce4996bafd23f169e530b4/lib/modules/platform/util.spec.ts#L8-L18) -- Mock Date/Time when testing a Date/Time dependent module - - For `Luxon` mocking see [Example](https://github.com/renovatebot/renovate/blob/5043379847818ac1fa71ff69c098451975e95710/lib/modules/versioning/distro.spec.ts#L7-L10) -- Prefer `jest.spyOn` for mocking single functions, or mock entire modules - - Avoid overwriting functions, for example: (`func = jest.fn();`) -- Prefer `toEqual` -- Use `toMatchObject` for huge objects when only parts need to be tested -- Avoid `toMatchSnapshot`, only use it for: - - huge strings like the Renovate PR body text - - huge complex objects where you only need to test parts -- Avoid exporting functions purely for the purpose of testing unless you really need to -- Avoid cast or prefer `x as T` instead of `x` cast - - Use `partial()` from `test/util` if only a partial object is required +- Separate the _Arrange_, _Act_ and _Assert_ phases with newlines +- Use `it.each` rather than `test.each` +- Prefer [Tagged Template Literal](https://jestjs.io/docs/api#2-testeachtablename-fn-timeout) style for `it.each`, Prettier will help with formatting + - See [Example](https://github.com/renovatebot/renovate/blob/768e178419437a98f5ce4996bafd23f169e530b4/lib/modules/platform/util.spec.ts#L8-L18) +- Mock Date/Time when testing a Date/Time dependent module + - For `Luxon` mocking see [Example](https://github.com/renovatebot/renovate/blob/5043379847818ac1fa71ff69c098451975e95710/lib/modules/versioning/distro.spec.ts#L7-L10) +- Prefer `jest.spyOn` for mocking single functions, or mock entire modules + - Avoid overwriting functions, for example: (`func = jest.fn();`) +- Prefer `toEqual` +- Use `toMatchObject` for huge objects when only parts need to be tested +- Avoid `toMatchSnapshot`, only use it for: + - huge strings like the Renovate PR body text + - huge complex objects where you only need to test parts +- Avoid exporting functions purely for the purpose of testing unless you really need to +- Avoid cast or prefer `x as T` instead of `x` cast + - Use `partial()` from `test/util` if only a partial object is required ## Fixtures @@ -314,16 +314,16 @@ Declare types and function prototypes with [JSDoc](https://jsdoc.app/index.html) ## Classes -- Use [Typescript getter setters (Accessors) when needed](https://google.github.io/styleguide/tsguide.html#properties-used-outside-of-class-lexical-scope). - The getter must be a `pure function` i.e. - - The function return values are identical for identical arguments - - The function has no side effects +- Use [Typescript getter setters (Accessors) when needed](https://google.github.io/styleguide/tsguide.html#properties-used-outside-of-class-lexical-scope). + The getter must be a `pure function` i.e. + - The function return values are identical for identical arguments + - The function has no side effects [Source](https://en.wikipedia.org/wiki/Pure_function) -- Omit constructors when defining Static classes -- [No `#private` fields](https://google.github.io/styleguide/tsguide.html#private-fields), use TypeScript's visibility annotations instead -- Avoid underscore suffixes or prefixes like `_prop`, instead use [whole words](https://google.github.io/styleguide/tsguide.html#properties-used-outside-of-class-lexical-scope) as the suffix or prefix like `internalProp` +- Omit constructors when defining Static classes +- [No `#private` fields](https://google.github.io/styleguide/tsguide.html#private-fields), use TypeScript's visibility annotations instead +- Avoid underscore suffixes or prefixes like `_prop`, instead use [whole words](https://google.github.io/styleguide/tsguide.html#properties-used-outside-of-class-lexical-scope) as the suffix or prefix like `internalProp` ## regex diff --git a/docs/development/branches-commits.md b/docs/development/branches-commits.md index 71642988b82ffa..d295966dc7fb51 100644 --- a/docs/development/branches-commits.md +++ b/docs/development/branches-commits.md @@ -5,8 +5,8 @@ Renovate can, and should, update multiple files in the same branch/PR. For example: -- update the `package.json` and the `yarn.lock` file -- update multiple package files in a monorepo, including different package managers +- update the `package.json` and the `yarn.lock` file +- update multiple package files in a monorepo, including different package managers ## One commit per branch diff --git a/docs/development/bug-handling.md b/docs/development/bug-handling.md index 601d3a0d55f148..fe9beee109ee0c 100644 --- a/docs/development/bug-handling.md +++ b/docs/development/bug-handling.md @@ -11,8 +11,8 @@ Maintainers may close bug reports that lack the extra information, for example w We only create issues in this repository when we: -- consider them to be actionable -- are in a state where someone could work on it +- consider them to be actionable +- are in a state where someone could work on it We often need a minimal reproduction or logs, or even _both_, to pinpoint the exact problem. Because we need enough information for a actionable bug report, we may close Discussions that lack the needed info, even if it's highly likely the behavior is buggy. @@ -54,8 +54,8 @@ We are not interested in debating you, we prefer to spend our time helping users We are open to improve our approach to bugs, or this document, in good spirit. Please do _not_ post comments like these: -- "How dare you block users from creating Issues?!" -- "If the behavior was unexpected to me then that means it's a bug." +- "How dare you block users from creating Issues?!" +- "If the behavior was unexpected to me then that means it's a bug." Users who want to make our life difficult as maintainers will be blocked. Read our [Code of Conduct](https://github.com/renovatebot/renovate/blob/main/CODE_OF_CONDUCT.md) to learn more. diff --git a/docs/development/bump-node-major.md b/docs/development/bump-node-major.md index 19f30d69769931..f465f7271b0521 100644 --- a/docs/development/bump-node-major.md +++ b/docs/development/bump-node-major.md @@ -2,13 +2,13 @@ ## Add new NodeJS version -- Add new version via `package.json>engines>node` -- Update the node version in the [local-development](./local-development.md) docs -- Update the node version in the GitHub Actions workflow files +- Add new version via `package.json>engines>node` +- Update the node version in the [local-development](./local-development.md) docs +- Update the node version in the GitHub Actions workflow files ## Remove old NodeJS version -- Update `package.json>engines>node` -- Mark PR as `BREAKING` by: - - Adding the label `breaking` to the PR - - Putting the text `BREAKING CHANGE: ` in the PR content footer +- Update `package.json>engines>node` +- Mark PR as `BREAKING` by: + - Adding the label `breaking` to the PR + - Putting the text `BREAKING CHANGE: ` in the PR content footer diff --git a/docs/development/configuration.md b/docs/development/configuration.md index a238d412964bea..219c3f2e5b3bf5 100644 --- a/docs/development/configuration.md +++ b/docs/development/configuration.md @@ -4,9 +4,9 @@ Renovate global config can be defined via any of these methods: -- Configuration file -- Environment variables -- CLI parameters +- Configuration file +- Environment variables +- CLI parameters The above are listed in **_reverse order_** of preference. e.g. CLI values will override environment values if they conflict. @@ -33,10 +33,10 @@ e.g. apply one set of labels for `backend/package.json` and a different set of l ```javascript module.exports = { - npmrc: '//registry.npmjs.org/:_authToken=abc123', - baseDir: '/tmp/renovate', - forkProcessing: 'enabled', - gradle: { enabled: false }, + npmrc: '//registry.npmjs.org/:_authToken=abc123', + baseDir: '/tmp/renovate', + forkProcessing: 'enabled', + gradle: { enabled: false }, }; ``` @@ -61,9 +61,9 @@ If you add configuration options to your `package.json` then these will override ```json { - "renovate": { - "labels": ["upgrade", "bot"] - } + "renovate": { + "labels": ["upgrade", "bot"] + } } ``` diff --git a/docs/development/design-decisions.md b/docs/development/design-decisions.md index 1e420b232ed7e8..402f3f91c4d7aa 100644 --- a/docs/development/design-decisions.md +++ b/docs/development/design-decisions.md @@ -21,8 +21,8 @@ Due to this design, it is possible to stop the script at any time without riskin The script processes repositories and branches within them synchronously. This has the following benefits: -- Greatly reduces the chance of hitting simultaneous API rate limits -- Simplifies logging +- Greatly reduces the chance of hitting simultaneous API rate limits +- Simplifies logging ## Cascading Configuration @@ -61,9 +61,9 @@ For example, if the current example is 1.6.0 and upgrades to 1.7.0 and 2.0.0 exi Our reasons for separating minor and major PRs: -- It's often the case that projects can't upgrade major dependency versions immediately -- It's also often the case that previous major versions continue receiving Minor or Patch updates -- Projects should get Minor and Patch updates for their current Major release even if a new Major release exists +- It's often the case that projects can't upgrade major dependency versions immediately +- It's also often the case that previous major versions continue receiving Minor or Patch updates +- Projects should get Minor and Patch updates for their current Major release even if a new Major release exists This behavior can be overridden via the config option `separateMajorMinor`. @@ -73,8 +73,8 @@ Branches have names like `renovate/webpack-1.x` instead of `renovate/webpack-1.2 We do this because: -- Branches often get updates (e.g. new patches) before they're merged -- Naming the branch like `1.x` means its name still makes sense if a `1.2.1` release happens +- Branches often get updates (e.g. new patches) before they're merged +- Naming the branch like `1.x` means its name still makes sense if a `1.2.1` release happens Note: You can configure the branch names by using the string template `branchName` and/or its sub-templates `branchPrefix` and `branchTopic`. @@ -107,6 +107,6 @@ Alternatively, consider using a Configuration File. Renovate uses the following convention for log levels: -- logger.error should only be used for problems that are likely to be a Renovate bug or require Renovate improvements. These are the types of errors that Renovate administrators should be alerted to immediately -- logger.warn should be used for problems that might be a Renovate problem so should be checked periodically in batches -- For _user_ problems (e.g. configuration errors), these should not warn or error on the server side and instead use logger.info +- logger.error should only be used for problems that are likely to be a Renovate bug or require Renovate improvements. These are the types of errors that Renovate administrators should be alerted to immediately +- logger.warn should be used for problems that might be a Renovate problem so should be checked periodically in batches +- For _user_ problems (e.g. configuration errors), these should not warn or error on the server side and instead use logger.info diff --git a/docs/development/help-us-help-you.md b/docs/development/help-us-help-you.md index 9aaea3862a838d..dc672289defa43 100644 --- a/docs/development/help-us-help-you.md +++ b/docs/development/help-us-help-you.md @@ -36,9 +36,9 @@ In other words, if someone's taking the time to help you, "don't be lazy". If someone's helped you get some functionality working, or successfully troubleshoot a problem, please try to do this: -- Let us know which advice fixed your problem, if it's unclear -- If you're feeling polite, thank the person who helped you -- If you're feeling helpful, submit a Pull Request to improve the relevant documentation +- Let us know which advice fixed your problem, if it's unclear +- If you're feeling polite, thank the person who helped you +- If you're feeling helpful, submit a Pull Request to improve the relevant documentation Please don't ruin a successful result with a criticism or complaint about the quality of the documentation. If you feel frustrated because better documentation would have prevented you from making the mistake in the first place then improve it with a PR for those who come after you! diff --git a/docs/development/issue-labeling.md b/docs/development/issue-labeling.md index e294b2745eddf0..443a440b8ca7d4 100644 --- a/docs/development/issue-labeling.md +++ b/docs/development/issue-labeling.md @@ -5,11 +5,11 @@ Any repository collaborator can apply labels according to the below guidelines. The general idea is that we have: -- manager (`manager:`) -- versioning (`versioning:`) -- datasource (`datasource:`) -- platform (`platform:`) -- core functionality (`core:`) +- manager (`manager:`) +- versioning (`versioning:`) +- datasource (`datasource:`) +- platform (`platform:`) +- core functionality (`core:`) The majority of issues should have at least one of those labels. These labels should also map approximately to our Conventional Commit scopes. @@ -18,10 +18,10 @@ These labels should also map approximately to our Conventional Commit scopes. You should know about platforms, package managers, datasources and versioning to label issues effectively. -- To learn about platforms, read the [Renovate docs on Platforms](https://docs.renovatebot.com/modules/platform/) -- To learn about managers, read the [Renovate docs on Managers](https://docs.renovatebot.com/modules/manager/) -- To learn about datasources, read the [Renovate docs on Datasources](https://docs.renovatebot.com/modules/datasource/) -- To learn more about versioning, read the [Renovate docs on Versioning](https://docs.renovatebot.com/modules/versioning/) +- To learn about platforms, read the [Renovate docs on Platforms](https://docs.renovatebot.com/modules/platform/) +- To learn about managers, read the [Renovate docs on Managers](https://docs.renovatebot.com/modules/manager/) +- To learn about datasources, read the [Renovate docs on Datasources](https://docs.renovatebot.com/modules/datasource/) +- To learn more about versioning, read the [Renovate docs on Versioning](https://docs.renovatebot.com/modules/versioning/) Most issues should have a label relating to either a platform, manager, datasource, versioning or worker topic. diff --git a/docs/development/local-development.md b/docs/development/local-development.md index c175899b9fc0e7..6e594a2bfb4a56 100644 --- a/docs/development/local-development.md +++ b/docs/development/local-development.md @@ -10,10 +10,10 @@ For example, if you think anything is unclear, or you think something needs to b You need the following dependencies for local development: -- Git `>=2.45.1` -- Node.js `^20.15.1` -- pnpm `^9.0.0` (use corepack) -- C++ compiler +- Git `>=2.45.1` +- Node.js `^20.15.1` +- pnpm `^9.0.0` (use corepack) +- C++ compiler We recommend you use the version of Node.js defined in the repository's `.nvmrc`. @@ -37,26 +37,26 @@ To enter a development shell with the necessary packages, run `nix-shell --packa Follow these steps to set up your development environment on Windows 10. If you already installed a part, skip the corresponding step. -- Install [Git](https://git-scm.com/downloads). Make sure you've [configured your username and email](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup) -- Install [Node.js LTS](https://nodejs.org/en/download/) -- In an Administrator PowerShell prompt, run `npm install -global npm` and then `npm --debug install --global windows-build-tools` -- Enable corepack with: `corepack enable` +- Install [Git](https://git-scm.com/downloads). Make sure you've [configured your username and email](https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup) +- Install [Node.js LTS](https://nodejs.org/en/download/) +- In an Administrator PowerShell prompt, run `npm install -global npm` and then `npm --debug install --global windows-build-tools` +- Enable corepack with: `corepack enable` - You can see what versions you're using like this: + You can see what versions you're using like this: - ```powershell - PS C:\Windows\system32> git --version - PS C:\Windows\system32> node --version - PS C:\Windows\system32> pnpm --version - ``` + ```powershell + PS C:\Windows\system32> git --version + PS C:\Windows\system32> node --version + PS C:\Windows\system32> pnpm --version + ``` #### VS Code Dev Containers If you are using [VS Code](https://code.visualstudio.com/) you can skip installing [the prerequisites](#prerequisites) and work in a [development container](https://code.visualstudio.com/docs/devcontainers/containers) instead. -- Install the [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) and [check its system requirements](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers#system-requirements) -- Open the repository folder in VS Code -- Choose "Reopen in Container" via the command palette or the small button in the lower left corner +- Install the [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers) and [check its system requirements](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers#system-requirements) +- Open the repository folder in VS Code +- Choose "Reopen in Container" via the command palette or the small button in the lower left corner The VS Code [integrated terminal](https://code.visualstudio.com/docs/editor/integrated-terminal) is now running in the container and can be used to run more commands. @@ -180,8 +180,8 @@ First of all, never commit to the `main` branch of your fork - always use a "fea Make sure your fork is up-to-date with the Renovate `main` branch, check this each time before you create a new branch. To do this, see these GitHub guides: -- [Configuring a remote for a fork](https://help.github.com/articles/configuring-a-remote-for-a-fork/) -- [Syncing a fork](https://help.github.com/articles/syncing-a-fork/) +- [Configuring a remote for a fork](https://help.github.com/articles/configuring-a-remote-for-a-fork/) +- [Syncing a fork](https://help.github.com/articles/syncing-a-fork/) ## Tips and tricks @@ -229,8 +229,8 @@ Here's an example: ```javascript module.exports = { - token: 'xxxxxxxx', - repositories: ['r4harry/testrepo1'], + token: 'xxxxxxxx', + repositories: ['r4harry/testrepo1'], }; ``` diff --git a/docs/development/minimal-reproductions.md b/docs/development/minimal-reproductions.md index d4646dc18b2569..533013ec157d29 100644 --- a/docs/development/minimal-reproductions.md +++ b/docs/development/minimal-reproductions.md @@ -10,10 +10,10 @@ A minimal reproduction is a repository with the _least_ amount of code and confi The [`renovate-reproductions/12260` repository](https://github.com/renovate-reproductions/12260) shows a perfect reproduction, because it: -- Only has the files/config needed to trigger the bug -- Explains the current behavior and the expected behavior in the `readme.md` -- Links to the Renovate Issue, or Discussion in the `readme.md` -- Uses headings to organize information +- Only has the files/config needed to trigger the bug +- Explains the current behavior and the expected behavior in the `readme.md` +- Links to the Renovate Issue, or Discussion in the `readme.md` +- Uses headings to organize information ## Creating a minimal reproduction @@ -40,9 +40,9 @@ _Always_ follow these steps: 1. Reduce your Renovate config to a minimum 1. Remove private or secret information 1. Create a `readme.md` file (or edit the template `readme.md`) and: - - Explain the _Current behavior_ and _Expected behavior_ - - Link to the Renovate Issue or Discussion - - Use headings to organize the information + - Explain the _Current behavior_ and _Expected behavior_ + - Link to the Renovate Issue or Discussion + - Use headings to organize the information 1. Set the repository visibility to `public` 1. Give us the link to the repository @@ -63,14 +63,14 @@ Then set a high `minimumReleaseAge` for that dependency, for example: ```json { - "extends": ["config:best-practices"], - "packageRules": [ - { - "description": "Force lots of pending updates for the Prettier package", - "matchPackageNames": ["prettier"], - "minimumReleaseAge": "365 days" - } - ] + "extends": ["config:best-practices"], + "packageRules": [ + { + "description": "Force lots of pending updates for the Prettier package", + "matchPackageNames": ["prettier"], + "minimumReleaseAge": "365 days" + } + ] } ``` @@ -80,13 +80,13 @@ You'll get a lot of pending updates, which you can see on the Dependency Dashboa A minimal reproduction helps the Renovate developers: -- confirm the problem is with Renovate, and _not_ with your environment, or your configuration settings -- see where the bug or missing feature is -- verify that the new code solves the problem, or correctly adds a feature -- identify the root cause, or narrow down the possible causes -- suggest workarounds for the problem -- find where to look in our code to help you -- step through the code with a debugger +- confirm the problem is with Renovate, and _not_ with your environment, or your configuration settings +- see where the bug or missing feature is +- verify that the new code solves the problem, or correctly adds a feature +- identify the root cause, or narrow down the possible causes +- suggest workarounds for the problem +- find where to look in our code to help you +- step through the code with a debugger ## Why we will not use your production repository to debug @@ -98,9 +98,9 @@ You may think: This is because a production repository often has: -- many dependencies -- many custom rules in the Renovate configuration file -- many files that are not relevant +- many dependencies +- many custom rules in the Renovate configuration file +- many files that are not relevant Lots of "moving parts" makes it hard to debug, as debug break points can trigger hundreds of times. diff --git a/docs/development/new-package-manager-template.md b/docs/development/new-package-manager-template.md index 919f0471ded3dd..b6307f23a305ab 100644 --- a/docs/development/new-package-manager-template.md +++ b/docs/development/new-package-manager-template.md @@ -2,7 +2,7 @@ Did you read our documentation on adding a package manager? -- [ ] I've read the [adding a package manager](adding-a-package-manager.md) documentation. +- [ ] I've read the [adding a package manager](adding-a-package-manager.md) documentation. ## Basics @@ -14,8 +14,8 @@ Did you read our documentation on adding a package manager? ### Does this language have other (competing?) package managers? -- [ ] Yes (give names). -- [ ] No. +- [ ] Yes (give names). +- [ ] No. ### What are the big selling points for this package manager? @@ -29,8 +29,8 @@ Explain how this package manager is different from existing ones. ### Do many users need to extend the [`fileMatch`](../usage/configuration-options.md#filematch) pattern for custom file names? -- [ ] Yes, provide details. -- [ ] No. +- [ ] Yes, provide details. +- [ ] No. ### Is the [`fileMatch`](../usage/configuration-options.md#filematch) pattern going to get many "false hits" for files that have nothing to do with package management? @@ -42,27 +42,27 @@ Explain how this package manager is different from existing ones. The package files should be: -- [ ] Parsed together (in serial). -- [ ] Parsed independently. +- [ ] Parsed together (in serial). +- [ ] Parsed independently. ### Which format/syntax does the package file use? -- [ ] JSON -- [ ] TOML -- [ ] YAML -- [ ] Custom (explain below) +- [ ] JSON +- [ ] TOML +- [ ] YAML +- [ ] Custom (explain below) ### How should we parse the package files? -- [ ] Off the shelf parser. -- [ ] Using regex. -- [ ] Custom-parsed line by line. -- [ ] Other. +- [ ] Off the shelf parser. +- [ ] Using regex. +- [ ] Custom-parsed line by line. +- [ ] Other. ### Does the package file have different "types" of dependencies? -- [ ] Yes, production and development dependencies. -- [ ] No, all dependencies are treated the same. +- [ ] Yes, production and development dependencies. +- [ ] No, all dependencies are treated the same. ### List all the sources/syntaxes of dependencies that can be extracted @@ -74,56 +74,56 @@ The package files should be: ### Does this versioning scheme support range constraints, like `^1.0.0` or `1.x`? -- [ ] Supports range constraints (for example: `^1.0.0` or `1.x`), provide details. -- [ ] No. +- [ ] Supports range constraints (for example: `^1.0.0` or `1.x`), provide details. +- [ ] No. ## Lookup ### Is a new datasource required? -- [ ] Yes, provide details. -- [ ] No. +- [ ] Yes, provide details. +- [ ] No. ### Will users want (or need to) set a custom host or custom registry for Renovate's lookup? -- [ ] Yes, provide details. -- [ ] No. +- [ ] Yes, provide details. +- [ ] No. Where can Renovate find the custom host/registry? -- [ ] No custom host or registry is needed. -- [ ] In the package file(s), provide details. -- [ ] In some other file inside the repository, provide details. -- [ ] User needs to configure Renovate where to find the information, provide details. +- [ ] No custom host or registry is needed. +- [ ] In the package file(s), provide details. +- [ ] In some other file inside the repository, provide details. +- [ ] User needs to configure Renovate where to find the information, provide details. ### Are there any constraints in the package files that Renovate should use in the lookup procedure? -- [ ] Yes, there are constraints on the parent language (for example: supports only Python `v3.x`), provide details. -- [ ] Yes, there are constraints on the parent platform (for example: only supports Linux, Windows, etc.), provide details. -- [ ] Yes, some other kind of constraint, provide details. -- [ ] No constraints. +- [ ] Yes, there are constraints on the parent language (for example: supports only Python `v3.x`), provide details. +- [ ] Yes, there are constraints on the parent platform (for example: only supports Linux, Windows, etc.), provide details. +- [ ] Yes, some other kind of constraint, provide details. +- [ ] No constraints. ### Will users need the ability to configure language or other constraints using Renovate config? -- [ ] Yes, provide details. -- [ ] No. +- [ ] Yes, provide details. +- [ ] No. ## Artifacts ### Does the package manager use a lock file or checksum file? -- [ ] Yes, uses lock file. -- [ ] Yes, uses checksum file. -- [ ] Yes, uses lock file _and_ checksum file. -- [ ] No lock file or checksum. +- [ ] Yes, uses lock file. +- [ ] Yes, uses checksum file. +- [ ] Yes, uses lock file _and_ checksum file. +- [ ] No lock file or checksum. ### Is the locksum or checksum mandatory? -- [ ] Yes, locksum is mandatory. -- [ ] Yes, checksum is mandatory. -- [ ] Yes, lock file _and_ checksum are mandatory. -- [ ] No mandatory locksum or checksum. -- [ ] Package manager does not use locksums or checksums. +- [ ] Yes, locksum is mandatory. +- [ ] Yes, checksum is mandatory. +- [ ] Yes, lock file _and_ checksum are mandatory. +- [ ] No mandatory locksum or checksum. +- [ ] Package manager does not use locksums or checksums. ### If lockfiles or checksums are used: what tool and exact commands should Renovate use to update one (or more) package versions in a dependency file? @@ -131,28 +131,28 @@ Where can Renovate find the custom host/registry? #### Does the package manager use a cache? -- [ ] Yes, provide details. -- [ ] No. +- [ ] Yes, provide details. +- [ ] No. #### If the package manager uses a cache, how can Renovate control the cache? -- [ ] Package manager does not use a cache. -- [ ] Controlled via command line interface, provide details. -- [ ] Controlled via environment variables, provide details. +- [ ] Package manager does not use a cache. +- [ ] Controlled via command line interface, provide details. +- [ ] Controlled via environment variables, provide details. #### Should Renovate keep a cache? -- [ ] Yes, ignore/disable the cache. -- [ ] No. +- [ ] Yes, ignore/disable the cache. +- [ ] No. ### Generating a lockfile from scratch Renovate can perform "lock file maintenance" by getting the package manager to generate a lockfile from scratch. Can the package manager generate a lockfile from scratch? -- [ ] Yes, explain which command Renovate should use to generate the lockfile. -- [ ] No, the package manager does _not_ generate a lockfile from scratch. -- [ ] No, the package manager does not use lockfiles. +- [ ] Yes, explain which command Renovate should use to generate the lockfile. +- [ ] No, the package manager does _not_ generate a lockfile from scratch. +- [ ] No, the package manager does not use lockfiles. ## Other diff --git a/docs/development/remote-development.md b/docs/development/remote-development.md index d3f6c4ca0f3683..5794a8a6b58105 100644 --- a/docs/development/remote-development.md +++ b/docs/development/remote-development.md @@ -18,18 +18,18 @@ You'll use the same code editor and have the same config as all other developers ### Benefits -- You only need a browser and internet -- You don't need to install development dependencies on your computer -- Start work in a fresh environment every time -- Reproducible development environment -- Similar config for all developers -- Use VS Code in the browser +- You only need a browser and internet +- You don't need to install development dependencies on your computer +- Start work in a fresh environment every time +- Reproducible development environment +- Similar config for all developers +- Use VS Code in the browser ### Drawbacks -- Waiting for the remote container to start -- If your internet is down you can't work -- If Codespaces is down you can't work +- Waiting for the remote container to start +- If your internet is down you can't work +- If Codespaces is down you can't work ## GitHub Codespaces diff --git a/docs/development/style-guide.md b/docs/development/style-guide.md index a85ad53f47db6e..2fe420332d6d9e 100644 --- a/docs/development/style-guide.md +++ b/docs/development/style-guide.md @@ -2,9 +2,9 @@ This document describes the correct style for user-facing text in the: -- Documentation -- Error and debug messages -- Texts created by the bot in issues and pull requests +- Documentation +- Error and debug messages +- Texts created by the bot in issues and pull requests ## Use American English @@ -12,8 +12,8 @@ Set your spell checker to the correct language. Guidelines: -- Use `ize` instead of `ise` in words like customize and analyze -- Drop the British `u` in words like behavior +- Use `ize` instead of `ise` in words like customize and analyze +- Drop the British `u` in words like behavior ## One sentence per line @@ -76,7 +76,7 @@ In Markdown files, avoid punctuation at the end of a list item. Like this: ```markdown -- List item, no punctuation at the end +- List item, no punctuation at the end ``` ## Use plain language diff --git a/docs/development/triage-guide.md b/docs/development/triage-guide.md index 12b33d82d9c94f..e1336f75092c86 100644 --- a/docs/development/triage-guide.md +++ b/docs/development/triage-guide.md @@ -35,19 +35,19 @@ In short: users create discussions, and when it's clear what we need to do, the ### Special labels for issues -- If it's an easy issue for somebody new to Renovate to help us with: apply the `good first issue` label -- If we need outside help on the issue, apply the `help wanted` label +- If it's an easy issue for somebody new to Renovate to help us with: apply the `good first issue` label +- If we need outside help on the issue, apply the `help wanted` label ## What a triagist is allowed to do If you've been given triage rights, you are allowed to do the following things: -- Apply labels to issues/discussions -- Close, reopen, and assign all issues and pull requests -- Mark duplicate issues and pull requests -- Request pull request reviews -- Lock and unlock discussions -- Individually convert issues to discussions (do _not_ bulk convert issues) +- Apply labels to issues/discussions +- Close, reopen, and assign all issues and pull requests +- Mark duplicate issues and pull requests +- Request pull request reviews +- Lock and unlock discussions +- Individually convert issues to discussions (do _not_ bulk convert issues) **Note:** We don't use milestones or project boards. @@ -68,8 +68,8 @@ In general, make a good-faith effort to label issues correctly. You can close an issue yourself if it's: -- Spam -- Obviously fixed +- Spam +- Obviously fixed For really old issues, it's a good idea to ask the maintainers to decide if they want to keep or close the issue. @@ -90,8 +90,8 @@ Otherwise, ask the user to open a new issue if it seems like it is different. You can assign an issue to yourself, or to somebody else, so that others know who's going to work on the issue. GitHub allows issues to be assigned to: -- any project collaborator, or -- to any non-collaborator who has _created_ or _commented_ on the issue +- any project collaborator, or +- to any non-collaborator who has _created_ or _commented_ on the issue You can assign whoever makes sense. diff --git a/docs/development/zod.md b/docs/development/zod.md index 86fc86e3acd87f..e828318270be29 100644 --- a/docs/development/zod.md +++ b/docs/development/zod.md @@ -1,20 +1,20 @@ ### Table of Contents -- [Zod schema guideline](#zod-schema-guideline) - - [When and where to use Zod](#when-and-where-to-use-zod) - - [Technical guide](#technical-guide) - - [Use `schema.ts` files for Zod schemas](#use-schemats-files-for-zod-schemas) - - [Name schemas without any `Schema` suffix](#name-schemas-without-any-schema-suffix) - - [Inferred types](#inferred-types) - - [Specify only necessary fields](#specify-only-necessary-fields) - - [Use `Json`, `Yaml` and `Toml` for string parsing](#use-json-yaml-and-toml-for-string-parsing) - - [Use `.transform()` method to process validated data](#use-transform-method-to-process-validated-data) - - [Rename and move fields at the top level transform](#rename-and-move-fields-at-the-top-level-transform) - - [Stick to permissive behavior when possible](#stick-to-permissive-behavior-when-possible) - - [Use `.catch()` to force default values](#use-catch-to-force-default-values) - - [Use `LooseArray` and `LooseRecord` to filter out incorrect values from collections](#use-loosearray-and-looserecord-to-filter-out-incorrect-values-from-collections) - - [Combining with `Result` class](#combining-with-result-class) - - [Combining with `Http` class](#combining-with-http-class) +- [Zod schema guideline](#zod-schema-guideline) + - [When and where to use Zod](#when-and-where-to-use-zod) + - [Technical guide](#technical-guide) + - [Use `schema.ts` files for Zod schemas](#use-schemats-files-for-zod-schemas) + - [Name schemas without any `Schema` suffix](#name-schemas-without-any-schema-suffix) + - [Inferred types](#inferred-types) + - [Specify only necessary fields](#specify-only-necessary-fields) + - [Use `Json`, `Yaml` and `Toml` for string parsing](#use-json-yaml-and-toml-for-string-parsing) + - [Use `.transform()` method to process validated data](#use-transform-method-to-process-validated-data) + - [Rename and move fields at the top level transform](#rename-and-move-fields-at-the-top-level-transform) + - [Stick to permissive behavior when possible](#stick-to-permissive-behavior-when-possible) + - [Use `.catch()` to force default values](#use-catch-to-force-default-values) + - [Use `LooseArray` and `LooseRecord` to filter out incorrect values from collections](#use-loosearray-and-looserecord-to-filter-out-incorrect-values-from-collections) + - [Combining with `Result` class](#combining-with-result-class) + - [Combining with `Http` class](#combining-with-http-class) # Zod schema guideline @@ -32,8 +32,8 @@ For example: if Renovate assumes an _optional_ field from a public registry will You should use Zod to validate: -- Data received from external APIs and data sources, particularly the `lib/modules/datasource/*` section of Renovate -- Data parsed from files in the repository, particularly the `lib/modules/manager/*` section of Renovate +- Data received from external APIs and data sources, particularly the `lib/modules/datasource/*` section of Renovate +- Data parsed from files in the repository, particularly the `lib/modules/manager/*` section of Renovate [The `cdnjs` datasource](https://github.com/renovatebot/renovate/blob/main/lib/modules/datasource/cdnjs/index.ts) is a good example of using Zod schema validations on API responses from external sources. @@ -56,8 +56,8 @@ Schema names must start with a capital letter: ```ts const ComplexNumber = z.object({ - re: z.number(), - im: z.number(), + re: z.number(), + im: z.number(), }); ``` @@ -75,8 +75,8 @@ Example: ```ts export const User = z.object({ - firstName: z.string(), - lastName: z.string(), + firstName: z.string(), + lastName: z.string(), }); export type User = z.infer; ``` @@ -112,9 +112,9 @@ Here's the **correct** code: ```ts const Box = z.object({ - width: z.number(), - height: z.number(), - length: z.number(), + width: z.number(), + height: z.number(), + length: z.number(), }); const { width, height, length } = Box.parse(input); @@ -130,19 +130,19 @@ The **wrong** way to parse from string: ```ts const ApiResults = z.array( - z.object({ - id: z.number(), - value: z.string(), - }), + z.object({ + id: z.number(), + value: z.string(), + }), ); type ApiResults = z.infer; let results: ApiResults | null = null; try { - const json = JSON.parse(input); - results = ApiResults.parse(json); + const json = JSON.parse(input); + results = ApiResults.parse(json); } catch (e) { - results = null; + results = null; } ``` @@ -150,12 +150,12 @@ The **correct** way to parse from string: ```ts const ApiResults = Json.pipe( - z.array( - z.object({ - id: z.number(), - value: z.string(), - }), - ), + z.array( + z.object({ + id: z.number(), + value: z.string(), + }), + ), ); const results = ApiResults.parse(input); @@ -171,9 +171,9 @@ This is an example of **undesired** data transformation: ```ts const Box = z.object({ - width: z.number(), - height: z.number(), - length: z.number(), + width: z.number(), + height: z.number(), + length: z.number(), }); const { width, height, length } = Box.parse(input); @@ -184,17 +184,17 @@ Instead, use the idiomatic `.transform()` method: ```ts const BoxVolume = z - .object({ - width: z.number(), - height: z.number(), - length: z.number(), - }) - .transform(({ width, height, length }) => width * height * length); + .object({ + width: z.number(), + height: z.number(), + length: z.number(), + }) + .transform(({ width, height, length }) => width * height * length); const volume = BoxVolume.parse({ - width: 10, - height: 20, - length: 125, + width: 10, + height: 20, + length: 125, }); // => 25000 ``` @@ -206,30 +206,30 @@ The **wrong** way is to make cascading transformations: ```ts const SourceUrl = z - .object({ - meta: z - .object({ - links: z.object({ - Github: z.string().url(), - }), - }) - .transform(({ links }) => links.Github), - }) - .transform(({ meta: sourceUrl }) => sourceUrl); + .object({ + meta: z + .object({ + links: z.object({ + Github: z.string().url(), + }), + }) + .transform(({ links }) => links.Github), + }) + .transform(({ meta: sourceUrl }) => sourceUrl); ``` The **correct** way is to rename at the top-level: ```ts const SourceUrl = z - .object({ - meta: z.object({ - links: z.object({ - Github: z.string().url(), - }), - }), - }) - .transform(({ meta }) => meta.links.Github); + .object({ + meta: z.object({ + links: z.object({ + Github: z.string().url(), + }), + }), + }) + .transform(({ meta }) => meta.links.Github); ``` ### Stick to permissive behavior when possible @@ -246,8 +246,8 @@ Here are some techniques to make Zod more permissive about the input data. ```ts const Box = z.object({ - width: z.number().catch(10), - height: z.number().catch(10), + width: z.number().catch(10), + height: z.number().catch(10), }); const box = Box.parse({ width: 20, height: null }); @@ -262,17 +262,17 @@ If you only use methods from the `zod` library, you would need to write somethin ```ts const Versions = z - .array( - z - .object({ - version: z.string(), - }) - .nullable() - .catch(null), - ) - .transform((releases) => - releases.filter((x): x is { version: string } => x !== null), - ); + .array( + z + .object({ + version: z.string(), + }) + .nullable() + .catch(null), + ) + .transform((releases) => + releases.filter((x): x is { version: string } => x !== null), + ); ``` When trying to achieve permissive behavior, this pattern will emerge quite frequently, but filtering part of the code is not very readable. @@ -281,9 +281,9 @@ Instead, you should use the `LooseArray` and `LooseRecord` helpers from `schema- ```ts const Versions = LooseArray( - z.object({ - version: z.string(), - }), + z.object({ + version: z.string(), + }), ); ``` @@ -301,23 +301,23 @@ You can wrap the schema parsing result into the `Result` class: ```ts const { val, err } = Result.parse(url, z.string().url()) - .transform((url) => http.get(url)) - .onError((err) => { - logger.warn({ err }, 'Failed to fetch something important'); - }) - .transform((res) => res.body); + .transform((url) => http.get(url)) + .onError((err) => { + logger.warn({ err }, 'Failed to fetch something important'); + }) + .transform((res) => res.body); ``` You can use schema parsing in the middle of the `Result` transform chain: ```ts const UserConfig = z.object({ - /* ... */ + /* ... */ }); const config = await Result.wrap(readLocalFile('config.json')) - .transform((content) => Json.pipe(UserConfig).safeParse(content)) - .unwrapOrThrow(); + .transform((content) => Json.pipe(UserConfig).safeParse(content)) + .unwrapOrThrow(); ``` ### Combining with `Http` class @@ -329,16 +329,16 @@ Provide schema in the last argument of the method: ```ts const Users = z.object({ - users: z.object({ - id: z.number(), - firstName: z.string(), - lastName: z.string(), - }), + users: z.object({ + id: z.number(), + firstName: z.string(), + lastName: z.string(), + }), }); const { body: users } = await http.getJson( - 'https://dummyjson.com/users', - LooseArray(User), + 'https://dummyjson.com/users', + LooseArray(User), ); ``` @@ -346,9 +346,9 @@ For GET requests, use the `.getJsonSafe()` method which returns a `Result` insta ```ts const users = await http - .getJsonSafe('https://dummyjson.com/users', LooseArray(User)) - .onError((err) => { - logger.warn({ err }, 'Failed to fetch users'); - }) - .unwrapOrElse([]); + .getJsonSafe('https://dummyjson.com/users', LooseArray(User)) + .onError((err) => { + logger.warn({ err }, 'Failed to fetch users'); + }) + .unwrapOrElse([]); ``` diff --git a/docs/usage/about-us.md b/docs/usage/about-us.md index 9f72f9853d0da1..b59055ddf07e92 100644 --- a/docs/usage/about-us.md +++ b/docs/usage/about-us.md @@ -13,38 +13,38 @@ Thank you for your time and effort! Renovate is maintained by: -- [@rarkins](https://github.com/rarkins) -- [@viceice](https://github.com/viceice) -- [@JamieMagee](https://github.com/JamieMagee) -- [@secustor](https://github.com/secustor) +- [@rarkins](https://github.com/rarkins) +- [@viceice](https://github.com/viceice) +- [@JamieMagee](https://github.com/JamieMagee) +- [@secustor](https://github.com/secustor) ### Maintainers for features Next up, we have these people who help maintain parts of Renovate: -- [@zharinov](https://github.com/zharinov) focused on parsing, Gradle and Maven -- [@secustor](https://github.com/secustor) worked on Terraform and Helm -- [@fgreinacher](https://github.com/fgreinacher) worked on NuGet -- [@Turbo87](https://github.com/Turbo87) has helped in multiple areas, especially Cargo -- [@HonkingGoose](https://github.com/HonkingGoose) works on the documentation and helps manage the community -- [@Churro](https://github.com/Churro) worked on the `gradle` manager and added support for OSV vulnerabilities +- [@zharinov](https://github.com/zharinov) focused on parsing, Gradle and Maven +- [@secustor](https://github.com/secustor) worked on Terraform and Helm +- [@fgreinacher](https://github.com/fgreinacher) worked on NuGet +- [@Turbo87](https://github.com/Turbo87) has helped in multiple areas, especially Cargo +- [@HonkingGoose](https://github.com/HonkingGoose) works on the documentation and helps manage the community +- [@Churro](https://github.com/Churro) worked on the `gradle` manager and added support for OSV vulnerabilities ### Valuable contributions We want to highlight these valuable contributions, even if they are one-offs. Some features made a lot of people happy, and efficient! -- [@ikesyo](https://github.com/ikesyo) regularly helpful -- [@astellingwerf](https://github.com/astellingwerf) reviews PRs -- [@danports](https://github.com/danports) worked on the Flux manager, and other managers. Feel free to ping `@danports` for any Flux-related issue or PR -- [@shegox](https://github.com/shegox) worked on the Go manager, and improved our docs -- [@setchy](https://github.com/setchy) focused on Bitbucket Cloud and replacement features -- [@cgrindel](https://github.com/cgrindel) created the `bazel-module` manager -- [@RahulGautamSingh](https://github.com/RahulGautamSingh) refactored a lot of code and worked on performance improvements like reduced cloning during updates and onboarding -- [@Gabriel-Ladzaretti](https://github.com/Gabriel-Ladzaretti) S3 repo cache, child process refactoring, others -- [@not7cd](https://github.com/not7cd) improved the `pip-compile` manager -- [@squidfunk](https://github.com/squidfunk) for creating and maintaining the [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/) framework, that we use to build our docs, and for helping us with problems with the framework, or our docs -- [The MkDocs project](https://www.mkdocs.org/) for making the static site generator, that we use to build our docs +- [@ikesyo](https://github.com/ikesyo) regularly helpful +- [@astellingwerf](https://github.com/astellingwerf) reviews PRs +- [@danports](https://github.com/danports) worked on the Flux manager, and other managers. Feel free to ping `@danports` for any Flux-related issue or PR +- [@shegox](https://github.com/shegox) worked on the Go manager, and improved our docs +- [@setchy](https://github.com/setchy) focused on Bitbucket Cloud and replacement features +- [@cgrindel](https://github.com/cgrindel) created the `bazel-module` manager +- [@RahulGautamSingh](https://github.com/RahulGautamSingh) refactored a lot of code and worked on performance improvements like reduced cloning during updates and onboarding +- [@Gabriel-Ladzaretti](https://github.com/Gabriel-Ladzaretti) S3 repo cache, child process refactoring, others +- [@not7cd](https://github.com/not7cd) improved the `pip-compile` manager +- [@squidfunk](https://github.com/squidfunk) for creating and maintaining the [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/) framework, that we use to build our docs, and for helping us with problems with the framework, or our docs +- [The MkDocs project](https://www.mkdocs.org/) for making the static site generator, that we use to build our docs ## Renovate development diff --git a/docs/usage/bazel.md b/docs/usage/bazel.md index 4a95e19c55e2e1..209364f9ec52f1 100644 --- a/docs/usage/bazel.md +++ b/docs/usage/bazel.md @@ -26,10 +26,10 @@ If no registries are found, Renovate defaults to the [Bazel Central Registry](ht Here are some important points about Renovate's Bazel registry searches. Renovate: -- uses _all_ `--registry` values found in a workspace's `.bazelrc` file -- uses any files that are transitively imported by a `.bazelrc` file -- only uses `--registry` values that are not associated with [a configuration](https://bazel.build/run/bazelrc#config) -- queries the registries in the order that they are found in the `.bazelrc` file +- uses _all_ `--registry` values found in a workspace's `.bazelrc` file +- uses any files that are transitively imported by a `.bazelrc` file +- only uses `--registry` values that are not associated with [a configuration](https://bazel.build/run/bazelrc#config) +- queries the registries in the order that they are found in the `.bazelrc` file #### Example: multiple `.bazelrc` files @@ -149,13 +149,13 @@ Renovate ignores [`multiple_version_override`](https://bazel.build/rules/lib/glo Renovate extracts dependencies from the following repository rules: -- `container_pull` -- `oci_pull` -- `git_repository` -- `go_repository` -- `maven_install` -- `http_archive` -- `http_file` +- `container_pull` +- `oci_pull` +- `git_repository` +- `go_repository` +- `maven_install` +- `http_archive` +- `http_file` It also recognizes when these repository rule names are prefixed with an underscore. For example, `_http_archive` is treated the same as `http_archive`. @@ -207,13 +207,13 @@ To change it, configure `packageRules` like this: ```json { - "packageRules": [ - { - "matchManagers": ["bazel"], - "matchDatasources": ["maven"], - "versioning": "maven" - } - ] + "packageRules": [ + { + "matchManagers": ["bazel"], + "matchDatasources": ["maven"], + "versioning": "maven" + } + ] } ``` diff --git a/docs/usage/bicep.md b/docs/usage/bicep.md index ae21a09c0f956a..b38c53644aa54f 100644 --- a/docs/usage/bicep.md +++ b/docs/usage/bicep.md @@ -37,9 +37,9 @@ resource storageAccount 'Microsoft.Storage/storageAccounts@2022-05-01' = { ## Future work -- Support [versioned nested resource](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/child-resource-name-type#within-parent-resource) API version upgrades. -- Support [module](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules) version upgrades. - - [Public registry](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules#public-module-registry) module references. - - [Private registry](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules#private-module-registry) module references. - - [Template spec](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules#file-in-template-spec) module references. - - [Module aliases](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-config-modules#aliases-for-modules) support. +- Support [versioned nested resource](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/child-resource-name-type#within-parent-resource) API version upgrades. +- Support [module](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules) version upgrades. + - [Public registry](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules#public-module-registry) module references. + - [Private registry](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules#private-module-registry) module references. + - [Template spec](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules#file-in-template-spec) module references. + - [Module aliases](https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/bicep-config-modules#aliases-for-modules) support. diff --git a/docs/usage/bot-comparison.md b/docs/usage/bot-comparison.md index fb49fdd802fc3b..7a0e2fd2a56bb0 100644 --- a/docs/usage/bot-comparison.md +++ b/docs/usage/bot-comparison.md @@ -62,8 +62,8 @@ If you're an advanced user, you may use the [`dependabot-core` repository](https ### Supported languages -- [Renovate's supported managers](./modules/manager/index.md) -- [Dependabot's supported repositories and ecosystems](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates#supported-repositories-and-ecosystems) +- [Renovate's supported managers](./modules/manager/index.md) +- [Dependabot's supported repositories and ecosystems](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/about-dependabot-version-updates#supported-repositories-and-ecosystems) ### Show changelogs @@ -81,10 +81,10 @@ If you're an advanced user, you may use the [`dependabot-core` repository](https Renovate shows four _Merge Confidence_ badges in its PRs: -- **Age**: The age of the package -- **Adoption**: The percentage of this package's users (within Renovate) which are using this release -- **Passing**: The percentage of updates which have passing tests for this package -- **Confidence**: The confidence level for this update +- **Age**: The age of the package +- **Adoption**: The percentage of this package's users (within Renovate) which are using this release +- **Passing**: The percentage of updates which have passing tests for this package +- **Confidence**: The confidence level for this update Read the [Merge Confidence badges](./merge-confidence.md) page to learn more. @@ -105,10 +105,10 @@ Read [Renovate scheduling](./key-concepts/scheduling.md) to learn more. Dependabot has four options that apply at a language level: -- [`schedule.interval`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduleinterval) -- [`schedule.day`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduleday) -- [`schedule.time`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduletime) -- [`schedule.timezone`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduletimezone) +- [`schedule.interval`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduleinterval) +- [`schedule.day`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduleday) +- [`schedule.time`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduletime) +- [`schedule.timezone`](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#scheduletimezone) ### License @@ -136,13 +136,13 @@ If you decide to self-host Renovate, read the items from the [Self-hosting Renov Available [Renovate distributions](./getting-started/running.md#available-distributions): -- npm package (CLI) -- Docker images -- GitHub Action -- GitLab Runner -- Mend Renovate On-Premises -- Mend Remediate (commercial offering) -- Forking Renovate app +- npm package (CLI) +- Docker images +- GitHub Action +- GitLab Runner +- Mend Renovate On-Premises +- Mend Remediate (commercial offering) +- Forking Renovate app ### Self-hosting Dependabot @@ -153,8 +153,8 @@ You can self-host Dependabot on other platforms than GitHub but none are officia You can run Dependabot as a GitHub Actions workflow on hosted and self-hosted runners. Learn more by reading the: -- [GitHub Blog, Dependabot on GitHub Actions and self-hosted runners is now generally available](https://github.blog/2024-05-02-dependabot-on-github-actions-and-self-hosted-runners-is-now-generally-available/) -- [GitHub Docs, About Dependabot on GitHub Actions runners](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/about-dependabot-on-github-actions-runners) +- [GitHub Blog, Dependabot on GitHub Actions and self-hosted runners is now generally available](https://github.blog/2024-05-02-dependabot-on-github-actions-and-self-hosted-runners-is-now-generally-available/) +- [GitHub Docs, About Dependabot on GitHub Actions runners](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/about-dependabot-on-github-actions-runners) #### `dependabot-core` diff --git a/docs/usage/config-overview.md b/docs/usage/config-overview.md index 8ed23f918d566b..19f8f1680330ce 100644 --- a/docs/usage/config-overview.md +++ b/docs/usage/config-overview.md @@ -2,11 +2,11 @@ When Renovate runs on a repository, the final config used is derived from the: -- Default config -- Global config -- Inherited config -- Repository config -- Resolved presets referenced in config +- Default config +- Global config +- Inherited config +- Repository config +- Resolved presets referenced in config ## Types of config @@ -18,8 +18,8 @@ You can find the default values on the Renovate docs website. For example: -- The default value for `onboarding` is `true` -- The option `labels` lacks a default value, which means that no labels will be added to Renovate's PRs +- The default value for `onboarding` is `true` +- The option `labels` lacks a default value, which means that no labels will be added to Renovate's PRs The default config is loaded first, and may be superseded/overridden by the configuration types listed below. @@ -73,25 +73,25 @@ Any additional Environment config variables take precedence over values in `RENO Boolean: -- `RENOVATE_ONBOARDING=true` +- `RENOVATE_ONBOARDING=true` String: -- `RENOVATE_BASE_DIR=/tmp/something` -- `RENOVATE_BASE_DIR="/tmp/some thing"` +- `RENOVATE_BASE_DIR=/tmp/something` +- `RENOVATE_BASE_DIR="/tmp/some thing"` Number: -- `RENOVATE_PR_HOURLY_LIMIT=1` +- `RENOVATE_PR_HOURLY_LIMIT=1` List with numbers or strings: -- `RENOVATE_LABELS="abc,def,label with space"` +- `RENOVATE_LABELS="abc,def,label with space"` Objects, or lists with objects: -- `RENOVATE_CONFIG="{platform\":\"gitlab\",\"onboarding\":false}"` -- `RENOVATE_PACKAGE_RULES="[{matchHost:\"gitlab\",token:\"$SOME_TOKEN\"}]"` +- `RENOVATE_CONFIG="{platform\":\"gitlab\",\"onboarding\":false}"` +- `RENOVATE_PACKAGE_RULES="[{matchHost:\"gitlab\",token:\"$SOME_TOKEN\"}]"` !!! tip @@ -107,11 +107,11 @@ Read the [Self-hosted experimental environment variables](./self-hosted-experime Finally, there are some special environment variables that are loaded _before_ configuration parsing because they are used during logging initialization: -- `LOG_CONTEXT`: a unique identifier used in each log message to track context -- `LOG_FILE`: used to enable file logging and specify the log file path -- `LOG_FILE_LEVEL`: log file logging level, defaults to `debug` -- `LOG_FORMAT`: defaults to a "pretty" human-readable output, but can be changed to "json" -- `LOG_LEVEL`: most commonly used to change from the default `info` to `debug` logging +- `LOG_CONTEXT`: a unique identifier used in each log message to track context +- `LOG_FILE`: used to enable file logging and specify the log file path +- `LOG_FILE_LEVEL`: log file logging level, defaults to `debug` +- `LOG_FORMAT`: defaults to a "pretty" human-readable output, but can be changed to "json" +- `LOG_LEVEL`: most commonly used to change from the default `info` to `debug` logging #### CLI config @@ -123,8 +123,8 @@ For example, if you configure conflicting values in Environment, File config and It is important that you: -- Always provide a value, even if the field is boolean (e.g. `--onboarding=true` and _not_ `--onboarding`), and -- Prefer `=` notation over spaces, e.g. `--onboarding=true` instead of `--onboarding true` +- Always provide a value, even if the field is boolean (e.g. `--onboarding=true` and _not_ `--onboarding`), and +- Prefer `=` notation over spaces, e.g. `--onboarding=true` instead of `--onboarding true` ### Inherited config @@ -133,14 +133,14 @@ It is important that you: The primary purpose of Inherited config is to allow for default settings of an organization/group. Two main use cases for Inherited config are: -- Controlling onboarding settings within an org (e.g. disabling onboarding, making config optional) -- Defining default config settings for repos within an org +- Controlling onboarding settings within an org (e.g. disabling onboarding, making config optional) +- Defining default config settings for repos within an org We recommend that organizations use shared presets instead of Inherited config, if possible. But default settings through Inherited config are useful if: -- You want to avoid setting Repository config in each repo, or -- You onboarded many repos prior to having a shared org config, and don't want to retrospectively edit each repo's config +- You want to avoid setting Repository config in each repo, or +- You onboarded many repos prior to having a shared org config, and don't want to retrospectively edit each repo's config #### How it's found @@ -218,21 +218,21 @@ In such cases, use `globalExtends` instead of `extends` so that it is resolved i If you use `extends` within Global config then it's important to note that these are _not_ resolved/expanded during Global config processing and instead are passed through unresolved to be part of Repository config. Passing `extends` through to be part of Repository config has two major consequences: -- It allows repository users to be able to use `ignorePresets` to ignore all or part of the `extends` presets, and -- Presets defined within `extends` in Global config will take _higher_ precedence that "regular" Global config, because it's resolved later +- It allows repository users to be able to use `ignorePresets` to ignore all or part of the `extends` presets, and +- Presets defined within `extends` in Global config will take _higher_ precedence that "regular" Global config, because it's resolved later ### Using a centralized config Using "centralized" configs through Renovate presets is important in order to be able to: -- Save time by not repeating yourself in every repo with the same config, and -- Being able to change settings across an entire Organization or groups of repositories in one place +- Save time by not repeating yourself in every repo with the same config, and +- Being able to change settings across an entire Organization or groups of repositories in one place Once you've created a centralized preset config, there are multiple ways you can pass it through to repositories: -- Defining it in Global config (either `globalExtends` or `extends`) -- Using it as your Inherited config, or referencing it from Inherited config using `extends` -- Ensuring it's referenced in Onboarding config so that it's committed as part of the Repository config +- Defining it in Global config (either `globalExtends` or `extends`) +- Using it as your Inherited config, or referencing it from Inherited config using `extends` +- Ensuring it's referenced in Onboarding config so that it's committed as part of the Repository config The above possibilities go from least to most transparent when it comes to end users. @@ -244,8 +244,8 @@ Inherited config is visible to developers (it's within a repository they can see The recommended approach for using a centralized preset is to explicitly "extend" it from every repository, which can be achieved easily if it's part of your `onboardingConfig`. By having your centralized preset part of each Repository config `extends`, it has these two benefits: -- You still have the ability to change shared settings in a single location -- Any user viewing the repo can see the preset being extended and trace it back to understand which config is applied +- You still have the ability to change shared settings in a single location +- Any user viewing the repo can see the preset being extended and trace it back to understand which config is applied ## Mend Renovate App Config @@ -260,13 +260,13 @@ Importantly, logs for all Renovate jobs by the Mend Renovate App are available t If an Organization installed Renovate with "All repositories" (instead of "Selected repositories"), then Renovate will default to "Silent" mode (`dryRun=lookup`). We chose this behavior because: -- Too often an account or org administrator selects the "All repositories" option and accidentally onboards hundreds of repositories, and -- By offering this option, it means that org administrators _can_ install Renovate into "All repositories" without worrying about the noise, and let individual repository admins decide if/when to start onboarding +- Too often an account or org administrator selects the "All repositories" option and accidentally onboards hundreds of repositories, and +- By offering this option, it means that org administrators _can_ install Renovate into "All repositories" without worrying about the noise, and let individual repository admins decide if/when to start onboarding ##### Why we call this silent mode -- It's not just no PRs, it's also no Issues -- It's a common term across other Mend capabilities, such as OSS security and SAST security, where status checks also use silent/non-silent +- It's not just no PRs, it's also no Issues +- It's a common term across other Mend capabilities, such as OSS security and SAST security, where status checks also use silent/non-silent #### Get onboarding PRs from Renovate by getting out of silent mode diff --git a/docs/usage/config-presets.md b/docs/usage/config-presets.md index 8d90c12dd93252..e2ba1d9bbbf73e 100644 --- a/docs/usage/config-presets.md +++ b/docs/usage/config-presets.md @@ -124,7 +124,7 @@ A typical onboarding `renovate.json` looks like this: ```json { - "extends": ["config:recommended"] + "extends": ["config:recommended"] } ``` @@ -135,7 +135,7 @@ You put `schedule:nonOfficeHours` in the `extends` array of your `renovate.json` ```json { - "extends": ["config:recommended", "schedule:nonOfficeHours"] + "extends": ["config:recommended", "schedule:nonOfficeHours"] } ``` @@ -145,14 +145,14 @@ If you browse the "default" presets, you will see some that have parameters, e.g ```json { - "labels": { - "description": "Apply labels {{arg0}} and {{arg1}} to PRs", - "labels": ["{{arg0}}", "{{arg1}}"] - }, - "assignee": { - "description": "Assign PRs to {{arg0}}", - "assignees": ["{{arg0}}"] - } + "labels": { + "description": "Apply labels {{arg0}} and {{arg1}} to PRs", + "labels": ["{{arg0}}", "{{arg1}}"] + }, + "assignee": { + "description": "Assign PRs to {{arg0}}", + "assignees": ["{{arg0}}"] + } } ``` @@ -160,7 +160,7 @@ Here is how you would use these in your Renovate config: ```json { - "extends": [":labels(dependencies,devops)", ":assignee(rarkins)"] + "extends": [":labels(dependencies,devops)", ":assignee(rarkins)"] } ``` @@ -174,15 +174,15 @@ Or if you think your preset would be valuable for others, please contribute a PR To host your preset config on GitHub: -- Create a new repository. Normally you'd call it `renovate-config` but it can be named anything -- Add configuration files to this new repo for any presets you want to share. For the default preset, `default.json` will be checked. For named presets, `.json` will be loaded. For example, loading preset `library` would load `library.json`. No other files are necessary. -- In other repos, reference it in an extends array like "github>owner/name", for example: +- Create a new repository. Normally you'd call it `renovate-config` but it can be named anything +- Add configuration files to this new repo for any presets you want to share. For the default preset, `default.json` will be checked. For named presets, `.json` will be loaded. For example, loading preset `library` would load `library.json`. No other files are necessary. +- In other repos, reference it in an extends array like "github>owner/name", for example: - ```json - { - "extends": ["github>rarkins/renovate-config"] - } - ``` + ```json + { + "extends": ["github>rarkins/renovate-config"] + } + ``` From then on Renovate will use the Renovate config from the preset repo's default branch. You do not need to add it as a devDependency or add any other files to the preset repo. @@ -193,17 +193,17 @@ For a private GitLab repository Renovate requires at least `Reporter` level acce To host your preset config on GitLab: -- Create a new repository on GitLab. Normally you'd call it `renovate-config` but it can be named anything -- Add a `default.json` to this new repo containing the preset config. No other files are necessary -- In other repos, reference it in an extends array like "gitlab>owner/name", e.g. "gitlab>rarkins/renovate-config" +- Create a new repository on GitLab. Normally you'd call it `renovate-config` but it can be named anything +- Add a `default.json` to this new repo containing the preset config. No other files are necessary +- In other repos, reference it in an extends array like "gitlab>owner/name", e.g. "gitlab>rarkins/renovate-config" ## Gitea-hosted Presets To host your preset config on Gitea: -- Create a new repository on Gitea. Normally you'd call it `renovate-config` but you can use any name you want -- Add a `default.json` to this new repository containing the preset config. No other files are necessary -- In other repositories, reference it in an extends array like `"gitea>owner/name"`, e.g. `"gitea>rarkins/renovate-config"` +- Create a new repository on Gitea. Normally you'd call it `renovate-config` but you can use any name you want +- Add a `default.json` to this new repository containing the preset config. No other files are necessary +- In other repositories, reference it in an extends array like `"gitea>owner/name"`, e.g. `"gitea>rarkins/renovate-config"` ## Local presets @@ -218,9 +218,9 @@ If your desired platform is not yet supported, or if you want presets to work wh ```json { - "extends": [ - "http://my.server/users/me/repos/renovate-presets/raw/default.json?at=refs%2Fheads%2Fmain" - ] + "extends": [ + "http://my.server/users/me/repos/renovate-presets/raw/default.json?at=refs%2Fheads%2Fmain" + ] } ``` @@ -228,9 +228,9 @@ Parameters are supported similar to other methods: ```json { - "extends": [ - "http://my.server/users/me/repos/renovate-presets/raw/default.json?at=refs%2Fheads%2Fmain(param)" - ] + "extends": [ + "http://my.server/users/me/repos/renovate-presets/raw/default.json?at=refs%2Fheads%2Fmain(param)" + ] } ``` @@ -251,7 +251,7 @@ The following example shows a self-hosted Renovate preset located in a GitLab re ```json { - "extends": ["local>renovate/presets"] + "extends": ["local>renovate/presets"] } ``` @@ -261,10 +261,10 @@ Here is an example of how you can use templating to validate and load the preset ```javascript // config.js module.exports = { - customEnvVariables: { - GITLAB_REF: process.env.CI_COMMIT_REF_NAME || 'main', - }, - extends: ['local>renovate/presets#{{ env.GITLAB_REF }}'], + customEnvVariables: { + GITLAB_REF: process.env.CI_COMMIT_REF_NAME || 'main', + }, + extends: ['local>renovate/presets#{{ env.GITLAB_REF }}'], }; ``` @@ -289,8 +289,8 @@ For example the result may be: ```json { - "$schema": "https://docs.renovatebot.com/renovate-schema.json", - "extends": ["local>myorgname/.github:renovate-config"] + "$schema": "https://docs.renovatebot.com/renovate-schema.json", + "extends": ["local>myorgname/.github:renovate-config"] } ``` @@ -312,13 +312,13 @@ For example: ```json { - "name": "renovate-config-fastcore", - "version": "0.0.1", - "renovate-config": { - "default": { - "extends": ["config:recommended", "schedule:nonOfficeHours"] + "name": "renovate-config-fastcore", + "version": "0.0.1", + "renovate-config": { + "default": { + "extends": ["config:recommended", "schedule:nonOfficeHours"] + } } - } } ``` @@ -326,7 +326,7 @@ Then in each of your repositories you can add your Renovate config like: ```json { - "extends": ["fastcore"] + "extends": ["fastcore"] } ``` @@ -336,6 +336,6 @@ If you prefer to publish using the namespace `@fastcore/renovate-config` then yo ```json { - "extends": ["@fastcore"] + "extends": ["@fastcore"] } ``` diff --git a/docs/usage/config-validation.md b/docs/usage/config-validation.md index fc18c2a30051f6..e3e763d9d67b82 100644 --- a/docs/usage/config-validation.md +++ b/docs/usage/config-validation.md @@ -12,8 +12,8 @@ All [`renovate` distributions](getting-started/running.md#available-distribution When you run `renovate-config-validator` with no arguments it will check: -- all [default locations](configuration-options.md) (if files exist) -- the `RENOVATE_CONFIG_FILE` environment variable +- all [default locations](configuration-options.md) (if files exist) +- the `RENOVATE_CONFIG_FILE` environment variable For example: diff --git a/docs/usage/configuration-options.md b/docs/usage/configuration-options.md index 0b1b9b3cf01db9..1ac0c8415d6b1b 100644 --- a/docs/usage/configuration-options.md +++ b/docs/usage/configuration-options.md @@ -59,25 +59,25 @@ Consider this example: ```json { - "labels": ["dependencies"], - "packageRules": [ - { - "matchPackageNames": ["/eslint/"], - "labels": ["linting"] - }, - { - "matchDepTypes": ["optionalDependencies"], - "addLabels": ["optional"] - } - ] + "labels": ["dependencies"], + "packageRules": [ + { + "matchPackageNames": ["/eslint/"], + "labels": ["linting"] + }, + { + "matchDepTypes": ["optionalDependencies"], + "addLabels": ["optional"] + } + ] } ``` With the above config: -- Optional dependencies will have the labels `dependencies` and `optional` -- ESLint dependencies will have the label `linting` -- All other dependencies will have the label `dependencies` +- Optional dependencies will have the labels `dependencies` and `optional` +- ESLint dependencies will have the label `linting` +- All other dependencies will have the label `dependencies` ## additionalBranchPrefix @@ -90,7 +90,7 @@ This can be done with this configuration: ```json { - "additionalBranchPrefix": "{{parentDir}}-" + "additionalBranchPrefix": "{{parentDir}}-" } ``` @@ -116,9 +116,9 @@ If enabled Renovate tries to determine PR assignees by matching rules defined in Read the docs for your platform for details on syntax and allowed file locations: -- [GitHub Docs, About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) -- [GitLab, Code Owners](https://docs.gitlab.com/ee/user/project/code_owners.html) -- [Bitbucket, Set up and use code owners](https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/) +- [GitHub Docs, About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) +- [GitLab, Code Owners](https://docs.gitlab.com/ee/user/project/code_owners.html) +- [Bitbucket, Set up and use code owners](https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/) ## assigneesSampleSize @@ -144,13 +144,13 @@ FROM java:8@sha256:0e8b2a860 ```json { - "packageRules": [ - { - "matchPackageNames": ["java"], - "replacementName": "eclipse-temurin", - "replacementVersion": "11" - } - ] + "packageRules": [ + { + "matchPackageNames": ["java"], + "replacementName": "eclipse-temurin", + "replacementVersion": "11" + } + ] } ``` @@ -172,12 +172,12 @@ You could configure Renovate to automerge all but major this way: ```json { - "packageRules": [ - { - "matchUpdateTypes": ["minor", "patch", "pin", "digest"], - "automerge": true - } - ] + "packageRules": [ + { + "matchUpdateTypes": ["minor", "patch", "pin", "digest"], + "automerge": true + } + ] } ``` @@ -186,12 +186,12 @@ So for example you could choose to automerge all (passing) `devDependencies` onl ```json { - "packageRules": [ - { - "matchDepTypes": ["devDependencies"], - "automerge": true - } - ] + "packageRules": [ + { + "matchDepTypes": ["devDependencies"], + "automerge": true + } + ] } ``` @@ -213,9 +213,9 @@ So for example you could choose to automerge all (passing) `devDependencies` onl You must select at least one status check in the _Require status checks to pass before merging_ section of your branch protection rules on GitHub, if you match all three conditions: -- `automerge=true` -- `platformAutomerge=true`, Renovate defaults to `true` -- You use GitHub's _Require status checks to pass before merging_ branch protection rule +- `automerge=true` +- `platformAutomerge=true`, Renovate defaults to `true` +- You use GitHub's _Require status checks to pass before merging_ branch protection rule If you don't select any status check, and you use platform automerge, then GitHub might automerge PRs with failing tests! @@ -227,9 +227,9 @@ Example use: ```json { - "automerge": true, - "automergeType": "pr-comment", - "automergeComment": "bors: r+" + "automerge": true, + "automergeType": "pr-comment", + "automergeComment": "bors: r+" } ``` @@ -254,11 +254,11 @@ If you're happy with the default behavior, you don't need to do anything. You may choose from these values: -- `auto`, Renovate decides how to merge -- `fast-forward`, "fast-forwarding" the main branch reference, no new commits in the resultant tree -- `merge-commit`, create a new merge commit -- `rebase`, rewrite history as part of the merge, but usually keep the individual commits -- `squash`, flatten the commits that are being merged into a single new commit +- `auto`, Renovate decides how to merge +- `fast-forward`, "fast-forwarding" the main branch reference, no new commits in the resultant tree +- `merge-commit`, create a new merge commit +- `rebase`, rewrite history as part of the merge, but usually keep the individual commits +- `squash`, flatten the commits that are being merged into a single new commit Platforms may only support _some_ of these merge strategies. @@ -280,10 +280,10 @@ If Renovate is scheduled for hourly runs on the repository but commits are made If you prefer that Renovate more silently automerge _without_ Pull Requests at all, you can configure `"automergeType": "branch"`. In this case Renovate will: -- Create the branch, wait for test results -- Rebase it any time it gets out of date with the base branch -- Automerge the branch commit if it's: (a) up-to-date with the base branch, and (b) passing all tests -- As a backup, raise a PR only if either: (a) tests fail, or (b) tests remain pending for too long (default: 24 hours) +- Create the branch, wait for test results +- Rebase it any time it gets out of date with the base branch +- Automerge the branch commit if it's: (a) up-to-date with the base branch, and (b) passing all tests +- As a backup, raise a PR only if either: (a) tests fail, or (b) tests remain pending for too long (default: 24 hours) The final value for `automergeType` is `"pr-comment"`, intended only for users who already have a "merge bot" such as [bors-ng](https://github.com/bors-ng/bors-ng) and want Renovate to _not_ actually automerge by itself and instead tell `bors-ng` to merge for it, by using a comment in the PR. If you're not already using `bors-ng` or similar, don't worry about this option. @@ -299,9 +299,9 @@ By default, Renovate will detect and process only the repository's default branc For most projects, this is the expected approach. Renovate also allows users to explicitly configure `baseBranches`, e.g. for use cases such as: -- You wish Renovate to process only a non-default branch, e.g. `dev`: `"baseBranches": ["dev"]` -- You have multiple release streams you need Renovate to keep up to date, e.g. in branches `main` and `next`: `"baseBranches": ["main", "next"]` -- You want to update your main branch and consistently named release branches, e.g. `main` and `release/`: `"baseBranches": ["main", "/^release\\/.*/"]` +- You wish Renovate to process only a non-default branch, e.g. `dev`: `"baseBranches": ["dev"]` +- You have multiple release streams you need Renovate to keep up to date, e.g. in branches `main` and `next`: `"baseBranches": ["main", "next"]` +- You want to update your main branch and consistently named release branches, e.g. `main` and `release/`: `"baseBranches": ["main", "/^release\\/.*/"]` It's possible to add this setting into the `renovate.json` file as part of the "Configure Renovate" onboarding PR. If so then Renovate will reflect this setting in its description and use package file contents from the custom base branch(es) instead of default. @@ -310,7 +310,7 @@ If so then Renovate will reflect this setting in its description and use package ```json { - "baseBranches": ["main", "/^release\\/.*/"] + "baseBranches": ["main", "/^release\\/.*/"] } ``` @@ -320,7 +320,7 @@ With a negation, all branches except those matching the regex will be added to t ```json { - "baseBranches": ["!/^pre-release\\/.*/"] + "baseBranches": ["!/^pre-release\\/.*/"] } ``` @@ -328,7 +328,7 @@ You can also use the special `"$default"` string to denote the repository's defa ```json { - "baseBranches": ["$default", "/^release\\/.*/"] + "baseBranches": ["$default", "/^release\\/.*/"] } ``` @@ -355,7 +355,7 @@ Example config: ```json { - "branchConcurrentLimit": 3 + "branchConcurrentLimit": 3 } ``` @@ -367,23 +367,23 @@ Example config: If you have too many concurrent branches which rebase themselves each run, Renovate can take a lot of time to rebase. Solutions: -- Decrease the concurrent branch limit (note: this won't go and delete any existing, so won't have an effect until you either merge or close existing ones manually) -- Remove automerge and/or automatic rebasing (set `rebaseWhen` to `conflicted`). However if you have branch protection saying PRs must be up to date then it's not ideal to remove automatic rebasing +- Decrease the concurrent branch limit (note: this won't go and delete any existing, so won't have an effect until you either merge or close existing ones manually) +- Remove automerge and/or automatic rebasing (set `rebaseWhen` to `conflicted`). However if you have branch protection saying PRs must be up to date then it's not ideal to remove automatic rebasing ## branchName If you truly need to configure this then it probably means either: -- You are hopefully mistaken, and there's a better approach you should use, so open a new "config help" discussion at the [Renovate discussions tab](https://github.com/renovatebot/renovate/discussions) or -- You have a use case we didn't expect, please open a discussion to see if we want to get a feature request from you +- You are hopefully mistaken, and there's a better approach you should use, so open a new "config help" discussion at the [Renovate discussions tab](https://github.com/renovatebot/renovate/discussions) or +- You have a use case we didn't expect, please open a discussion to see if we want to get a feature request from you ## branchNameStrict If `true`, Renovate removes special characters when slugifying the branch name: -- all special characters are removed -- only alphabetic characters are allowed -- hyphens `-` are used to separate sections +- all special characters are removed +- only alphabetic characters are allowed +- hyphens `-` are used to separate sections The default `false` behavior will mean that special characters like `.` may end up in the branch name. @@ -416,15 +416,15 @@ This is an advanced field, and it's recommend you seek a config review before ap Currently, this config option only works with these managers: -- `cargo` -- `helmv3` -- `npm` -- `nuget` -- `maven` -- `ocb` -- `pep621` -- `poetry` -- `sbt` +- `cargo` +- `helmv3` +- `npm` +- `nuget` +- `maven` +- `ocb` +- `pep621` +- `poetry` +- `sbt` Raise a feature request if you want to use this config option with other package managers. @@ -455,7 +455,7 @@ For example, To add `[skip ci]` to every commit you could configure: ```json { - "commitBody": "[skip ci]" + "commitBody": "[skip ci]" } ``` @@ -465,7 +465,7 @@ If you want Renovate to sign off its commits, add the [`:gitSignOff` preset](./p ```json { - "extends": [":gitSignOff"] + "extends": [":gitSignOff"] } ``` @@ -508,12 +508,12 @@ We recommend you use `matchManagers` and `commitMessageTopic` in a `packageRules ```json { - "packageRules": [ - { - "matchManagers": ["github-actions"], - "commitMessageTopic": "{{depName}}" - } - ] + "packageRules": [ + { + "matchManagers": ["github-actions"], + "commitMessageTopic": "{{depName}}" + } + ] } ``` @@ -600,9 +600,9 @@ For now this datasource constraint feature only supports `python`, other compati ```json { - "constraints": { - "python": "2.7" - } + "constraints": { + "python": "2.7" + } } ``` @@ -610,11 +610,11 @@ If you need to _override_ constraints that Renovate detects from the repository, ```json { - "force": { - "constraints": { - "node": "< 15.0.0" + "force": { + "constraints": { + "node": "< 15.0.0" + } } - } } ``` @@ -627,8 +627,8 @@ If you need to _override_ constraints that Renovate detects from the repository, This option controls whether Renovate filters new releases based on configured or detected `constraints`. Renovate supports two options: -- `none`: No release filtering (all releases allowed) -- `strict`: If the release's constraints match the package file constraints, then it's included +- `none`: No release filtering (all releases allowed) +- `strict`: If the release's constraints match the package file constraints, then it's included More advanced filtering options may come in future. @@ -637,12 +637,12 @@ Additionally, the "datasource" within Renovate must be capable of returning `con This feature is limited to the following datasources: -- `crate` -- `jenkins-plugins` -- `npm` -- `packagist` -- `pypi` -- `rubygems` +- `crate` +- `jenkins-plugins` +- `npm` +- `packagist` +- `pypi` +- `rubygems` Sometimes when using private registries they may omit constraints information, which then is another reason such filtering may not work even if the datasource and corresponding default public registry supports it. @@ -653,9 +653,9 @@ Sometimes when using private registries they may omit constraints information, w When `constraintsFiltering=strict`, the following logic applies: -- Are there `constraints` for this repository, either detected from source or from config? -- Does this package's release declare constraints of its own (e.g. `engines` in Node.js)? -- If so, filter out this release unless the repository constraint is a _subset_ of the release constraint +- Are there `constraints` for this repository, either detected from source or from config? +- Does this package's release declare constraints of its own (e.g. `engines` in Node.js)? +- If so, filter out this release unless the repository constraint is a _subset_ of the release constraint Here are some examples: @@ -669,8 +669,8 @@ Here are some examples: When using with `npm`, we recommend you: -- Use `constraintsFiltering` on `dependencies`, not `devDependencies` (usually you do not need to be strict about development dependencies) -- Do _not_ enable `rollbackPrs` at the same time (otherwise your _current_ version may be rolled back if it's incompatible) +- Use `constraintsFiltering` on `dependencies`, not `devDependencies` (usually you do not need to be strict about development dependencies) +- Do _not_ enable `rollbackPrs` at the same time (otherwise your _current_ version may be rolled back if it's incompatible) ## customDatasources @@ -685,17 +685,17 @@ Use `customManagers`(previously `regexManagers`) entries to configure the custom You can define custom managers to handle: -- Proprietary file formats or conventions -- Popular file formats not yet supported as a manager by Renovate +- Proprietary file formats or conventions +- Popular file formats not yet supported as a manager by Renovate Currently we only have one custom manager. The `regex` manager which is based on using Regular Expression named capture groups. You must have a named capture group matching (e.g. `(?.*)`) _or_ configure its corresponding template (e.g. `depNameTemplate`) for these fields: -- `datasource` -- `depName` and / or `packageName` -- `currentValue` +- `datasource` +- `depName` and / or `packageName` +- `currentValue` Use named capture group matching _or_ set a corresponding template. We recommend you use only _one_ of these methods, or you'll get confused. @@ -723,18 +723,18 @@ image: my.old.registry/aRepository/andImage:1.18-alpine ```json title="The regex definition" { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["values.yaml$"], - "matchStrings": [ - "image:\\s+(?my\\.old\\.registry/aRepository/andImage):(?[^\\s]+)" - ], - "depNameTemplate": "my.new.registry/aRepository/andImage", - "autoReplaceStringTemplate": "image: {{{depName}}}:{{{newValue}}}", - "datasourceTemplate": "docker" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["values.yaml$"], + "matchStrings": [ + "image:\\s+(?my\\.old\\.registry/aRepository/andImage):(?[^\\s]+)" + ], + "depNameTemplate": "my.new.registry/aRepository/andImage", + "autoReplaceStringTemplate": "image: {{{depName}}}:{{{newValue}}}", + "datasourceTemplate": "docker" + } + ] } ``` @@ -756,14 +756,14 @@ Example: ```json { - "customManagers": [ - { - "customType": "regex", - "matchStrings": [ - "ENV .*?_VERSION=(?.*) # (?.*?)/(?.*?)\\s" - ] - } - ] + "customManagers": [ + { + "customType": "regex", + "matchStrings": [ + "ENV .*?_VERSION=(?.*) # (?.*?)/(?.*?)\\s" + ] + } + ] } ``` @@ -795,9 +795,9 @@ Example: ```json { - "matchStrings": [ - "ENV .*?_VERSION=(?.*) # (?.*?)/(?.*?)\\s" - ] + "matchStrings": [ + "ENV .*?_VERSION=(?.*) # (?.*?)/(?.*?)\\s" + ] } ``` @@ -806,9 +806,9 @@ Example: `matchStringsStrategy` controls behavior when multiple `matchStrings` values are provided. Three options are available: -- `any` (default) -- `recursive` -- `combination` +- `any` (default) +- `recursive` +- `combination` #### any @@ -819,18 +819,18 @@ As example the following configuration will update all three lines in the Docker ```json title="renovate.json" { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^Dockerfile$"], - "matchStringsStrategy": "any", - "matchStrings": [ - "ENV [A-Z]+_VERSION=(?.*) # (?.*?)/(?.*?)(\\&versioning=(?.*?))?\\s", - "FROM (?\\S*):(?\\S*)" - ], - "datasourceTemplate": "docker" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^Dockerfile$"], + "matchStringsStrategy": "any", + "matchStrings": [ + "ENV [A-Z]+_VERSION=(?.*) # (?.*?)/(?.*?)(\\&versioning=(?.*?))?\\s", + "FROM (?\\S*):(?\\S*)" + ], + "datasourceTemplate": "docker" + } + ] } ``` @@ -857,47 +857,47 @@ But the second custom manager will upgrade both definitions as its first `matchS ```json title="renovate.json" { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^example.json$"], - "matchStringsStrategy": "recursive", - "matchStrings": [ - "\"backup\":\\s*{[^}]*}", - "\"test\":\\s*\\{[^}]*}", - "\"name\":\\s*\"(?.*)\"[^\"]*\"type\":\\s*\"(?.*)\"[^\"]*\"value\":\\s*\"(?.*)\"" - ], - "datasourceTemplate": "docker" - }, - { - "fileMatch": ["^example.json$"], - "matchStringsStrategy": "recursive", - "matchStrings": [ - "\"test\":\\s*\\{[^}]*}", - "\"name\":\\s*\"(?.*)\"[^\"]*\"type\":\\s*\"(?.*)\"[^\"]*\"value\":\\s*\"(?.*)\"" - ], - "datasourceTemplate": "docker" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^example.json$"], + "matchStringsStrategy": "recursive", + "matchStrings": [ + "\"backup\":\\s*{[^}]*}", + "\"test\":\\s*\\{[^}]*}", + "\"name\":\\s*\"(?.*)\"[^\"]*\"type\":\\s*\"(?.*)\"[^\"]*\"value\":\\s*\"(?.*)\"" + ], + "datasourceTemplate": "docker" + }, + { + "fileMatch": ["^example.json$"], + "matchStringsStrategy": "recursive", + "matchStrings": [ + "\"test\":\\s*\\{[^}]*}", + "\"name\":\\s*\"(?.*)\"[^\"]*\"type\":\\s*\"(?.*)\"[^\"]*\"value\":\\s*\"(?.*)\"" + ], + "datasourceTemplate": "docker" + } + ] } ``` ```json title="example.json" { - "backup": { - "test": { - "name": "grafana/loki", - "type": "docker", - "value": "1.6.1" - } - }, - "setup": { - "test": { - "name": "python", - "type": "docker", - "value": "3.9.0" + "backup": { + "test": { + "name": "grafana/loki", + "type": "docker", + "value": "1.6.1" + } + }, + "setup": { + "test": { + "name": "python", + "type": "docker", + "value": "3.9.0" + } } - } } ``` @@ -913,27 +913,27 @@ Matched group values will be merged to form a single dependency. ```json title="renovate.json" { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^main.yml$"], - "matchStringsStrategy": "combination", - "matchStrings": [ - "prometheus_image:\\s*\"(?.*)\"\\s*//", - "prometheus_version:\\s*\"(?.*)\"\\s*//" - ], - "datasourceTemplate": "docker" - }, - { - "fileMatch": ["^main.yml$"], - "matchStringsStrategy": "combination", - "matchStrings": [ - "thanos_image:\\s*\"(?.*)\"\\s*//", - "thanos_version:\\s*\"(?.*)\"\\s*//" - ], - "datasourceTemplate": "docker" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^main.yml$"], + "matchStringsStrategy": "combination", + "matchStrings": [ + "prometheus_image:\\s*\"(?.*)\"\\s*//", + "prometheus_version:\\s*\"(?.*)\"\\s*//" + ], + "datasourceTemplate": "docker" + }, + { + "fileMatch": ["^main.yml$"], + "matchStringsStrategy": "combination", + "matchStrings": [ + "thanos_image:\\s*\"(?.*)\"\\s*//", + "thanos_version:\\s*\"(?.*)\"\\s*//" + ], + "datasourceTemplate": "docker" + } + ] } ``` @@ -969,25 +969,25 @@ You may use the `customizeDashboard` object to customize the Dependency Dashboar Supported fields: -- `repoProblemsHeader`: This field will replace the header of the Repository Problems in the Dependency Dashboard issue. +- `repoProblemsHeader`: This field will replace the header of the Repository Problems in the Dependency Dashboard issue. ### defaultRegistryUrlTemplate This field is used to build a `registryUrl` for the dependency. It is not needed if either: -- The dependency can be found with the default `registryUrls` of the datasource (e.g. npmjs registry if the datasource is `npm`), or -- The matching groups you specified as part of the matching already include a `registryUrl` group - As this is a template it can be dynamically set. - E.g. add the `packageName` as part of the URL: +- The dependency can be found with the default `registryUrls` of the datasource (e.g. npmjs registry if the datasource is `npm`), or +- The matching groups you specified as part of the matching already include a `registryUrl` group + As this is a template it can be dynamically set. + E.g. add the `packageName` as part of the URL: ```json5 { - customDatasources: { - foo: { - defaultRegistryUrlTemplate: 'https://example.foo.bar/v1/{{ packageName }}', + customDatasources: { + foo: { + defaultRegistryUrlTemplate: 'https://example.foo.bar/v1/{{ packageName }}', + }, }, - }, } ``` @@ -1008,8 +1008,8 @@ The datasources's `customRegistrySupport` value must be `true` for the config op Default registries are only used when both: -- The manager did not extract any `registryUrls` values, and -- No `registryUrls` values have been applied via config, such as `packageRules` +- The manager did not extract any `registryUrls` values, and +- No `registryUrls` values have been applied via config, such as `packageRules` Think of `defaultRegistryUrls` as a way to specify the "fallback" registries for a datasource, for use when no `registryUrls` are extracted or configured. Compare that to `registryUrls`, which are a way to _override_ registries. @@ -1022,7 +1022,7 @@ To disable the Dependency Dashboard, add the preset `:disableDependencyDashboard ```json { - "extends": ["config:recommended", ":disableDependencyDashboard"] + "extends": ["config:recommended", ":disableDependencyDashboard"] } ``` @@ -1032,10 +1032,10 @@ The goal of this issue is to give visibility into all updates that Renovate is m Examples of what having a Dependency Dashboard will allow you to do: -- View all PRs in one place, rather than having to filter PRs by author -- Rebase/retry multiple PRs without having to open each individually -- Override any rate limiting (e.g. concurrent PRs) or scheduling to force Renovate to create a PR that would otherwise be suppressed -- Recreate an unmerged PR (e.g. for a major update that you postponed by closing the original PR) +- View all PRs in one place, rather than having to filter PRs by author +- Rebase/retry multiple PRs without having to open each individually +- Override any rate limiting (e.g. concurrent PRs) or scheduling to force Renovate to create a PR that would otherwise be suppressed +- Recreate an unmerged PR (e.g. for a major update that you postponed by closing the original PR) !!! tip @@ -1056,16 +1056,16 @@ You can approve a pending PR by selecting the checkbox in the Dependency Dashboa You can configure Renovate to wait for approval for: -- all package upgrades -- major, minor, patch level upgrades -- specific package upgrades -- upgrades coming from specific package managers +- all package upgrades +- major, minor, patch level upgrades +- specific package upgrades +- upgrades coming from specific package managers If you want to approve _all_ upgrades, set `dependencyDashboardApproval` to `true`: ```json { - "dependencyDashboardApproval": true + "dependencyDashboardApproval": true } ``` @@ -1073,9 +1073,9 @@ If you want to require approval for _major_ updates, set `dependencyDashboardApp ```json { - "major": { - "dependencyDashboardApproval": true - } + "major": { + "dependencyDashboardApproval": true + } } ``` @@ -1083,12 +1083,12 @@ If you want to approve _specific_ packages, set `dependencyDashboardApproval` to ```json { - "packageRules": [ - { - "matchPackageNames": ["/^@package-name/"], - "dependencyDashboardApproval": true - } - ] + "packageRules": [ + { + "matchPackageNames": ["/^@package-name/"], + "dependencyDashboardApproval": true + } + ] } ``` @@ -1110,9 +1110,9 @@ It is pointless to edit the labels, as Renovate bot restores the labels on each Use this option to control if the Dependency Dashboard lists the OSV-sourced CVEs for your repository. You can choose from: -- `none` (default) do not list any CVEs -- `unresolved` list CVEs that have no fixes -- `all` list all CVEs +- `none` (default) do not list any CVEs +- `unresolved` list CVEs that have no fixes +- `all` list all CVEs This feature is independent of the `osvVulnerabilityAlerts` option. @@ -1137,7 +1137,7 @@ If you want the PRs created by Renovate to be considered as drafts rather than n ```json { - "draftPR": true + "draftPR": true } ``` @@ -1156,7 +1156,7 @@ For example, if you wanted to disable Renovate completely on a repository, you c ```json { - "enabled": false + "enabled": false } ``` @@ -1164,12 +1164,12 @@ To disable Renovate for all `eslint` packages, you can configure a package rule ```json { - "packageRules": [ - { - "matchPackageNames": ["eslint**"], - "enabled": false - } - ] + "packageRules": [ + { + "matchPackageNames": ["eslint**"], + "enabled": false + } + ] } ``` @@ -1177,13 +1177,13 @@ To disable Renovate for npm `devDependencies` but keep it for `dependencies` you ```json { - "packageRules": [ - { - "matchManagers": ["npm"], - "matchDepTypes": ["devDependencies"], - "enabled": false - } - ] + "packageRules": [ + { + "matchManagers": ["npm"], + "matchDepTypes": ["devDependencies"], + "enabled": false + } + ] } ``` @@ -1195,7 +1195,7 @@ Example: ```json { - "enabledManagers": ["dockerfile", "npm"] + "enabledManagers": ["dockerfile", "npm"] } ``` @@ -1205,7 +1205,7 @@ Example: ```json { - "enabledManagers": ["custom.regex"] + "enabledManagers": ["custom.regex"] } ``` @@ -1229,11 +1229,11 @@ echo -n '{"o":"your-organization", "r":"your-repository (optional)", "v":"your-s The above script uses: -- `curl` to download the Mend Renovate hosted app's public key -- `echo` to echo a JSON object into `jq` -- `jq` to validate the JSON and then compact it -- `gpg` to encrypt the contents -- `grep` and `tr` to extract the encrypted payload which we will use +- `curl` to download the Mend Renovate hosted app's public key +- `echo` to echo a JSON object into `jq` +- `jq` to validate the JSON and then compact it +- `gpg` to encrypt the contents +- `grep` and `tr` to extract the encrypted payload which we will use The `jq` step is optional, you can leave it out if you wish. Its primary value is validating that the string you echo to `gpg` is valid JSON, and compact. @@ -1260,14 +1260,14 @@ It is valid only as a top-level configuration option and not, for example, withi Behavior: -- This option only applies when Renovate runs package manager commands (e.g. `npm install`), within the `updateArtifacts()` function -- Values set in the `env` configuration override corresponding environment variables, including those from `customEnvVariables` and `process.env` +- This option only applies when Renovate runs package manager commands (e.g. `npm install`), within the `updateArtifacts()` function +- Values set in the `env` configuration override corresponding environment variables, including those from `customEnvVariables` and `process.env` ```json title="Example renovate.json with env configuration" { - "env": { - "SOME_ENV_VARIABLE": "SOME_STRING_VALUE" - } + "env": { + "SOME_ENV_VARIABLE": "SOME_STRING_VALUE" + } } ``` @@ -1279,7 +1279,7 @@ Example: ```json { - "excludeCommitPaths": ["vendor/golang.org/x/text/**"] + "excludeCommitPaths": ["vendor/golang.org/x/text/**"] } ``` @@ -1304,12 +1304,12 @@ For example, to extract only the major.minor precision from a GitHub release, th ```json { - "packageRules": [ - { - "matchPackageNames": ["foo"], - "extractVersion": "^(?v\\d+\\.\\d+)" - } - ] + "packageRules": [ + { + "matchPackageNames": ["foo"], + "extractVersion": "^(?v\\d+\\.\\d+)" + } + ] } ``` @@ -1319,12 +1319,12 @@ Alternatively, to strip a `release-` prefix: ```json { - "packageRules": [ - { - "matchPackageNames": ["bar"], - "extractVersion": "^release-(?.*)$" - } - ] + "packageRules": [ + { + "matchPackageNames": ["bar"], + "extractVersion": "^release-(?.*)$" + } + ] } ``` @@ -1333,12 +1333,12 @@ A similar one could strip leading `v` prefixes: ```json { - "packageRules": [ - { - "matchPackageNames": ["baz"], - "extractVersion": "^v(?.*)$" - } - ] + "packageRules": [ + { + "matchPackageNames": ["baz"], + "extractVersion": "^v(?.*)$" + } + ] } ``` @@ -1347,18 +1347,18 @@ A similar one could strip leading `v` prefixes: Use this config option to configure changelogs/release notes fetching. The available options are: -- `off` - disable changelogs fetching -- `branch` - fetch changelogs while creating/updating branch -- `pr`(default) - fetches changelogs while creating/updating pull-request +- `off` - disable changelogs fetching +- `branch` - fetch changelogs while creating/updating branch +- `pr`(default) - fetches changelogs while creating/updating pull-request Avoid setting `fetchChangeLogs=branch`, because this slows down Renovate. But if you're embedding changelogs in commit information, you may use `fetchChangeLogs=branch`. Renovate can fetch changelogs when they are hosted on one of these platforms: -- Bitbucket Cloud -- GitHub (.com and Enterprise Server) -- GitLab (.com and CE/EE) +- Bitbucket Cloud +- GitHub (.com and Enterprise Server) +- GitLab (.com and CE/EE) If you are running on any platform except `github.com`, you need to [configure a Personal Access Token](./getting-started/running.md#githubcom-token-for-changelogs) to allow Renovate to fetch changelogs notes from `github.com`. @@ -1388,9 +1388,9 @@ Because `fileMatch` is mergeable, you don't need to duplicate the defaults and c ```json { - "dockerfile": { - "fileMatch": ["^ACTUALLY_A_DOCKERFILE\\.template$"] - } + "dockerfile": { + "fileMatch": ["^ACTUALLY_A_DOCKERFILE\\.template$"] + } } ``` @@ -1411,12 +1411,12 @@ The main use case is to follow a pre-release tag of a dependency, say TypeScript ```json { - "packageRules": [ - { - "matchPackageNames": ["typescript"], - "followTag": "insiders" - } - ] + "packageRules": [ + { + "matchPackageNames": ["typescript"], + "followTag": "insiders" + } + ] } ``` @@ -1451,8 +1451,8 @@ It even skips a forked repository that has a Renovate configuration file, becaus If you want Renovate to run on a forked repository when in `autodiscover` mode then: -- Ensure a `renovate.json` config exists with `"forkProcessing": "enabled"` in your repository, -- Or run the CLI command with `--fork-processing=enabled` +- Ensure a `renovate.json` config exists with `"forkProcessing": "enabled"` in your repository, +- Or run the CLI command with `--fork-processing=enabled` **Process a fork in other modes** @@ -1503,7 +1503,7 @@ Example: ```json { - "gitIgnoredAuthors": ["some-bot@example.org"] + "gitIgnoredAuthors": ["some-bot@example.org"] } ``` @@ -1521,7 +1521,7 @@ If you need to modify this path, for example in order to ignore directories, you ```json { - "goGetDirs": ["./some-project/", "./tools/..."] + "goGetDirs": ["./some-project/", "./tools/..."] } ``` @@ -1543,13 +1543,13 @@ For example, to group all non-major devDependencies updates together into a sing ```json { - "packageRules": [ - { - "matchDepTypes": ["devDependencies"], - "matchUpdateTypes": ["patch", "minor"], - "groupName": "devDependencies (non-major)" - } - ] + "packageRules": [ + { + "matchDepTypes": ["devDependencies"], + "matchUpdateTypes": ["patch", "minor"], + "groupName": "devDependencies (non-major)" + } + ] } ``` @@ -1561,14 +1561,14 @@ If you wished to override this then you could configure like this: ```json { - "packageRules": [ - { - "matchDepTypes": ["devDependencies"], - "matchUpdateTypes": ["patch", "minor"], - "groupName": "devDependencies (non-major)", - "groupSlug": "dev-dependencies" - } - ] + "packageRules": [ + { + "matchDepTypes": ["devDependencies"], + "matchUpdateTypes": ["patch", "minor"], + "groupName": "devDependencies (non-major)", + "groupSlug": "dev-dependencies" + } + ] } ``` @@ -1598,13 +1598,13 @@ Example for configuring `docker` auth: ```json { - "hostRules": [ - { - "matchHost": "docker.io", - "username": "", - "password": "" - } - ] + "hostRules": [ + { + "matchHost": "docker.io", + "username": "", + "password": "" + } + ] } ``` @@ -1618,12 +1618,12 @@ To disable requests to a particular host, you can configure a rule like: ```json { - "hostRules": [ - { - "matchHost": "registry.npmjs.org", - "enabled": false - } - ] + "hostRules": [ + { + "matchHost": "registry.npmjs.org", + "enabled": false + } + ] } ``` @@ -1631,7 +1631,7 @@ A preset alternative to the above is: ```json { - "extends": [":disableHost(registry.npmjs.org)"] + "extends": [":disableHost(registry.npmjs.org)"] } ``` @@ -1639,12 +1639,12 @@ To match specific ports you have to add a protocol to `matchHost`: ```json { - "hostRules": [ - { - "matchHost": "https://domain.com:9118", - "enabled": false - } - ] + "hostRules": [ + { + "matchHost": "https://domain.com:9118", + "enabled": false + } + ] } ``` @@ -1664,12 +1664,12 @@ For example to also skip 404 responses then configure the following: ```json { - "hostRules": [ - { - "abortOnError": true, - "abortIgnoreStatusCodes": [404] - } - ] + "hostRules": [ + { + "abortOnError": true, + "abortIgnoreStatusCodes": [404] + } + ] } ``` @@ -1686,11 +1686,11 @@ To abort Renovate runs for HTTP failures from _any_ host: ```json { - "hostRules": [ - { - "abortOnError": true - } - ] + "hostRules": [ + { + "abortOnError": true + } + ] } ``` @@ -1698,12 +1698,12 @@ To abort Renovate runs for any `docker` datasource failures: ```json { - "hostRules": [ - { - "hostType": "docker", - "abortOnError": true - } - ] + "hostRules": [ + { + "hostType": "docker", + "abortOnError": true + } + ] } ``` @@ -1711,12 +1711,12 @@ To abort Renovate for errors for a specific `docker` host: ```json { - "hostRules": [ - { - "matchHost": "docker.company.com", - "abortOnError": true - } - ] + "hostRules": [ + { + "matchHost": "docker.company.com", + "abortOnError": true + } + ] } ``` @@ -1730,14 +1730,14 @@ For example, using this option could be used whenever authentication using Git f ```json { - "hostRules": [ - { - "hostType": "gitlab", - "matchHost": "gitlab.myorg.com", - "token": "abc123", - "artifactAuth": ["composer"] - } - ] + "hostRules": [ + { + "hostType": "gitlab", + "matchHost": "gitlab.myorg.com", + "token": "abc123", + "artifactAuth": ["composer"] + } + ] } ``` @@ -1759,13 +1759,13 @@ An example for npm basic auth with token: ```json { - "hostRules": [ - { - "matchHost": "npm.custom.org", - "token": "", - "authType": "Basic" - } - ] + "hostRules": [ + { + "matchHost": "npm.custom.org", + "token": "", + "authType": "Basic" + } + ] } ``` @@ -1775,13 +1775,13 @@ To use a bare token in the authorization header (required by e.g. Hex) - use the ```json { - "hostRules": [ - { - "matchHost": "https://hex.pm/api/repos/private_repo/", - "token": "", - "authType": "Token-Only" - } - ] + "hostRules": [ + { + "matchHost": "https://hex.pm/api/repos/private_repo/", + "token": "", + "authType": "Token-Only" + } + ] } ``` @@ -1797,12 +1797,12 @@ Example config: ```json { - "hostRules": [ - { - "matchHost": "api.github.com", - "concurrentRequestLimit": 2 - } - ] + "hostRules": [ + { + "matchHost": "api.github.com", + "concurrentRequestLimit": 2 + } + ] } ``` @@ -1831,14 +1831,14 @@ For example: ```json { - "hostRules": [ - { - "matchHost": "https://domain.com/all-versions", - "headers": { - "X-custom-header": "secret" - } - } - ] + "hostRules": [ + { + "matchHost": "https://domain.com/all-versions", + "headers": { + "X-custom-header": "secret" + } + } + ] } ``` @@ -1875,12 +1875,12 @@ Example: ```json { - "hostRules": [ - { - "matchHost": "reg.insecure.com", - "insecureRegistry": true - } - ] + "hostRules": [ + { + "matchHost": "reg.insecure.com", + "insecureRegistry": true + } + ] } ``` @@ -1899,12 +1899,12 @@ The `matchHost` URL must be the same as the `registryUrl` set in `.npmrc`, or yo ```json { - "hostRules": [ - { - "matchHost": "https://gitlab.myorg.com/api/v4/packages/npm/", - "token": "abc123" - } - ] + "hostRules": [ + { + "matchHost": "https://gitlab.myorg.com/api/v4/packages/npm/", + "token": "abc123" + } + ] } ``` @@ -1929,12 +1929,12 @@ Example config: ```json { - "hostRules": [ - { - "matchHost": "api.github.com", - "maxRequestsPerSecond": 2 - } - ] + "hostRules": [ + { + "matchHost": "api.github.com", + "maxRequestsPerSecond": 2 + } + ] } ``` @@ -1949,12 +1949,12 @@ You can configure a different maximum value in seconds using `maxRetryAfter`: ```json { - "hostRules": [ - { - "matchHost": "api.github.com", - "maxRetryAfter": 25 - } - ] + "hostRules": [ + { + "matchHost": "api.github.com", + "maxRetryAfter": 25 + } + ] } ``` @@ -1964,12 +1964,12 @@ For log level remapping, `newLogLevel` will set for the particular log message: ```json { - "logLevelRemap": [ - { - "matchMessage": "/Error executing maven wrapper update command/", - "newLogLevel": "warn" - } - ] + "logLevelRemap": [ + { + "matchMessage": "/Error executing maven wrapper update command/", + "newLogLevel": "warn" + } + ] } ``` @@ -1982,13 +1982,13 @@ This option could be used to avoid rate limits for certain platforms like GitHub ```json { - "hostRules": [ - { - "matchHost": "api.github.com", - "readOnly": true, - "token": "********" - } - ] + "hostRules": [ + { + "matchHost": "api.github.com", + "readOnly": true, + "token": "********" + } + ] } ``` @@ -2002,11 +2002,11 @@ To adjust it down to 10s for all queries, do this: ```json { - "hostRules": [ - { - "timeout": 10000 - } - ] + "hostRules": [ + { + "timeout": 10000 + } + ] } ``` @@ -2024,7 +2024,7 @@ Currently it supports only "exact match" dependency names and not any patterns. ```json { - "ignoreDeps": ["eslint", "eslint-config-base"] + "ignoreDeps": ["eslint", "eslint-config-base"] } ``` @@ -2032,12 +2032,12 @@ The above is the same as if you wrote this package rule: ```json { - "packageRules": [ - { - "matchPackageNames": ["eslint", "eslint-config-base"], - "enabled": false - } - ] + "packageRules": [ + { + "matchPackageNames": ["eslint", "eslint-config-base"], + "enabled": false + } + ] } ``` @@ -2050,7 +2050,7 @@ For instance if you have a project with an `"examples/"` directory you wish to i ```json { - "ignorePaths": ["**/examples/**"] + "ignorePaths": ["**/examples/**"] } ``` @@ -2079,8 +2079,8 @@ For example, consider this config: ```json { - "extends": ["config:recommended"], - "ignorePresets": ["group:monorepos"] + "extends": ["config:recommended"], + "ignorePresets": ["group:monorepos"] } ``` @@ -2094,8 +2094,8 @@ In the case that a user is automatically added as reviewer (such as Renovate App ```json { - "reviewers": ["foo"], - "ignoreReviewers": ["renovate-approve"] + "reviewers": ["foo"], + "ignoreReviewers": ["renovate-approve"] } ``` @@ -2141,9 +2141,9 @@ Change this setting to `true` if you want to use internal Renovate checks toward This setting determines whether Renovate controls when and how filtering of internal checks are performed, particularly when multiple versions of the same update type are available. Currently this applies to the `minimumReleaseAge` check only. -- `none`: No filtering will be performed, and the highest release will be used regardless of whether it's pending or not -- `strict`: All pending releases will be filtered. PRs will be skipped unless a non-pending version is available -- `flexible`: Similar to strict, but in the case where all versions are pending then a PR will be created with the highest pending version +- `none`: No filtering will be performed, and the highest release will be used regardless of whether it's pending or not +- `strict`: All pending releases will be filtered. PRs will be skipped unless a non-pending version is available +- `flexible`: Similar to strict, but in the case where all versions are pending then a PR will be created with the highest pending version The `flexible` mode can result in "flapping" of Pull Requests, for example: a pending PR with version `1.0.3` is first released but then downgraded to `1.0.2` once it passes `minimumReleaseAge`. We recommend that you use the `strict` mode, and enable the `dependencyDashboard` so that you can see suppressed PRs. @@ -2158,8 +2158,8 @@ This is different from the `rebaseLabel` option, where Renovate _removes_ the la `keepUpdatedLabel` can be useful when you have approved certain PRs and want Renovate to keep the PRs up-to-date until you're ready to merge them. The setting `keepUpdatedLabel` is best used in this scenario: -- By default, you configure `rebaseWhen` to `never` or `conflicted` to reduce rebasing -- Sometimes, you want Renovate to keep specific PRs up-to-date with their base branch (equivalent to `rebaseWhen=behind-base-branch`) +- By default, you configure `rebaseWhen` to `never` or `conflicted` to reduce rebasing +- Sometimes, you want Renovate to keep specific PRs up-to-date with their base branch (equivalent to `rebaseWhen=behind-base-branch`) ## labels @@ -2172,13 +2172,13 @@ Consider this example: ```json { - "labels": ["dependencies"], - "packageRules": [ - { - "matchPackageNames": ["/eslint/"], - "labels": ["linting"] - } - ] + "labels": ["dependencies"], + "packageRules": [ + { + "matchPackageNames": ["/eslint/"], + "labels": ["linting"] + } + ] } ``` @@ -2186,8 +2186,8 @@ With the above config, every PR raised by Renovate will have the label `dependen Behavior details: -- On GitHub, GitLab and Gitea: Renovate will keep PR labels in sync with configured labels, provided that no other user or bot has made changes to the labels after PR creation. If labels are changed by any other account, Renovate will stop making further changes. -- For other platforms, Renovate will add labels only at time of PR creation and not update them after that. +- On GitHub, GitLab and Gitea: Renovate will keep PR labels in sync with configured labels, provided that no other user or bot has made changes to the labels after PR creation. If labels are changed by any other account, Renovate will stop making further changes. +- For other platforms, Renovate will add labels only at time of PR creation and not update them after that. The `labels` array is non-mergeable, meaning if multiple `packageRules` match then Renovate uses the last value for `labels`. If you want to add/combine labels, use the `addLabels` config option, which is mergeable. @@ -2202,25 +2202,25 @@ Renovate then commits that lock file to the update branch and creates the lock f Supported lock files: -- `.terraform.lock.hcl` -- `Cargo.lock` -- `Chart.lock` -- `composer.lock` -- `flake.lock` -- `Gemfile.lock` -- `gradle.lockfile` -- `jsonnetfile.lock.json` -- `manifest.toml` -- `package-lock.json` -- `packages.lock.json` -- `pdm.lock` -- `Pipfile.lock` -- `pnpm-lock.yaml` -- `poetry.lock` -- `pubspec.lock` -- `pyproject.toml` -- `requirements.txt` -- `yarn.lock` +- `.terraform.lock.hcl` +- `Cargo.lock` +- `Chart.lock` +- `composer.lock` +- `flake.lock` +- `Gemfile.lock` +- `gradle.lockfile` +- `jsonnetfile.lock.json` +- `manifest.toml` +- `package-lock.json` +- `packages.lock.json` +- `pdm.lock` +- `Pipfile.lock` +- `pnpm-lock.yaml` +- `poetry.lock` +- `pubspec.lock` +- `pyproject.toml` +- `requirements.txt` +- `yarn.lock` Support for new lock files may be added via feature request. @@ -2229,7 +2229,7 @@ To enable `lockFileMaintenance` add this to your configuration: ```json { - "lockFileMaintenance": { "enabled": true } + "lockFileMaintenance": { "enabled": true } } ``` @@ -2244,20 +2244,20 @@ Be careful with remapping `warn` or `error` messages to lower log levels, as it ```json { - "logLevelRemap": [ - { - "matchMessage": "/^pip-compile:/", - "newLogLevel": "info" - }, - { - "matchMessage": "Package lookup error", - "newLogLevel": "warn" - }, - { - "matchMessage": "/^Please upgrade the version of Node.js/", - "newLogLevel": "info" - } - ] + "logLevelRemap": [ + { + "matchMessage": "/^pip-compile:/", + "newLogLevel": "info" + }, + { + "matchMessage": "Package lookup error", + "newLogLevel": "warn" + }, + { + "matchMessage": "/^Please upgrade the version of Node.js/", + "newLogLevel": "info" + } + ] } ``` @@ -2272,7 +2272,7 @@ Renovate will only add a milestone when it _creates_ the PR. ```json title="Example Renovate config" { - "milestone": 12 + "milestone": 12 } ``` @@ -2319,12 +2319,12 @@ Set `minimumReleaseAge` to `3 days` for npm packages to prevent relying on a pac ```json { - "packageRules": [ - { - "matchDatasources": ["npm"], - "minimumReleaseAge": "3 days" - } - ] + "packageRules": [ + { + "matchDatasources": ["npm"], + "minimumReleaseAge": "3 days" + } + ] } ``` @@ -2352,15 +2352,15 @@ When both are configured, `dryRun` takes precedence, so for example PRs won't be Configuring `silent` mode is quite similar to `dryRun=lookup` except: -- It will bypass onboarding checks (unlike when performing a dry run on a non-onboarded repo) similar to `requireConfig=optional` -- It can create branches/PRs if `checkedBranches` is set -- It will keep any existing branches up-to-date (e.g. ones created previously using `checkedBranches`) +- It will bypass onboarding checks (unlike when performing a dry run on a non-onboarded repo) similar to `requireConfig=optional` +- It can create branches/PRs if `checkedBranches` is set +- It will keep any existing branches up-to-date (e.g. ones created previously using `checkedBranches`) When in `silent` mode Renovate will: -- _not_ create or update any Issue: even the Dependency Dashboard or Config Warning Issues will stay as-is -- _not_ prune or close any existing Issues -- _not_ create any Config Migration PRs, even if you explictly enabled Config Migration PRs in your Renovate config +- _not_ create or update any Issue: even the Dependency Dashboard or Config Warning Issues will stay as-is +- _not_ prune or close any existing Issues +- _not_ create any Config Migration PRs, even if you explictly enabled Config Migration PRs in your Renovate config ## npmToken @@ -2388,15 +2388,15 @@ Set `osvVulnerabilityAlerts` to `true` to get pull requests with vulnerability f You will only get OSV-based vulnerability alerts for _direct_ dependencies. Renovate only queries the OSV database for dependencies that use one of these datasources: -- [`crate`](./modules/datasource/crate/index.md) -- [`go`](./modules/datasource/go/index.md) -- [`hex`](./modules/datasource/hex/index.md) -- [`maven`](./modules/datasource/maven/index.md) -- [`npm`](./modules/datasource/npm/index.md) -- [`nuget`](./modules/datasource/nuget/index.md) -- [`packagist`](./modules/datasource/packagist/index.md) -- [`pypi`](./modules/datasource/pypi/index.md) -- [`rubygems`](./modules/datasource/rubygems/index.md) +- [`crate`](./modules/datasource/crate/index.md) +- [`go`](./modules/datasource/go/index.md) +- [`hex`](./modules/datasource/hex/index.md) +- [`maven`](./modules/datasource/maven/index.md) +- [`npm`](./modules/datasource/npm/index.md) +- [`nuget`](./modules/datasource/nuget/index.md) +- [`packagist`](./modules/datasource/packagist/index.md) +- [`pypi`](./modules/datasource/pypi/index.md) +- [`rubygems`](./modules/datasource/rubygems/index.md) ## packageRules @@ -2408,25 +2408,25 @@ The order of rules matters, because later rules may override configuration optio The matching process for a package rule: -- Each package rule can include `match...` matchers to identify dependencies and `exclude...` matchers to filter them out. -- If no match/exclude matchers are defined, everything matches. -- If an aspect is both `match`ed and `exclude`d, the exclusion wins. -- Multiple values within a single matcher will be evaluated independently (they're OR-ed together). -- Combining multiple matchers will restrict the resulting matches (they're AND-ed together): - `matchCurrentVersion`, `matchCurrentValue`, `matchNewValue`, `matchConfidence`, `matchCurrentAge`, - `matchManagers`, `matchDatasources`, `matchCategories`, `matchDepTypes`, `matchUpdateTypes`, - `matchRepositories`/`excludeRepositories`, `matchBaseBranches`, `matchFileNames` +- Each package rule can include `match...` matchers to identify dependencies and `exclude...` matchers to filter them out. +- If no match/exclude matchers are defined, everything matches. +- If an aspect is both `match`ed and `exclude`d, the exclusion wins. +- Multiple values within a single matcher will be evaluated independently (they're OR-ed together). +- Combining multiple matchers will restrict the resulting matches (they're AND-ed together): + `matchCurrentVersion`, `matchCurrentValue`, `matchNewValue`, `matchConfidence`, `matchCurrentAge`, + `matchManagers`, `matchDatasources`, `matchCategories`, `matchDepTypes`, `matchUpdateTypes`, + `matchRepositories`/`excludeRepositories`, `matchBaseBranches`, `matchFileNames` Here is an example if you want to group together all packages starting with `eslint` into a single branch/PR: ```json { - "packageRules": [ - { - "matchPackageNames": ["eslint**"], - "groupName": "eslint packages" - } - ] + "packageRules": [ + { + "matchPackageNames": ["eslint**"], + "groupName": "eslint packages" + } + ] } ``` @@ -2436,12 +2436,12 @@ Here's an example config to limit the "noisy" `aws-sdk` package to weekly update ```json { - "packageRules": [ - { - "matchPackageNames": ["aws-sdk"], - "schedule": ["after 9pm on sunday"] - } - ] + "packageRules": [ + { + "matchPackageNames": ["aws-sdk"], + "schedule": ["after 9pm on sunday"] + } + ] } ``` @@ -2453,12 +2453,12 @@ Example: ```json { - "packageRules": [ - { - "matchPackageNames": ["neutrino", "@neutrino/**"], - "groupName": "neutrino monorepo" - } - ] + "packageRules": [ + { + "matchPackageNames": ["neutrino", "@neutrino/**"], + "groupName": "neutrino monorepo" + } + ] } ``` @@ -2469,12 +2469,12 @@ For example, if you have an `examples` directory and you want all updates to tho ```json { - "packageRules": [ - { - "matchFileNames": ["examples/**"], - "extends": [":semanticCommitTypeAll(chore)"] - } - ] + "packageRules": [ + { + "matchFileNames": ["examples/**"], + "extends": [":semanticCommitTypeAll(chore)"] + } + ] } ``` @@ -2483,12 +2483,12 @@ For example you have multiple `package.json` and want to use `dependencyDashboar ```json { - "packageRules": [ - { - "matchFileNames": ["package.json"], - "dependencyDashboardApproval": true - } - ] + "packageRules": [ + { + "matchFileNames": ["package.json"], + "dependencyDashboardApproval": true + } + ] } ``` @@ -2509,12 +2509,12 @@ For example, if you want to upgrade to Angular v1.5 but _not_ to `angular` v1.6 ```json { - "packageRules": [ - { - "matchPackageNames": ["angular"], - "allowedVersions": "<=1.5" - } - ] + "packageRules": [ + { + "matchPackageNames": ["angular"], + "allowedVersions": "<=1.5" + } + ] } ``` @@ -2529,12 +2529,12 @@ For example, this config only allows 3 or 4-part versions, without any prefixes ```json { - "packageRules": [ - { - "matchPackageNames": ["com.thoughtworks.xstream:xstream"], - "allowedVersions": "/^[0-9]+\\.[0-9]+\\.[0-9]+(\\.[0-9]+)?$/" - } - ] + "packageRules": [ + { + "matchPackageNames": ["com.thoughtworks.xstream:xstream"], + "allowedVersions": "/^[0-9]+\\.[0-9]+\\.[0-9]+(\\.[0-9]+)?$/" + } + ] } ``` @@ -2547,12 +2547,12 @@ You must use the `!/ /` syntax, like this: ```json { - "packageRules": [ - { - "matchPackageNames": ["chalk"], - "allowedVersions": "!/java$/" - } - ] + "packageRules": [ + { + "matchPackageNames": ["chalk"], + "allowedVersions": "!/java$/" + } + ] } ``` @@ -2567,12 +2567,12 @@ To read the changelogs you must use the link. ```json title="Setting the changelog URL for the dummy package" { - "packageRules": [ - { - "matchPackageNames": ["dummy"], - "changelogUrl": "https://github.com/org/dummy" - } - ] + "packageRules": [ + { + "matchPackageNames": ["dummy"], + "changelogUrl": "https://github.com/org/dummy" + } + ] } ``` @@ -2588,13 +2588,13 @@ Use this field to restrict rules to a particular branch. e.g. ```json { - "packageRules": [ - { - "matchBaseBranches": ["main"], - "excludePackagePatterns": ["^eslint"], - "enabled": false - } - ] + "packageRules": [ + { + "matchBaseBranches": ["main"], + "excludePackagePatterns": ["^eslint"], + "enabled": false + } + ] } ``` @@ -2602,13 +2602,13 @@ This field also supports Regular Expressions if they begin and end with `/`. e.g ```json { - "packageRules": [ - { - "matchBaseBranches": ["/^release/.*/"], - "excludePackagePatterns": ["^eslint"], - "enabled": false - } - ] + "packageRules": [ + { + "matchBaseBranches": ["/^release/.*/"], + "excludePackagePatterns": ["^eslint"], + "enabled": false + } + ] } ``` @@ -2625,12 +2625,12 @@ The categories can be found in the [manager documentation](modules/manager/index ```json { - "packageRules": [ - { - "matchCategories": ["python"], - "addLabels": ["py"] - } - ] + "packageRules": [ + { + "matchCategories": ["python"], + "addLabels": ["py"] + } + ] } ``` @@ -2643,12 +2643,12 @@ The categories can be found in the [manager documentation](modules/manager/index ```json title="Grouping high merge confidence updates" { - "packageRules": [ - { - "matchConfidence": ["high", "very high"], - "groupName": "high merge confidence" - } - ] + "packageRules": [ + { + "matchConfidence": ["high", "very high"], + "groupName": "high merge confidence" + } + ] } ``` @@ -2660,12 +2660,12 @@ For example, if you want to group updates for dependencies where the existing ve ```json { - "packageRules": [ - { - "matchCurrentAge": "> 2 years", - "groupName": "old dependencies" - } - ] + "packageRules": [ + { + "matchCurrentAge": "> 2 years", + "groupName": "old dependencies" + } + ] } ``` @@ -2686,13 +2686,13 @@ This option is matched against the `currentValue` field of a dependency. ```json { - "packageRules": [ - { - "matchPackagePatterns": ["io.github.resilience4j"], - "matchCurrentValue": "1.*", - "automerge": true - } - ] + "packageRules": [ + { + "matchPackagePatterns": ["io.github.resilience4j"], + "matchCurrentValue": "1.*", + "automerge": true + } + ] } ``` @@ -2700,12 +2700,12 @@ Regular Expressions must begin and end with `/`. ```json { - "packageRules": [ - { - "matchPackageNames": ["io.github.resilience4j**"], - "matchCurrentValue": "/^1\\./" - } - ] + "packageRules": [ + { + "matchPackageNames": ["io.github.resilience4j**"], + "matchCurrentValue": "/^1\\./" + } + ] } ``` @@ -2714,12 +2714,12 @@ Use the syntax `!/ /` like this: ```json { - "packageRules": [ - { - "matchPackageNames": ["io.github.resilience4j**"], - "matchCurrentValue": "!/^0\\./" - } - ] + "packageRules": [ + { + "matchPackageNames": ["io.github.resilience4j**"], + "matchCurrentValue": "!/^0\\./" + } + ] } ``` @@ -2727,9 +2727,9 @@ Use the syntax `!/ /` like this: The `currentVersion` field will be one of the following (in order of preference): -- locked version if a lock file exists -- resolved version -- current value +- locked version if a lock file exists +- resolved version +- current value Consider using instead `matchCurrentValue` if you wish to match against the raw string value of a dependency. @@ -2737,12 +2737,12 @@ Consider using instead `matchCurrentValue` if you wish to match against the raw ```json { - "packageRules": [ - { - "matchCurrentVersion": ">=1.0.0", - "matchPackageNames": ["angular"] - } - ] + "packageRules": [ + { + "matchCurrentVersion": ">=1.0.0", + "matchPackageNames": ["angular"] + } + ] } ``` @@ -2755,12 +2755,12 @@ For example, the following enforces that only `1.*` versions will be used: ```json { - "packageRules": [ - { - "matchPackageNames": ["io.github.resilience4j**"], - "matchCurrentVersion": "/^1\\./" - } - ] + "packageRules": [ + { + "matchPackageNames": ["io.github.resilience4j**"], + "matchCurrentVersion": "/^1\\./" + } + ] } ``` @@ -2769,12 +2769,12 @@ Use the syntax `!/ /` like this: ```json { - "packageRules": [ - { - "matchPackageNames": ["io.github.resilience4j**"], - "matchCurrentVersion": "!/^0\\./" - } - ] + "packageRules": [ + { + "matchPackageNames": ["io.github.resilience4j**"], + "matchCurrentVersion": "!/^0\\./" + } + ] } ``` @@ -2784,12 +2784,12 @@ Use this field to restrict rules to a particular datasource. e.g. ```json { - "packageRules": [ - { - "matchDatasources": ["orb"], - "labels": ["circleci-orb!!"] - } - ] + "packageRules": [ + { + "matchDatasources": ["orb"], + "labels": ["circleci-orb!!"] + } + ] } ``` @@ -2810,12 +2810,12 @@ The following example matches `package.json` but _not_ `package/frontend/package ```json { - "packageRules": [ - { - "matchFileNames": ["package.json"], - "labels": ["npm"] - } - ] + "packageRules": [ + { + "matchFileNames": ["package.json"], + "labels": ["npm"] + } + ] } ``` @@ -2823,13 +2823,13 @@ The following example matches any `package.json`, including files like `backend/ ```json { - "packageRules": [ - { - "description": "Group dependencies from package.json files", - "matchFileNames": ["**/package.json"], - "groupName": "All package.json changes" - } - ] + "packageRules": [ + { + "description": "Group dependencies from package.json files", + "matchFileNames": ["**/package.json"], + "groupName": "All package.json changes" + } + ] } ``` @@ -2837,13 +2837,13 @@ The following example matches any file in directories starting with `app/`: ```json { - "packageRules": [ - { - "description": "Group all dependencies from the app directory", - "matchFileNames": ["app/**"], - "groupName": "App dependencies" - } - ] + "packageRules": [ + { + "description": "Group all dependencies from the app directory", + "matchFileNames": ["app/**"], + "groupName": "App dependencies" + } + ] } ``` @@ -2855,13 +2855,13 @@ Use this field to restrict rules to a particular package manager. e.g. ```json { - "packageRules": [ - { - "matchPackageNames": ["node"], - "matchManagers": ["dockerfile"], - "enabled": false - } - ] + "packageRules": [ + { + "matchPackageNames": ["node"], + "matchManagers": ["dockerfile"], + "enabled": false + } + ] } ``` @@ -2875,13 +2875,13 @@ This option is matched against the `newValue` field of a dependency. ```json { - "packageRules": [ - { - "matchPackagePatterns": ["io.github.resilience4j"], - "matchNewValue": "1.*", - "automerge": true - } - ] + "packageRules": [ + { + "matchPackagePatterns": ["io.github.resilience4j"], + "matchNewValue": "1.*", + "automerge": true + } + ] } ``` @@ -2889,12 +2889,12 @@ Regular Expressions must begin and end with `/`. ```json { - "packageRules": [ - { - "matchPackageNames": ["io.github.resilience4j**"], - "matchNewValue": "/^1\\./" - } - ] + "packageRules": [ + { + "matchPackageNames": ["io.github.resilience4j**"], + "matchNewValue": "/^1\\./" + } + ] } ``` @@ -2903,12 +2903,12 @@ Use the syntax `!/ /` like this: ```json { - "packageRules": [ - { - "matchPackageNames": ["io.github.resilience4j**"], - "matchNewValue": "!/^0\\./" - } - ] + "packageRules": [ + { + "matchPackageNames": ["io.github.resilience4j**"], + "matchNewValue": "!/^0\\./" + } + ] } ``` @@ -2924,13 +2924,13 @@ Note that Glob matching (including exact name matching) is case-insensitive. ```json title="exact name match" { - "packageRules": [ - { - "matchDatasources": ["npm"], - "matchPackageNames": ["angular"], - "rangeStrategy": "pin" - } - ] + "packageRules": [ + { + "matchDatasources": ["npm"], + "matchPackageNames": ["angular"], + "rangeStrategy": "pin" + } + ] } ``` @@ -2938,12 +2938,12 @@ The above will configure `rangeStrategy` to `pin` only for the npm package `angu ```json title="prefix match using Glob" { - "packageRules": [ - { - "matchPackagePatterns": ["^angular", "!@angular/abc"], - "rangeStrategy": "replace" - } - ] + "packageRules": [ + { + "matchPackagePatterns": ["^angular", "!@angular/abc"], + "rangeStrategy": "replace" + } + ] } ``` @@ -2951,13 +2951,13 @@ The above will set a replaceStrategy for any npm package which starts with `@ang ```json title="pattern match using RegEx" { - "packageRules": [ - { - "matchDatasources": ["npm"], - "matchPackageNames": ["/^angular/"], - "groupName": "Angular" - } - ] + "packageRules": [ + { + "matchDatasources": ["npm"], + "matchPackageNames": ["/^angular/"], + "groupName": "Angular" + } + ] } ``` @@ -2971,12 +2971,12 @@ Here's an example of where you use this to group together all packages from the ```json { - "packageRules": [ - { - "matchSourceUrls": ["https://github.com/vuejs/vue"], - "groupName": "Vue monorepo packages" - } - ] + "packageRules": [ + { + "matchSourceUrls": ["https://github.com/vuejs/vue"], + "groupName": "Vue monorepo packages" + } + ] } ``` @@ -2989,12 +2989,12 @@ For example to apply a special label to `major` updates: ```json { - "packageRules": [ - { - "matchUpdateTypes": ["major"], - "labels": ["UPDATE-MAJOR"] - } - ] + "packageRules": [ + { + "matchUpdateTypes": ["major"], + "labels": ["UPDATE-MAJOR"] + } + ] } ``` @@ -3011,12 +3011,12 @@ Tokens can be configured via `hostRules` using the `"merge-confidence"` `hostTyp ```json { - "hostRules": [ - { - "hostType": "merge-confidence", - "token": "********" - } - ] + "hostRules": [ + { + "hostType": "merge-confidence", + "token": "********" + } + ] } ``` @@ -3040,16 +3040,16 @@ Here's an example of how you would define PR priority so that `devDependencies` ```json { - "packageRules": [ - { - "matchDepTypes": ["devDependencies"], - "prPriority": -1 - }, - { - "matchPackageNames": ["react"], - "prPriority": 5 - } - ] + "packageRules": [ + { + "matchDepTypes": ["devDependencies"], + "prPriority": -1 + }, + { + "matchPackageNames": ["react"], + "prPriority": 5 + } + ] } ``` @@ -3060,14 +3060,14 @@ We're working to support more managers, subscribe to issue [renovatebot/renovate Managers which do not support replacement: -- `bazel` -- `git-submodules` -- `gomod` -- `gradle` -- `homebrew` -- `maven` -- `regex` -- `sbt` +- `bazel` +- `git-submodules` +- `gomod` +- `gradle` +- `homebrew` +- `maven` +- `regex` +- `sbt` Use the `replacementName` config option to set the name of a replacement package. @@ -3089,13 +3089,13 @@ For example, the following package rule can be used to replace the registry for ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNames": ["docker.io/**"], - "replacementNameTemplate": "{{{replace 'docker\\.io/' 'ghcr.io/' packageName}}}" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNames": ["docker.io/**"], + "replacementNameTemplate": "{{{replace 'docker\\.io/' 'ghcr.io/' packageName}}}" + } + ] } ``` @@ -3103,20 +3103,20 @@ Or, to add a registry prefix to any `docker` images that do not contain an expli ```json { - "packageRules": [ - { - "description": "official images", - "matchDatasources": ["docker"], - "matchPackageNames": ["/^[a-z-]+$/"], - "replacementNameTemplate": "some.registry.org/library/{{{packageName}}}" - }, - { - "description": "non-official images", - "matchDatasources": ["docker"], - "matchPackageNames": ["/^[a-z-]+/[a-z-]+$/"], - "replacementNameTemplate": "some.registry.org/{{{packageName}}}" - } - ] + "packageRules": [ + { + "description": "official images", + "matchDatasources": ["docker"], + "matchPackageNames": ["/^[a-z-]+$/"], + "replacementNameTemplate": "some.registry.org/library/{{{packageName}}}" + }, + { + "description": "non-official images", + "matchDatasources": ["docker"], + "matchPackageNames": ["/^[a-z-]+/[a-z-]+$/"], + "replacementNameTemplate": "some.registry.org/{{{packageName}}}" + } + ] } ``` @@ -3132,14 +3132,14 @@ For example to replace the npm package `jade` with version `2.0.0` of the packag ```json { - "packageRules": [ - { - "matchDatasources": ["npm"], - "matchPackageNames": ["jade"], - "replacementName": "pug", - "replacementVersion": "2.0.0" - } - ] + "packageRules": [ + { + "matchDatasources": ["npm"], + "matchPackageNames": ["jade"], + "replacementName": "pug", + "replacementVersion": "2.0.0" + } + ] } ``` @@ -3149,13 +3149,13 @@ Use this field to set the directory in which the package is present at the sourc ```json title="Setting the source directory for the kube-prometheus package from bitnami charts repo" { - "packageRules": [ - { - "matchPackageNames": ["dummy"], - "sourceUrl": "https://github.com/bitnami/charts", - "sourceDirectory": "bitnami/kube-prometheus" - } - ] + "packageRules": [ + { + "matchPackageNames": ["dummy"], + "sourceUrl": "https://github.com/bitnami/charts", + "sourceDirectory": "bitnami/kube-prometheus" + } + ] } ``` @@ -3170,12 +3170,12 @@ Source URLs are necessary to link to the source of the package and in order to l ```json title="Setting the source URL for the dummy package" { - "packageRules": [ - { - "matchPackageNames": ["dummy"], - "sourceUrl": "https://github.com/org/dummy" - } - ] + "packageRules": [ + { + "matchPackageNames": ["dummy"], + "sourceUrl": "https://github.com/org/dummy" + } + ] } ``` @@ -3268,11 +3268,11 @@ e.g. ```json { - "postUpgradeTasks": { - "commands": ["tslint --fix"], - "fileFilters": ["yarn.lock", "**/*.js"], - "executionMode": "update" - } + "postUpgradeTasks": { + "commands": ["tslint --fix"], + "fileFilters": ["yarn.lock", "**/*.js"], + "executionMode": "update" + } } ``` @@ -3308,14 +3308,14 @@ Use this array to provide a list of column names you wish to include in the PR t ```json title="Adding the package file name to the table" { - "prBodyColumns": [ - "Package", - "Update", - "Type", - "New value", - "Package file", - "References" - ] + "prBodyColumns": [ + "Package", + "Update", + "Type", + "New value", + "Package file", + "References" + ] } ``` @@ -3327,29 +3327,29 @@ Use this array to provide a list of column names you wish to include in the PR t You can configure this object to either: -- modify the template for an existing table column in PR bodies, or -- _add_ a definition for a new/additional column. +- modify the template for an existing table column in PR bodies, or +- _add_ a definition for a new/additional column. ```json title="Modifying the default value for the Package column to put it inside a code block" { - "prBodyDefinitions": { - "Package": "`{{{depName}}}`" - } + "prBodyDefinitions": { + "Package": "`{{{depName}}}`" + } } ``` ```json title="Adding a custom Sourcegraph column definition" { - "prBodyDefinitions": { - "Sourcegraph": "[![code search for \"{{{depName}}}\"](https://sourcegraph.com/search/badge?q=repo:%5Egithub%5C.com/{{{repository}}}%24+case:yes+-file:package%28-lock%29%3F%5C.json+{{{depName}}}&label=matches)](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/{{{repository}}}%24+case:yes+-file:package%28-lock%29%3F%5C.json+{{{depName}}})" - }, - "prBodyColumns": [ - "Package", - "Update", - "New value", - "References", - "Sourcegraph" - ] + "prBodyDefinitions": { + "Sourcegraph": "[![code search for \"{{{depName}}}\"](https://sourcegraph.com/search/badge?q=repo:%5Egithub%5C.com/{{{repository}}}%24+case:yes+-file:package%28-lock%29%3F%5C.json+{{{depName}}}&label=matches)](https://sourcegraph.com/search?q=repo:%5Egithub%5C.com/{{{repository}}}%24+case:yes+-file:package%28-lock%29%3F%5C.json+{{{depName}}})" + }, + "prBodyColumns": [ + "Package", + "Update", + "New value", + "References", + "Sourcegraph" + ] } ``` @@ -3363,7 +3363,9 @@ Use this field to add custom content inside PR bodies, including conditionally. ```json title="Adding an extra Warning to major updates" { - "prBodyNotes": ["{{#if isMajor}}:warning: MAJOR MAJOR MAJOR :warning:{{/if}}"] + "prBodyNotes": [ + "{{#if isMajor}}:warning: MAJOR MAJOR MAJOR :warning:{{/if}}" + ] } ``` @@ -3371,14 +3373,14 @@ Use this field to add custom content inside PR bodies, including conditionally. The available sections are: -- `header` -- `table` -- `warnings` -- `notes` -- `changelogs` -- `configDescription` -- `controls` -- `footer` +- `header` +- `table` +- `warnings` +- `notes` +- `changelogs` +- `configDescription` +- `controls` +- `footer` ## prConcurrentLimit @@ -3395,10 +3397,10 @@ This limit is enforced on a per-repository basis. This setting tells Renovate _when_ to create PRs: -- `immediate` (default): Renovate creates PRs immediately after creating the corresponding branch -- `not-pending`: Renovate waits until status checks have completed (passed or failed) before raising the PR -- `status-success`: Renovate only creates PRs if/when the the test pass -- `approval`: Renovate creates branches for updates immediately, but creates the PR _after_ getting Dependency Dashboard approval +- `immediate` (default): Renovate creates PRs immediately after creating the corresponding branch +- `not-pending`: Renovate waits until status checks have completed (passed or failed) before raising the PR +- `status-success`: Renovate only creates PRs if/when the the test pass +- `approval`: Renovate creates branches for updates immediately, but creates the PR _after_ getting Dependency Dashboard approval When prCreation is set to `immediate`, you'll get a Pull Request and possible associated notification right away when a new update is available. You'll have to wait until the checks have been performed, before you can decide if you want to merge the PR. @@ -3441,8 +3443,8 @@ What may happen if you don't set a `prHourlyLimit`: The above may cause: -- Renovate bot's PRs to overwhelm your CI systems -- a lot of test runs, because branches are rebased each time you merge a PR +- Renovate bot's PRs to overwhelm your CI systems +- a lot of test runs, because branches are rebased each time you merge a PR To prevent these problems you can set `prHourlyLimit` to a value like `1` or `2`. Renovate will only create that many PRs within each hourly period (`:00` through `:59`). @@ -3495,13 +3497,13 @@ Defaults to `true`. Behavior: -- `auto` = Renovate decides (this will be done on a manager-by-manager basis) -- `pin` = convert ranges to exact versions, e.g. `^1.0.0` -> `1.1.0` -- `bump` = e.g. bump the range even if the new version satisfies the existing range, e.g. `^1.0.0` -> `^1.1.0` -- `replace` = Replace the range with a newer one if the new version falls outside it, and update nothing otherwise -- `widen` = Widen the range with newer one, e.g. `^1.0.0` -> `^1.0.0 || ^2.0.0` -- `update-lockfile` = Update the lock file when in-range updates are available, otherwise `replace` for updates out of range. Works for `bundler`, `cargo`, `composer`, `npm`, `yarn`, `pnpm`, `terraform` and `poetry` so far -- `in-range-only` = Update the lock file when in-range updates are available, ignore package file updates +- `auto` = Renovate decides (this will be done on a manager-by-manager basis) +- `pin` = convert ranges to exact versions, e.g. `^1.0.0` -> `1.1.0` +- `bump` = e.g. bump the range even if the new version satisfies the existing range, e.g. `^1.0.0` -> `^1.1.0` +- `replace` = Replace the range with a newer one if the new version falls outside it, and update nothing otherwise +- `widen` = Widen the range with newer one, e.g. `^1.0.0` -> `^1.0.0 || ^2.0.0` +- `update-lockfile` = Update the lock file when in-range updates are available, otherwise `replace` for updates out of range. Works for `bundler`, `cargo`, `composer`, `npm`, `yarn`, `pnpm`, `terraform` and `poetry` so far +- `in-range-only` = Update the lock file when in-range updates are available, ignore package file updates Renovate's `"auto"` strategy works like this for npm: @@ -3532,15 +3534,15 @@ By default this label is `"rebase"` but you can configure it to anything you wan Possible values and meanings: -- `auto`: Renovate will autodetect the best setting. It will use `behind-base-branch` if configured to automerge or repository has been set to require PRs to be up to date. Otherwise, `conflicted` will be used instead -- `never`: Renovate will never rebase the branch or update it unless manually requested -- `conflicted`: Renovate will rebase only if the branch is conflicted -- `behind-base-branch`: Renovate will rebase whenever the branch falls 1 or more commit behind its base branch +- `auto`: Renovate will autodetect the best setting. It will use `behind-base-branch` if configured to automerge or repository has been set to require PRs to be up to date. Otherwise, `conflicted` will be used instead +- `never`: Renovate will never rebase the branch or update it unless manually requested +- `conflicted`: Renovate will rebase only if the branch is conflicted +- `behind-base-branch`: Renovate will rebase whenever the branch falls 1 or more commit behind its base branch `rebaseWhen=conflicted` is not recommended if you have enabled Renovate automerge, because: -- It could result in a broken base branch if two updates are merged one after another without testing the new versions together -- If you have enforced that PRs must be up-to-date before merging (e.g. using branch protection on GitHub), then automerge won't be possible as soon as a PR gets out-of-date but remains non-conflicted +- It could result in a broken base branch if two updates are merged one after another without testing the new versions together +- If you have enforced that PRs must be up-to-date before merging (e.g. using branch protection on GitHub), then automerge won't be possible as soon as a PR gets out-of-date but remains non-conflicted It is also recommended to avoid `rebaseWhen=never` as it can result in conflicted branches with outdated PR descriptions and/or status checks. @@ -3555,15 +3557,15 @@ For example the Webpack 3.x case described in the [`separateMajorMinor`](#separa You can use `recreateWhen` to customize this behavior down to a per-package level. For example we override it to `always` in the following cases where branch names and PR titles must be reused: -- Package groups -- When pinning versions -- Lock file maintenance +- Package groups +- When pinning versions +- Lock file maintenance You can select which behavior you want from Renovate: -- `always`: Recreates all closed or blocking PRs -- `auto`: The default option. Recreates only [immortal PRs](./key-concepts/pull-requests.md#immortal-prs) (default) -- `never`: No PR is recreated, doesn't matter if it is immortal or not +- `always`: Recreates all closed or blocking PRs +- `auto`: The default option. Recreates only [immortal PRs](./key-concepts/pull-requests.md#immortal-prs) (default) +- `never`: No PR is recreated, doesn't matter if it is immortal or not We recommend that you stick with the default setting for this option. Only change this setting if you really need to. @@ -3574,38 +3576,38 @@ You can use the `registryAliases` object to set registry aliases. This feature works with the following managers: -- [`ansible`](modules/manager/ansible/index.md) -- [`bitbucket-pipelines`](modules/manager/bitbucket-pipelines/index.md) -- [`docker-compose`](modules/manager/docker-compose/index.md) -- [`dockerfile`](modules/manager/dockerfile/index.md) -- [`droneci`](modules/manager/droneci/index.md) -- [`flux`](modules/manager/flux/index.md) -- [`gitlabci`](modules/manager/gitlabci/index.md) -- [`helm-requirements`](modules/manager/helm-requirements/index.md) -- [`helm-values`](modules/manager/helm-values/index.md) -- [`helmfile`](modules/manager/helmfile/index.md) -- [`helmv3`](modules/manager/helmv3/index.md) -- [`kubernetes`](modules/manager/kubernetes/index.md) -- [`terraform`](modules/manager/terraform/index.md) -- [`woodpecker`](modules/manager/woodpecker/index.md) +- [`ansible`](modules/manager/ansible/index.md) +- [`bitbucket-pipelines`](modules/manager/bitbucket-pipelines/index.md) +- [`docker-compose`](modules/manager/docker-compose/index.md) +- [`dockerfile`](modules/manager/dockerfile/index.md) +- [`droneci`](modules/manager/droneci/index.md) +- [`flux`](modules/manager/flux/index.md) +- [`gitlabci`](modules/manager/gitlabci/index.md) +- [`helm-requirements`](modules/manager/helm-requirements/index.md) +- [`helm-values`](modules/manager/helm-values/index.md) +- [`helmfile`](modules/manager/helmfile/index.md) +- [`helmv3`](modules/manager/helmv3/index.md) +- [`kubernetes`](modules/manager/kubernetes/index.md) +- [`terraform`](modules/manager/terraform/index.md) +- [`woodpecker`](modules/manager/woodpecker/index.md) ```json title="Setting generic aliases" { - "registryAliases": { - "jfrogecosystem": "some.jfrog.mirror", - "jfrog.com": "some.jfrog.mirror" - } + "registryAliases": { + "jfrogecosystem": "some.jfrog.mirror", + "jfrog.com": "some.jfrog.mirror" + } } ``` ```json title="Setting aliases for a specific Renovate manager only" { - "gitlabci": { - "registryAliases": { - "$HARBOR_HOST/$HARBOR_PROJECT": "registry.example.com/proxy", - "$HARBOR_HOST/tools": "registry.example.com/tools" + "gitlabci": { + "registryAliases": { + "$HARBOR_HOST/$HARBOR_PROJECT": "registry.example.com/proxy", + "$HARBOR_HOST/tools": "registry.example.com/tools" + } } - } } ``` @@ -3616,12 +3618,12 @@ In case there is a need to configure them manually, it can be done using this `r ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "registryUrls": ["https://docker.mycompany.domain"] - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "registryUrls": ["https://docker.mycompany.domain"] + } + ] } ``` @@ -3647,7 +3649,7 @@ Say the full team name on GitHub is `@organization/foo`, then you'd set the conf ```json { - "reviewers": ["team:foo"] + "reviewers": ["team:foo"] } ``` @@ -3659,7 +3661,7 @@ For example: if the username or team name is `bar` then you would set the config ```json { - "reviewers": ["required:bar"] + "reviewers": ["required:bar"] } ``` @@ -3669,9 +3671,9 @@ If enabled Renovate tries to determine PR reviewers by matching rules defined in Read the docs for your platform for details on syntax and allowed file locations: -- [GitHub Docs, About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) -- [GitLab, Code Owners](https://docs.gitlab.com/ee/user/project/code_owners.html) -- [Bitbucket, Set up and use code owners](https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/) +- [GitHub Docs, About code owners](https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners) +- [GitLab, Code Owners](https://docs.gitlab.com/ee/user/project/code_owners.html) +- [Bitbucket, Set up and use code owners](https://support.atlassian.com/bitbucket-cloud/docs/set-up-and-use-code-owners/) ## reviewersSampleSize @@ -3726,7 +3728,7 @@ You could then configure a schedule like this at the repository level: ```json { - "schedule": ["after 10pm and before 5am every weekday", "every weekend"] + "schedule": ["after 10pm and before 5am every weekday", "every weekend"] } ``` @@ -3738,12 +3740,12 @@ To restrict `aws-sdk` to only monthly updates, you could add this package rule: ```json { - "packageRules": [ - { - "matchPackageNames": ["aws-sdk"], - "extends": ["schedule:monthly"] - } - ] + "packageRules": [ + { + "matchPackageNames": ["aws-sdk"], + "extends": ["schedule:monthly"] + } + ] } ``` @@ -3809,8 +3811,8 @@ If you want to enforce grouped package updates, you need to set this option to ` By default, Renovate groups `patch` (`1.0.x`) and `minor` (`1.x.0`) releases into a single PR. For example: you are running version `1.0.0` of a package, which has two updates: -- `1.0.1`, a `patch` type update -- `1.1.0`, a `minor` type update +- `1.0.1`, a `patch` type update +- `1.1.0`, a `minor` type update By default, Renovate creates a single PR for the `1.1.0` version. @@ -3848,10 +3850,10 @@ This option is mergeable, which means you only have to specify the status checks ```json title="Example of overriding status check strings" { - "statusCheckNames": { - "minimumReleaseAge": "custom/stability-days", - "mergeConfidence": "custom/merge-confidence-level" - } + "statusCheckNames": { + "minimumReleaseAge": "custom/stability-days", + "mergeConfidence": "custom/merge-confidence-level" + } } ``` @@ -3866,7 +3868,7 @@ You can set your own label name with the `"stopUpdatingLabel"` field: ```json { - "stopUpdatingLabel": "take-a-break-renovate" + "stopUpdatingLabel": "take-a-break-renovate" } ``` @@ -3877,7 +3879,7 @@ For example: ```json { - "suppressNotifications": ["prIgnoreNotification"] + "suppressNotifications": ["prIgnoreNotification"] } ``` @@ -3925,21 +3927,21 @@ If you want, you can change the text in the comment with the `userStrings` confi You can edit these user-facing strings: -- `ignoreDigest`: Text of the PR comment for digest upgrades. -- `ignoreMajor`: Text of the PR comment for major upgrades. -- `ignoreOther`: Text of the PR comment for other (neither digest nor major) upgrades. -- `ignoreTopic`: Topic of the PR comment. +- `ignoreDigest`: Text of the PR comment for digest upgrades. +- `ignoreMajor`: Text of the PR comment for major upgrades. +- `ignoreOther`: Text of the PR comment for other (neither digest nor major) upgrades. +- `ignoreTopic`: Topic of the PR comment. For example: ```json { - "userStrings": { - "ignoreTopic": "Custom topic for PR comment", - "ignoreMajor": "Custom text for major upgrades.", - "ignoreDigest": "Custom text for digest upgrades.", - "ignoreOther": "Custom text for other upgrades." - } + "userStrings": { + "ignoreTopic": "Custom topic for PR comment", + "ignoreMajor": "Custom text for major upgrades.", + "ignoreDigest": "Custom text for digest upgrades.", + "ignoreOther": "Custom text for other upgrades." + } } ``` @@ -3950,27 +3952,27 @@ It's typically used with docker and tags datasources. Here are two examples: -- The image tag `ghcr.io/umami-software/umami:postgresql-v1.37.0` embeds text like `postgresql-` as a prefix to the actual version to differentiate different DB types. -- Docker image tags like `node:18.10.0-alpine` embed the base image as a suffix to the version. +- The image tag `ghcr.io/umami-software/umami:postgresql-v1.37.0` embeds text like `postgresql-` as a prefix to the actual version to differentiate different DB types. +- Docker image tags like `node:18.10.0-alpine` embed the base image as a suffix to the version. Here is an example of solving these types of cases: ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNames": ["ghcr.io/umami-software/umami"], - "versionCompatibility": "^(?.*)-(?.*)$", - "versioning": "semver" - }, - { - "matchDatasources": ["docker"], - "matchPackageNames": ["node"], - "versionCompatibility": "^(?[^-]+)(?-.*)?$", - "versioning": "node" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNames": ["ghcr.io/umami-software/umami"], + "versionCompatibility": "^(?.*)-(?.*)$", + "versioning": "semver" + }, + { + "matchDatasources": ["docker"], + "matchPackageNames": ["node"], + "versionCompatibility": "^(?[^-]+)(?-.*)?$", + "versioning": "node" + } + ] } ``` @@ -3987,8 +3989,8 @@ Renovate applies this compatibility check to datasource lookup results by passin For a new version to be allowed, it must: -- Satisfy the `versionCompatibility` regex, and -- Have the same `compatibility` part as the `currentValue` +- Satisfy the `versionCompatibility` regex, and +- Have the same `compatibility` part as the `currentValue` At this point, Renovate's core lookup logic is comparing versions to versions, and ignoring compatibility strings like `-jre8`. Finally, once updates are decided, Renovate restores the compatibility part to the `newValue` result. @@ -4027,11 +4029,11 @@ You may use the `vulnerabilityAlerts` configuration object to customize vulnerab ```json title="Setting a custom label and assignee" { - "vulnerabilityAlerts": { - "labels": ["security"], - "automerge": true, - "assignees": ["@rarkins"] - } + "vulnerabilityAlerts": { + "labels": ["security"], + "automerge": true, + "assignees": ["@rarkins"] + } } ``` @@ -4050,9 +4052,9 @@ To disable the vulnerability alerts feature, set `enabled=false` in a `vulnerabi ```json title="Disabling vulnerability alerts" { - "vulnerabilityAlerts": { - "enabled": false - } + "vulnerabilityAlerts": { + "enabled": false + } } ``` diff --git a/docs/usage/configuration-templates.md b/docs/usage/configuration-templates.md index c37f45a28e2bce..ca27f6ab75c8f5 100644 --- a/docs/usage/configuration-templates.md +++ b/docs/usage/configuration-templates.md @@ -52,8 +52,8 @@ It can be empty in some cases, like if the action/topic doesn't change a package `commitMessageSuffix` defaults to empty but is currently used in two cases: -- Differentiating major from non-major groups -- Differentiating between PRs from different base branches, maybe for `major` updates you always want the PR to end with `(MAJOR)`, for instance +- Differentiating major from non-major groups +- Differentiating between PRs from different base branches, maybe for `major` updates you always want the PR to end with `(MAJOR)`, for instance `commitBody` is used if you wish to add multi-line commit messages, such as for the `Signed-off-by` fields, or adding `[skip-ci]`, etc. It is appended to the generated `commitMessage`, separated by a newline. @@ -67,8 +67,8 @@ If you have a requirement where `prTitle` should be different from `commitMessag You can change the PR body in the following ways: -- Change the entire layout/flow by using `prBodyTemplate` (we do not recommend this) -- Add a header by using `prHeader` -- Add a footer by using `prFooter` -- Add a note by using `prBodyNotes` -- Edit the embedded table by using `prBodyDefinitions` and `prBodyColumns` +- Change the entire layout/flow by using `prBodyTemplate` (we do not recommend this) +- Add a header by using `prHeader` +- Add a footer by using `prFooter` +- Add a note by using `prBodyNotes` +- Edit the embedded table by using `prBodyDefinitions` and `prBodyColumns` diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md index 8cd9129b835204..cf48b78a5c0132 100644 --- a/docs/usage/dependency-pinning.md +++ b/docs/usage/dependency-pinning.md @@ -113,10 +113,10 @@ In that case if the `pg` package has a minor or patch update and passes all test In the above suggestion of Pull Request automerging, you might still find it annoying if you get GitHub Notifications for every PR that is created and merged. In that case, you could set `automergeType` to `branch`, which means Renovate will: -- Create a new branch for testing -- Wait until after tests have completed -- Push the commit directly to `main` if tests pass, or -- Raise a PR only if tests failed +- Create a new branch for testing +- Wait until after tests have completed +- Push the commit directly to `main` if tests pass, or +- Raise a PR only if tests failed With this approach, updates will be essentially "silent" - causing no notifications - but you will be able to see each commit on `main` of course. @@ -127,8 +127,8 @@ And worse still, npm package versions that are less than 24 hours [can be unpubl So to reduce the interruptions of automated dependency updates, consider putting Renovate on a schedule, such as: -- Update only on weekends? This way you update packages at most once per week, _and_ your CI build runners are likely to be idle anyway -- Update daily, but between midnight and 5am? This way developers aren't bothered by notifications when they're working, _and_ you're keeping the build machines free for the developers +- Update only on weekends? This way you update packages at most once per week, _and_ your CI build runners are likely to be idle anyway +- Update daily, but between midnight and 5am? This way developers aren't bothered by notifications when they're working, _and_ you're keeping the build machines free for the developers To learn all about controlling Renovate's schedule, read the [key concepts, scheduling](./key-concepts/scheduling.md) docs. diff --git a/docs/usage/docker.md b/docs/usage/docker.md index 33bc9277ef2906..64d7fcc410e296 100644 --- a/docs/usage/docker.md +++ b/docs/usage/docker.md @@ -7,12 +7,12 @@ description: Docker Package Manager Support in Renovate Renovate supports upgrading dependencies in various types of Docker definition files: -- Docker's `Dockerfile` files -- Docker Compose `docker-compose.yml`, `compose.yml` files -- Visual Studio Code dev containers and GitHub Codespaces images and features -- CircleCI config files -- Kubernetes manifest files -- Ansible configuration files +- Docker's `Dockerfile` files +- Docker Compose `docker-compose.yml`, `compose.yml` files +- Visual Studio Code dev containers and GitHub Codespaces images and features +- CircleCI config files +- Kubernetes manifest files +- Ansible configuration files ## How It Works @@ -41,13 +41,13 @@ You could then use this `packageRules` array, to tell Renovate to use `semver` v ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNames": ["foo/bar"], - "versioning": "semver" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNames": ["foo/bar"], + "versioning": "semver" + } + ] } ``` @@ -55,13 +55,13 @@ Another example is the official `python` image, which follows `pep440` versionin ```json title="Telling Renovate to use the pep440 versioning scheme" { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNames": ["python"], - "versioning": "pep440" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNames": ["python"], + "versioning": "pep440" + } + ] } ``` @@ -154,11 +154,11 @@ For example, to disable digest updates for Docker Compose only but leave them fo ```json { - "docker-compose": { - "digest": { - "enabled": false + "docker-compose": { + "digest": { + "enabled": false + } } - } } ``` @@ -174,8 +174,8 @@ Add all paths to ignore into the `ignorePaths` configuration field. e.g. ```json { - "extends": ["config:recommended"], - "ignorePaths": ["docker/old-files/"] + "extends": ["config:recommended"], + "ignorePaths": ["docker/old-files/"] } ``` @@ -204,13 +204,13 @@ The Docker Hub password is stored in a process environment variable. ```js title="config.js" module.exports = { - hostRules: [ - { - hostType: 'docker', - username: '', - password: process.env.DOCKER_HUB_PASSWORD, - }, - ], + hostRules: [ + { + hostType: 'docker', + username: '', + password: process.env.DOCKER_HUB_PASSWORD, + }, + ], }; ``` @@ -224,14 +224,14 @@ In this example you would configure a specific Docker host like this: ```js module.exports = { - hostRules: [ - { - hostType: 'docker', - matchHost: 'your.host.io', - username: '', - password: process.env.SELF_HOSTED_DOCKER_IMAGES_PASSWORD, - }, - ], + hostRules: [ + { + hostType: 'docker', + matchHost: 'your.host.io', + username: '', + password: process.env.SELF_HOSTED_DOCKER_IMAGES_PASSWORD, + }, + ], }; ``` @@ -243,16 +243,16 @@ Renovate can authenticate with AWS ECR using AWS access key id & secret as the u ```json { - "hostRules": [ - { - "hostType": "docker", - "matchHost": "12345612312.dkr.ecr.us-east-1.amazonaws.com", - "username": "AKIAABCDEFGHIJKLMNOPQ", - "encrypted": { - "password": "w...A" - } - } - ] + "hostRules": [ + { + "hostType": "docker", + "matchHost": "12345612312.dkr.ecr.us-east-1.amazonaws.com", + "username": "AKIAABCDEFGHIJKLMNOPQ", + "encrypted": { + "password": "w...A" + } + } + ] } ``` @@ -264,16 +264,16 @@ To make use of this authentication mechanism, specify the username as `AWS`: ```json { - "hostRules": [ - { - "hostType": "docker", - "matchHost": "12345612312.dkr.ecr.us-east-1.amazonaws.com", - "username": "AWS", - "encrypted": { - "password": "w...A" - } - } - ] + "hostRules": [ + { + "hostType": "docker", + "matchHost": "12345612312.dkr.ecr.us-east-1.amazonaws.com", + "username": "AWS", + "encrypted": { + "password": "w...A" + } + } + ] } ``` @@ -290,8 +290,8 @@ google-auth-library. To access the Google Container Registry (deprecated) or the Google Artifact Registry, use the JSON service account with `Basic` authentication, and use the: -- `_json_key` as username -- full Google Cloud Platform service account JSON as password +- `_json_key` as username +- full Google Cloud Platform service account JSON as password To avoid JSON-in-JSON wrapping, which can cause problems, encode the JSON service account beforehand. @@ -303,88 +303,88 @@ If all your dependencies are on the Google Artifact Registry, you can base64 enc 1. Base64 encode the service account credentials by running `cat service-account.json | base64` 1. Add the encoded service account to your configuration file - 1. If you want to add it to your self-hosted configuration file: - - ```json - { - "hostRules": [ - { - "matchHost": "europe-docker.pkg.dev", - "username": "_json_key_base64", - "password": "" - } - ] - } - ``` - - 1. If you want to add it to your repository Renovate configuration file, [encrypt](./configuration-options.md#encrypted) it and then add it: - - ```json - { - "hostRules": [ - { - "matchHost": "europe-docker.pkg.dev", - "username": "_json_key_base64", - "encrypted": { - "password": "" - } - } - ] - } - ``` + 1. If you want to add it to your self-hosted configuration file: + + ```json + { + "hostRules": [ + { + "matchHost": "europe-docker.pkg.dev", + "username": "_json_key_base64", + "password": "" + } + ] + } + ``` + + 1. If you want to add it to your repository Renovate configuration file, [encrypt](./configuration-options.md#encrypted) it and then add it: + + ```json + { + "hostRules": [ + { + "matchHost": "europe-docker.pkg.dev", + "username": "_json_key_base64", + "encrypted": { + "password": "" + } + } + ] + } + ``` If you have dependencies on Google Container Registry (and Artifact Registry) you need to use `_json_key` and a slightly different encoding: 1. Download your JSON service account and store it on your machine. Make sure that the service account has `read` (and only `read`) permissions to your artifacts 1. Open the file and prefix the content with `_json_key:`. The file should look like this: - ``` - _json_key:{ - "type": "service_account", - "project_id": "sample-project", - "private_key_id": "5786ff7e615522b932a2a37b4a6f9645c4316dbd", - "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDaOkxZut9uDUHV\n...\n/PWs0Wa2z5+IawMD7nO63+b6\n-----END PRIVATE KEY-----\n", - "client_email": "renovate-lookup@sample-project.iam.gserviceaccount.com", - "client_id": "115429165445403928973", - "auth_uri": "https://accounts.google.com/o/oauth2/auth", - "token_uri": "https://oauth2.googleapis.com/token", - "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", - "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/renovate-lookup%40sample-project.iam.gserviceaccount.com" - } - ``` + ``` + _json_key:{ + "type": "service_account", + "project_id": "sample-project", + "private_key_id": "5786ff7e615522b932a2a37b4a6f9645c4316dbd", + "private_key": "-----BEGIN PRIVATE KEY-----\nMIIEvgIBADANBgkqhkiG9w0BAQEFAASCBKgwggSkAgEAAoIBAQDaOkxZut9uDUHV\n...\n/PWs0Wa2z5+IawMD7nO63+b6\n-----END PRIVATE KEY-----\n", + "client_email": "renovate-lookup@sample-project.iam.gserviceaccount.com", + "client_id": "115429165445403928973", + "auth_uri": "https://accounts.google.com/o/oauth2/auth", + "token_uri": "https://oauth2.googleapis.com/token", + "auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs", + "client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/renovate-lookup%40sample-project.iam.gserviceaccount.com" + } + ``` 1. Base64 encode the prefixed service account credentials by running `cat prefixed-service-account.json | base64` 1. Add the prefixed and encoded service account to your configuration file - 1. If you want to add it to your self-hosted configuration file: - - ```json - { - "hostRules": [ - { - "matchHost": "europe-docker.pkg.dev", - "authType": "Basic", - "token": "" - } - ] - } - ``` - - 1. If you want to add it to your repository Renovate configuration file, [encrypt](./configuration-options.md#encrypted) it and then add it: - - ```json - { - "hostRules": [ - { - "matchHost": "europe-docker.pkg.dev", - "authType": "Basic", - "encrypted": { - "token": "" - } - } - ] - } - ``` + 1. If you want to add it to your self-hosted configuration file: + + ```json + { + "hostRules": [ + { + "matchHost": "europe-docker.pkg.dev", + "authType": "Basic", + "token": "" + } + ] + } + ``` + + 1. If you want to add it to your repository Renovate configuration file, [encrypt](./configuration-options.md#encrypted) it and then add it: + + ```json + { + "hostRules": [ + { + "matchHost": "europe-docker.pkg.dev", + "authType": "Basic", + "encrypted": { + "token": "" + } + } + ] + } + ``` ##### Using short-lived access tokens @@ -418,10 +418,10 @@ The configuration fragment to do that looks something like this: ```js hostRules: [ - { - matchHost: 'eu.gcr.io', - token: 'MyReallySecretTokenThatExpiresAfter60Minutes', - }, + { + matchHost: 'eu.gcr.io', + token: 'MyReallySecretTokenThatExpiresAfter60Minutes', + }, ]; ``` @@ -429,6 +429,6 @@ One way to provide the short-lived Google Access Token to Renovate is by generat ```yaml script: - - 'echo "module.exports = { hostRules: [ { matchHost: ''eu.gcr.io'', token: ''"$(gcloud auth print-access-token)"'' } ] };" > config.js' - - renovate $RENOVATE_EXTRA_FLAGS + - 'echo "module.exports = { hostRules: [ { matchHost: ''eu.gcr.io'', token: ''"$(gcloud auth print-access-token)"'' } ] };" > config.js' + - renovate $RENOVATE_EXTRA_FLAGS ``` diff --git a/docs/usage/examples/opentelemetry.md b/docs/usage/examples/opentelemetry.md index febbd31479377e..7d64eb44e2a22c 100644 --- a/docs/usage/examples/opentelemetry.md +++ b/docs/usage/examples/opentelemetry.md @@ -2,7 +2,7 @@ Requirements: -- docker-compose +- docker-compose ## Prepare setup @@ -11,73 +11,73 @@ Create a `docker-compose.yaml` and `otel-collector-config.yml` file as seen belo ```yaml title="docker-compose.yaml" version: '3' services: - # Jaeger - jaeger: - image: jaegertracing/all-in-one:1 - ports: - - '16686:16686' - - '4317' - - otel-collector: - image: otel/opentelemetry-collector-contrib:0.88.0 - command: ['--config=/etc/otel-collector-config.yml'] - volumes: - - ./otel-collector-config.yml:/etc/otel-collector-config.yml - ports: - - '1888:1888' # pprof extension - - '13133:13133' # health_check extension - - '55679:55679' # zpages extension - - '4318:4318' # OTLP HTTP - - '4317:4317' # OTLP GRPC - - '9123:9123' # Prometheus exporter - depends_on: - - jaeger + # Jaeger + jaeger: + image: jaegertracing/all-in-one:1 + ports: + - '16686:16686' + - '4317' + + otel-collector: + image: otel/opentelemetry-collector-contrib:0.88.0 + command: ['--config=/etc/otel-collector-config.yml'] + volumes: + - ./otel-collector-config.yml:/etc/otel-collector-config.yml + ports: + - '1888:1888' # pprof extension + - '13133:13133' # health_check extension + - '55679:55679' # zpages extension + - '4318:4318' # OTLP HTTP + - '4317:4317' # OTLP GRPC + - '9123:9123' # Prometheus exporter + depends_on: + - jaeger ``` ```yaml title="otel-collector-config.yml" receivers: - otlp: - protocols: - grpc: - http: + otlp: + protocols: + grpc: + http: exporters: - otlp/jaeger: - endpoint: jaeger:4317 - tls: - insecure: true - logging: - prometheus: - endpoint: '0.0.0.0:9123' + otlp/jaeger: + endpoint: jaeger:4317 + tls: + insecure: true + logging: + prometheus: + endpoint: '0.0.0.0:9123' processors: - batch: - spanmetrics: - metrics_exporter: prometheus - latency_histogram_buckets: [10ms, 100ms, 250ms, 1s, 30s, 1m, 5m] - dimensions: - - name: http.method - - name: http.status_code - - name: http.host - dimensions_cache_size: 1000 - aggregation_temporality: 'AGGREGATION_TEMPORALITY_CUMULATIVE' + batch: + spanmetrics: + metrics_exporter: prometheus + latency_histogram_buckets: [10ms, 100ms, 250ms, 1s, 30s, 1m, 5m] + dimensions: + - name: http.method + - name: http.status_code + - name: http.host + dimensions_cache_size: 1000 + aggregation_temporality: 'AGGREGATION_TEMPORALITY_CUMULATIVE' extensions: - health_check: - pprof: - zpages: + health_check: + pprof: + zpages: service: - extensions: [pprof, zpages, health_check] - pipelines: - traces: - receivers: [otlp] - exporters: [otlp/jaeger, logging] - processors: [spanmetrics, batch] - - metrics: - receivers: [otlp] - exporters: [prometheus] + extensions: [pprof, zpages, health_check] + pipelines: + traces: + receivers: [otlp] + exporters: [otlp/jaeger, logging] + processors: [spanmetrics, batch] + + metrics: + receivers: [otlp] + exporters: [prometheus] ``` Start setup using this command inside the folder containing the files created in the earlier steps: diff --git a/docs/usage/examples/self-hosting.md b/docs/usage/examples/self-hosting.md index a4753c12628653..9e98865a761911 100644 --- a/docs/usage/examples/self-hosting.md +++ b/docs/usage/examples/self-hosting.md @@ -50,29 +50,29 @@ The following is an example manifest of running Renovate against a GitHub Enterp apiVersion: batch/v1 kind: CronJob metadata: - name: renovate + name: renovate spec: - schedule: '@hourly' - concurrencyPolicy: Forbid - jobTemplate: - spec: - template: + schedule: '@hourly' + concurrencyPolicy: Forbid + jobTemplate: spec: - containers: - - name: renovate - # Update this to the latest available and then enable Renovate on - # the manifest - image: renovate/renovate:35.14.4 - args: - - user/repo - # Environment Variables - env: - - name: LOG_LEVEL - value: debug - envFrom: - - secretRef: - name: renovate-env - restartPolicy: Never + template: + spec: + containers: + - name: renovate + # Update this to the latest available and then enable Renovate on + # the manifest + image: renovate/renovate:35.14.4 + args: + - user/repo + # Environment Variables + env: + - name: LOG_LEVEL + value: debug + envFrom: + - secretRef: + name: renovate-env + restartPolicy: Never ``` And the `secret.yaml` that goes with it: @@ -81,16 +81,16 @@ And the `secret.yaml` that goes with it: apiVersion: v1 kind: Secret metadata: - name: renovate-env + name: renovate-env type: Opaque stringData: - GITHUB_COM_TOKEN: 'any-personal-user-token-for-github.aaakk.us.kg-for-fetching-changelogs' - # You can set RENOVATE_AUTODISCOVER to true to run Renovate on all repos you have push access to - RENOVATE_AUTODISCOVER: 'false' - RENOVATE_ENDPOINT: 'https://github.company.com/api/v3' - RENOVATE_GIT_AUTHOR: 'Renovate Bot ' - RENOVATE_PLATFORM: 'github' - RENOVATE_TOKEN: 'your-github-enterprise-renovate-user-token' + GITHUB_COM_TOKEN: 'any-personal-user-token-for-github.aaakk.us.kg-for-fetching-changelogs' + # You can set RENOVATE_AUTODISCOVER to true to run Renovate on all repos you have push access to + RENOVATE_AUTODISCOVER: 'false' + RENOVATE_ENDPOINT: 'https://github.company.com/api/v3' + RENOVATE_GIT_AUTHOR: 'Renovate Bot ' + RENOVATE_PLATFORM: 'github' + RENOVATE_TOKEN: 'your-github-enterprise-renovate-user-token' ``` A `config.json` file can be added to the manifest using a `ConfigMap` as shown in the following example (using a "dry run" in github.com): @@ -100,54 +100,54 @@ A `config.json` file can be added to the manifest using a `ConfigMap` as shown i apiVersion: v1 kind: ConfigMap metadata: - name: renovate-config + name: renovate-config data: - config.json: |- - { - "repositories": ["orgname/repo","username/repo"], - "dryRun" : "full" - } + config.json: |- + { + "repositories": ["orgname/repo","username/repo"], + "dryRun" : "full" + } --- apiVersion: batch/v1 kind: CronJob metadata: - name: renovate-bot + name: renovate-bot spec: - schedule: '@hourly' - concurrencyPolicy: Forbid - jobTemplate: - spec: - template: + schedule: '@hourly' + concurrencyPolicy: Forbid + jobTemplate: spec: - containers: - - image: renovate/renovate:35.14.4 - name: renovate-bot - env: # For illustration purposes, please use secrets. - - name: RENOVATE_PLATFORM - value: 'github' - - name: RENOVATE_TOKEN - value: 'some-token' - - name: RENOVATE_AUTODISCOVER - value: 'false' - - name: RENOVATE_BASE_DIR - value: '/tmp/renovate/' - - name: RENOVATE_CONFIG_FILE - value: '/opt/renovate/config.json' - - name: LOG_LEVEL - value: debug - volumeMounts: - - name: config-volume - mountPath: /opt/renovate/ - - name: work-volume - mountPath: /tmp/renovate/ - restartPolicy: Never - volumes: - - name: config-volume - configMap: - name: renovate-config - - name: work-volume - emptyDir: {} + template: + spec: + containers: + - image: renovate/renovate:35.14.4 + name: renovate-bot + env: # For illustration purposes, please use secrets. + - name: RENOVATE_PLATFORM + value: 'github' + - name: RENOVATE_TOKEN + value: 'some-token' + - name: RENOVATE_AUTODISCOVER + value: 'false' + - name: RENOVATE_BASE_DIR + value: '/tmp/renovate/' + - name: RENOVATE_CONFIG_FILE + value: '/opt/renovate/config.json' + - name: LOG_LEVEL + value: debug + volumeMounts: + - name: config-volume + mountPath: /opt/renovate/ + - name: work-volume + mountPath: /tmp/renovate/ + restartPolicy: Never + volumes: + - name: config-volume + configMap: + name: renovate-config + - name: work-volume + emptyDir: {} ``` ### CircleCI @@ -170,20 +170,20 @@ To share environment variables across projects, use [CircleCI Contexts](https:// ```yml title="This runs Renovate hourly, and looks for the self-hosted config file at renovate-config.js" version: '2.1' orbs: - renovate: daniel-shuy/renovate@2.2.0 + renovate: daniel-shuy/renovate@2.2.0 workflows: - renovate: - jobs: - - renovate/self-hosted: - config_file_path: renovate-config.js - nightly: - triggers: - - schedule: - cron: 0 * * * * - filters: - branches: - only: - - main + renovate: + jobs: + - renovate/self-hosted: + config_file_path: renovate-config.js + nightly: + triggers: + - schedule: + cron: 0 * * * * + filters: + branches: + only: + - main ``` #### Renovate config file validation when using CircleCI @@ -191,11 +191,11 @@ workflows: ```yml title="Validate your config as part of your workflow" version: '2.1' orbs: - renovate: daniel-shuy/renovate@2.2.0 + renovate: daniel-shuy/renovate@2.2.0 workflows: - lint: - jobs: - - renovate/validate-config + lint: + jobs: + - renovate/validate-config ``` ### GitLab CI/CD pipeline @@ -218,9 +218,9 @@ Renovate's cache, and the caches(s) for npm, Yarn, Composer, and so on, are stor If you don't want to use the default `tmp/renovate` directory you can: -- Set a value for `baseDir` in `config.js` -- Use an environment variable `RENOVATE_BASE_DIR` -- Use the CLI to pass a base directory: `--base-dir=` +- Set a value for `baseDir` in `config.js` +- Use an environment variable `RENOVATE_BASE_DIR` +- Use the CLI to pass a base directory: `--base-dir=` ### Overriding the default cache directory @@ -238,13 +238,13 @@ Create a Renovate config file, for example: ```js module.exports = { - endpoint: 'https://self-hosted.gitlab/api/v4/', - token: '**gitlab_token**', - platform: 'gitlab', - onboardingConfig: { - extends: ['config:recommended'], - }, - repositories: ['username/repo', 'orgname/repo'], + endpoint: 'https://self-hosted.gitlab/api/v4/', + token: '**gitlab_token**', + platform: 'gitlab', + onboardingConfig: { + extends: ['config:recommended'], + }, + repositories: ['username/repo', 'orgname/repo'], }; ``` @@ -304,13 +304,13 @@ It creates something like this: ```yml apiVersion: v1 data: - config: aG9zdCBnaXRsYWIuY29tCiAgSG9zdE5hbWUgZ2l0bGFiLmNvbQogIFN0cmljdEhvc3RLZXlDaGVja2luZyBubwogIElkZW50aXR5RmlsZSB+Ly5zc2gvaWRfcnNhCiAgVXNlciBnaXQ= - id_rsa: - id_rsa.pub: + config: aG9zdCBnaXRsYWIuY29tCiAgSG9zdE5hbWUgZ2l0bGFiLmNvbQogIFN0cmljdEhvc3RLZXlDaGVja2luZyBubwogIElkZW50aXR5RmlsZSB+Ly5zc2gvaWRfcnNhCiAgVXNlciBnaXQ= + id_rsa: + id_rsa.pub: kind: Secret metadata: - name: ssh-key-secret - namespace: + name: ssh-key-secret + namespace: ``` Then you need to add a Git author, and configure the mount volumes. @@ -321,64 +321,64 @@ The final configuration should look something like this: apiVersion: v1 kind: Namespace metadata: - name: + name: --- apiVersion: v1 kind: Secret metadata: - name: renovate-env - namespace: + name: renovate-env + namespace: type: Opaque stringData: - GITHUB_COM_TOKEN: 'any-personal-user-token-for-github.aaakk.us.kg-for-fetching-changelogs' - RENOVATE_AUTODISCOVER: 'false' - RENOVATE_ENDPOINT: 'https://github.company.com/api/v3' - RENOVATE_GIT_AUTHOR: 'Renovate Bot ' - RENOVATE_PLATFORM: 'github' - RENOVATE_TOKEN: 'your-github-enterprise-renovate-user-token' + GITHUB_COM_TOKEN: 'any-personal-user-token-for-github.aaakk.us.kg-for-fetching-changelogs' + RENOVATE_AUTODISCOVER: 'false' + RENOVATE_ENDPOINT: 'https://github.company.com/api/v3' + RENOVATE_GIT_AUTHOR: 'Renovate Bot ' + RENOVATE_PLATFORM: 'github' + RENOVATE_TOKEN: 'your-github-enterprise-renovate-user-token' --- apiVersion: v1 data: - config: aG9zdCBnaXRsYWIuY29tCiAgSG9zdE5hbWUgZ2l0bGFiLmNvbQogIFN0cmljdEhvc3RLZXlDaGVja2luZyBubwogIElkZW50aXR5RmlsZSB+Ly5zc2gvaWRfcnNhCiAgVXNlciBnaXQ= - id_rsa: - id_rsa.pub: + config: aG9zdCBnaXRsYWIuY29tCiAgSG9zdE5hbWUgZ2l0bGFiLmNvbQogIFN0cmljdEhvc3RLZXlDaGVja2luZyBubwogIElkZW50aXR5RmlsZSB+Ly5zc2gvaWRfcnNhCiAgVXNlciBnaXQ= + id_rsa: + id_rsa.pub: kind: Secret metadata: - name: ssh-key-secret - namespace: + name: ssh-key-secret + namespace: --- apiVersion: batch/v1beta1 kind: CronJob metadata: - name: renovate - namespace: + name: renovate + namespace: spec: - schedule: '@hourly' - concurrencyPolicy: Forbid - jobTemplate: - spec: - template: + schedule: '@hourly' + concurrencyPolicy: Forbid + jobTemplate: spec: - volumes: - - name: ssh-key-volume - secret: - secretName: ssh-key-secret - containers: - - name: renovate - # Update this to the latest available and then enable Renovate on the manifest - image: renovate/renovate:35.14.4 - volumeMounts: - - name: ssh-key-volume - readOnly: true - mountPath: '/home/ubuntu/.ssh' - args: - - - # Environment Variables - envFrom: - - secretRef: - name: renovate-env - restartPolicy: Never + template: + spec: + volumes: + - name: ssh-key-volume + secret: + secretName: ssh-key-secret + containers: + - name: renovate + # Update this to the latest available and then enable Renovate on the manifest + image: renovate/renovate:35.14.4 + volumeMounts: + - name: ssh-key-volume + readOnly: true + mountPath: '/home/ubuntu/.ssh' + args: + - + # Environment Variables + envFrom: + - secretRef: + name: renovate-env + restartPolicy: Never ``` ## Logging diff --git a/docs/usage/faq.md b/docs/usage/faq.md index 3ff913c2d72c84..633c6c0585a21d 100644 --- a/docs/usage/faq.md +++ b/docs/usage/faq.md @@ -9,22 +9,22 @@ description: Frequently Asked Questions for Renovate Configuration Renovate will: -- Look for configuration options in a configuration file (e.g. `renovate.json`) and in each `package.json` file -- Find and process all package files (e.g. `package.json`, `composer.json`, `Dockerfile`, etc) in each repository -- Use separate branches/PR for each dependency -- Use separate branches for each _major_ version of each dependency -- Pin devDependencies to a single version, rather than use ranges -- Pin dependencies to a single version if it appears not to be a library -- Update `yarn.lock` or `package-lock.json` files, if found -- Create Pull Requests immediately after branch creation +- Look for configuration options in a configuration file (e.g. `renovate.json`) and in each `package.json` file +- Find and process all package files (e.g. `package.json`, `composer.json`, `Dockerfile`, etc) in each repository +- Use separate branches/PR for each dependency +- Use separate branches for each _major_ version of each dependency +- Pin devDependencies to a single version, rather than use ranges +- Pin dependencies to a single version if it appears not to be a library +- Update `yarn.lock` or `package-lock.json` files, if found +- Create Pull Requests immediately after branch creation ## Which Renovate versions are officially supported? Only the latest version of Renovate is supported by the Renovate maintainers. The Renovate team only fixes bugs in an older version if: -- the Mend Renovate App needs to stay on that older major version for a short time, or -- some critical bug needs to be fixed and the new major is blocked +- the Mend Renovate App needs to stay on that older major version for a short time, or +- some critical bug needs to be fixed and the new major is blocked If you're using the Mend Renovate App, you don't need to do anything, as the Renovate maintainers update it regularly. If you're self hosting Renovate, use the latest release if possible. @@ -48,12 +48,12 @@ Follow these steps to see which version the Mend Renovate app is on: 1. Select the _Info_ Log Level from the dropdown menu 1. You should see something like this: - ``` - INFO: Repository started - { - "renovateVersion": "37.356.1" - } - ``` + ``` + INFO: Repository started + { + "renovateVersion": "37.356.1" + } + ``` !!! tip @@ -106,25 +106,25 @@ The basic idea is that you create a new `packageRules` entry and describe what k ```json title="Manually approve all major npm package manager updates" { - "packageRules": [ - { - "matchUpdateTypes": ["major"], - "matchManagers": ["npm"], - "dependencyDashboardApproval": true - } - ] + "packageRules": [ + { + "matchUpdateTypes": ["major"], + "matchManagers": ["npm"], + "dependencyDashboardApproval": true + } + ] } ``` ```json title="Manually approve all major Jest updates" { - "packageRules": [ - { - "matchPackageNames": ["jest"], - "matchUpdateTypes": ["major"], - "dependencyDashboardApproval": true - } - ] + "packageRules": [ + { + "matchPackageNames": ["jest"], + "matchUpdateTypes": ["major"], + "dependencyDashboardApproval": true + } + ] } ``` @@ -133,7 +133,7 @@ The `dependencyDashboardApproval` config option is outside of a `packageRules` a ```json { - "dependencyDashboardApproval": true + "dependencyDashboardApproval": true } ``` @@ -148,7 +148,7 @@ Add this line to the `renovate.json` file that's in the _default_ branch (`main` ```json { - "baseBranches": ["next"] + "baseBranches": ["next"] } ``` @@ -212,12 +212,12 @@ e.g. ```json { - "packageRules": [ - { - "matchPackageNames": ["abc"], - "assignees": ["importantreviewer"] - } - ] + "packageRules": [ + { + "matchPackageNames": ["abc"], + "assignees": ["importantreviewer"] + } + ] } ``` @@ -227,12 +227,12 @@ Do the same as above, but instead of an exact match, use a glob prefix: ```json { - "packageRules": [ - { - "matchPackageNames": "abc**", - "assignees": ["importantreviewer"] - } - ] + "packageRules": [ + { + "matchPackageNames": "abc**", + "assignees": ["importantreviewer"] + } + ] } ``` @@ -242,12 +242,12 @@ As above, but apply a `groupName`: ```json { - "packageRules": [ - { - "matchPackageNames": "abc**", - "groupName": ["abc packages"] - } - ] + "packageRules": [ + { + "matchPackageNames": "abc**", + "groupName": ["abc packages"] + } + ] } ``` @@ -271,14 +271,14 @@ Here's an example: Say you're using version `0.8.0` of the `foo` package. The `foo` maintainers release the following versions: -- `0.8.1` (patch) -- `0.9.0` (minor) -- `1.0.0` (major) +- `0.8.1` (patch) +- `0.9.0` (minor) +- `1.0.0` (major) Renovate creates the following PRs: -- Update dependency `foo` to `0.9.0` (minor) -- Update dependency `foo` to `1.0.0` (major) +- Update dependency `foo` to `0.9.0` (minor) +- Update dependency `foo` to `1.0.0` (major) Renovate groups the patch and minor versions into one PR. This means you only get a PR for the minor version, `0.9.0`. @@ -294,14 +294,14 @@ You can tell Renovate to create a separate PR for the patch release by setting ` In both cases, Renovate will open 3 PRs: -- Update dependency `foo` to `0.8.1` (patch) -- Update dependency `foo` to `0.9.0` (minor) -- Update dependency `foo` to `1.0.0` (major) +- Update dependency `foo` to `0.8.1` (patch) +- Update dependency `foo` to `0.9.0` (minor) +- Update dependency `foo` to `1.0.0` (major) Usually you don't want more PRs though. It can be nice to get patch PRs when you're using automerge: -- Get daily patch updates which are automerged once tests pass -- Get weekly updates for minor and major updates +- Get daily patch updates which are automerged once tests pass +- Get weekly updates for minor and major updates This means you barely notice Renovate during the week, while you still get the benefits of patch level updates. diff --git a/docs/usage/getting-started/app-secrets.md b/docs/usage/getting-started/app-secrets.md index c425784f83266d..fcb88f0bb55157 100644 --- a/docs/usage/getting-started/app-secrets.md +++ b/docs/usage/getting-started/app-secrets.md @@ -2,8 +2,8 @@ The information on this page is for the Mend-hosted cloud apps: -- Renovate App on GitHub -- Mend App on Bitbucket +- Renovate App on GitHub +- Mend App on Bitbucket If you self-host, you can skip reading this page. @@ -28,20 +28,20 @@ To add a secret for the Mend cloud app: 2. Open your organization/repository settings. 3. Put the secret in the _Credentials_ section: - ![Credentials settings page](../assets/images/app-settings/app-credentials.png) + ![Credentials settings page](../assets/images/app-settings/app-credentials.png) 4. Reference the secret from Renovate config files inside the repo. - ```json - { - "hostRules": [ - { - "matchHost": "github.com", - "token": "{{ secrets.MY-ORG-SECRET-1 }}" - } - ] - } - ``` + ```json + { + "hostRules": [ + { + "matchHost": "github.com", + "token": "{{ secrets.MY-ORG-SECRET-1 }}" + } + ] + } + ``` ## Organization secrets vs repository secrets diff --git a/docs/usage/getting-started/installing-onboarding.md b/docs/usage/getting-started/installing-onboarding.md index c85946157044b1..a71a0d95c9a3db 100644 --- a/docs/usage/getting-started/installing-onboarding.md +++ b/docs/usage/getting-started/installing-onboarding.md @@ -4,11 +4,11 @@ Read the [Security and Permissions](../security-and-permissions.md) page to learn more about: -- Renovate's security stance -- What do if you need to use certificed software -- The security/disclosure process -- Permissions -- Privacy +- Renovate's security stance +- What do if you need to use certificed software +- The security/disclosure process +- Permissions +- Privacy ## Repository installation @@ -18,8 +18,8 @@ If the administrator has configured a fixed list of repositories then the only w Otherwise, the process for adding new repositories to a Renovate installation can vary: -- Most commonly, you run Renovate as a dedicated "bot user" with global config option `autodiscover` set to `true`, meaning that it will run on every repository which it's been granted access to -- If using a GitHub App (including the Mend Renovate App) then you can install the app into a user or organization account and select either "All repositories", or "Select repositories" and pick them manually +- Most commonly, you run Renovate as a dedicated "bot user" with global config option `autodiscover` set to `true`, meaning that it will run on every repository which it's been granted access to +- If using a GitHub App (including the Mend Renovate App) then you can install the app into a user or organization account and select either "All repositories", or "Select repositories" and pick them manually ### Hosted GitHub.com App @@ -84,15 +84,15 @@ Warnings and errors should be fixed on the base branch (e.g. `main`) so that Ren The "Configure Renovate" PR will include a `renovate.json` file in the root directory, with suggested default settings. If you don't want a `renovate.json` file in your repository you can use one of the following files instead: -- `renovate.json5` -- `.github/renovate.json` -- `.github/renovate.json5` -- `.gitlab/renovate.json` -- `.gitlab/renovate.json5` -- `.renovaterc` -- `.renovaterc.json` -- `.renovaterc.json5` -- `package.json` (deprecated) +- `renovate.json5` +- `.github/renovate.json` +- `.github/renovate.json5` +- `.gitlab/renovate.json` +- `.gitlab/renovate.json5` +- `.renovaterc` +- `.renovaterc.json` +- `.renovaterc.json5` +- `package.json` (deprecated) #### package.json @@ -110,17 +110,17 @@ The configuration in your `package.json` will apply to the whole project (this i Renovate provides a `renovate.json` file, with default settings that will work for most cases. Sometimes Renovate detects that an override to these defaults is needed, and will add this override automatically, such as: -- Automatically enabling Angular-style semantic commits if your repository uses them -- Determining whether to use dependency range pinning depending on the detected project type (app vs library) +- Automatically enabling Angular-style semantic commits if your repository uses them +- Determining whether to use dependency range pinning depending on the detected project type (app vs library) ### Common overrides Please check the docs on this website for an exhaustive Configuration Reference. To help you get started, here are some of the most commonly changed (overridden) configuration settings: -- **rangeStrategy**: By default (with zero config) it's `"replace"` but the `"config:recommended"` preset overrides it to `"auto"`. Some prefer `"bump"`. -- **labels**: Labels to assign to Pull Requests -- **assignees**: GitHub user(s) to assign the Pull Requests to +- **rangeStrategy**: By default (with zero config) it's `"replace"` but the `"config:recommended"` preset overrides it to `"auto"`. Some prefer `"bump"`. +- **labels**: Labels to assign to Pull Requests +- **assignees**: GitHub user(s) to assign the Pull Requests to Renovate will update your PR description each time it finds changes. @@ -133,8 +133,8 @@ Once you're done checking and configuring in your Configure Renovate PR, it's ti There will be times when you need to change your Renovate config. There are two recommended approaches: -- Reconfigure via PR -- Nuke the config and re-onboard +- Reconfigure via PR +- Nuke the config and re-onboard ### Reconfigure via PR diff --git a/docs/usage/getting-started/migrating-secrets.md b/docs/usage/getting-started/migrating-secrets.md index ac74c451bc2f41..91ecf911d73c0c 100644 --- a/docs/usage/getting-started/migrating-secrets.md +++ b/docs/usage/getting-started/migrating-secrets.md @@ -12,14 +12,14 @@ This method will stop working on 01-Oct-2024: ```json title="Put encrypted secret in Renovate config" { - "hostRules": [ - { - "matchHost": "github.com", - "encrypted": { - "token": "drsMDVf6M2hTZCN......+gQm/0Rpw" - } - } - ] + "hostRules": [ + { + "matchHost": "github.com", + "encrypted": { + "token": "drsMDVf6M2hTZCN......+gQm/0Rpw" + } + } + ] } ``` @@ -29,12 +29,12 @@ This is the new method, that you should start using: ```json title="Reference the app secret in the Renovate config" { - "hostRules": [ - { - "matchHost": "github.com", - "token": "{{ secrets.GITHUB_COM_TOKEN }}" - } - ] + "hostRules": [ + { + "matchHost": "github.com", + "token": "{{ secrets.GITHUB_COM_TOKEN }}" + } + ] } ``` @@ -66,9 +66,9 @@ Mend recommends the first way. 3. On the **Credentials** page, select `ADD SECRET` to add the encrypted secret. 4. Give a value for `Secret name`, paste the encrypted secret into the `Secret Value` field, and select `SAVE`. 5. When you migrate a secret from a repository, make sure you are adding the secret to the _same_ organization or repository for which you generated the secret! - - A secret generated for a specific repository can only be added to that _same_ repository. - - A secret generated for a specific repository can only be added to the repository settings for the matching repository. This secret can _not_ be added to the organization's settings. - - A secret generated without a specific repository _can_ be added into the organization _or_ into the repository settings under that organization. + - A secret generated for a specific repository can only be added to that _same_ repository. + - A secret generated for a specific repository can only be added to the repository settings for the matching repository. This secret can _not_ be added to the organization's settings. + - A secret generated without a specific repository _can_ be added into the organization _or_ into the repository settings under that organization. 6. If you see the confirmation box with the text: **“Successfully migrated secret”**, your secret is now stored in the correct organization or repository. ![Successfully migrated secret](../assets/images/app-settings/stored-secret-encrypted.png) @@ -102,4 +102,4 @@ If you were expecting to import a secret originally encrypted by Renovate: ## Related links -- [Using Secrets with Mend Cloud Apps](app-secrets.md) +- [Using Secrets with Mend Cloud Apps](app-secrets.md) diff --git a/docs/usage/getting-started/private-packages.md b/docs/usage/getting-started/private-packages.md index 2e776a1e2d3198..3d92e9073f9040 100644 --- a/docs/usage/getting-started/private-packages.md +++ b/docs/usage/getting-started/private-packages.md @@ -5,8 +5,8 @@ This page describes Renovate's approach to authentication. First, a quick note on terminology: -- The terms `module`, `package` and `dependency` can mostly be used interchangeably below -- The terms `credentials`, `secrets` and `authentication` are also used interchangeably +- The terms `module`, `package` and `dependency` can mostly be used interchangeably below +- The terms `credentials`, `secrets` and `authentication` are also used interchangeably ## When does Renovate need credentials? @@ -18,10 +18,10 @@ Any time you need Renovate to access such registries with credentials then you w There are four times in Renovate's behavior when it may need credentials: -- Resolving private config presets -- Looking up dependency versions -- Looking up changelogs -- Passing to package managers when updating lock files or checksums +- Resolving private config presets +- Looking up dependency versions +- Looking up changelogs +- Passing to package managers when updating lock files or checksums !!! note @@ -43,9 +43,9 @@ If your preset doesn't have secrets then you should make it public, while if it In summary, the recommended approach to private presets is: -- Host the presets on the same server/platform as other repositories -- Make sure you install Renovate into the preset repository so that it has credentials to access it from other private repos -- Use `local>....` syntax to refer to private presets +- Host the presets on the same server/platform as other repositories +- Make sure you install Renovate into the preset repository so that it has credentials to access it from other private repos +- Use `local>....` syntax to refer to private presets ## Dependency Version Lookups @@ -69,17 +69,17 @@ Other credential terms are not supported yet. ```json title="Example host rules" { - "hostRules": [ - { - "matchHost": "registry.npmjs.org", - "token": "abc123" - }, - { - "matchHost": "https://registry.company.com/pypi-simple/", - "username": "engineering", - "password": "abc123" - } - ] + "hostRules": [ + { + "matchHost": "registry.npmjs.org", + "token": "abc123" + }, + { + "matchHost": "https://registry.company.com/pypi-simple/", + "username": "engineering", + "password": "abc123" + } + ] } ``` @@ -92,16 +92,16 @@ If you need to use different credentials for a specific GitHub repo, then you ca ```json { - "hostRules": [ - { - "matchHost": "https://api.github.com/repos/org/repo", - "token": "abc123" - }, - { - "matchHost": "https://github.domain.com/api/v3/repos/org/repo", - "token": "abc123" - } - ] + "hostRules": [ + { + "matchHost": "https://api.github.com/repos/org/repo", + "token": "abc123" + }, + { + "matchHost": "https://github.domain.com/api/v3/repos/org/repo", + "token": "abc123" + } + ] } ``` @@ -114,31 +114,31 @@ Assume this config is used on the `github.com/some-other-org` repo: ```json { - "$schema": "https://docs.renovatebot.com/renovate-schema.json", - "dependencyDashboard": true, - "hostRules": [ - { - "matchHost": "https://gitlab.com", - "token": "glpat-token_for_different_git_platform", - "hostType": "gitlab" + "$schema": "https://docs.renovatebot.com/renovate-schema.json", + "dependencyDashboard": true, + "hostRules": [ + { + "matchHost": "https://gitlab.com", + "token": "glpat-token_for_different_git_platform", + "hostType": "gitlab" + }, + { + "matchHost": "https://github.com/some-org", + "token": "ghp_token_for_different_org", + "hostType": "go" + }, + { + "matchHost": "https://api.github.com/repos/some-org", + "token": "ghp_token_for_different_org", + "hostType": "github" + } + ], + "customEnvVariables": { + "GOPRIVATE": "github.com/some-org,github.com/some-other-org,gitlab.com/some-org", + "GONOSUMDB": "github.com/some-org,github.com/some-other-org,gitlab.com/some-org", + "GONOPROXY": "github.com/some-org,github.com/some-other-org,gitlab.com/some-org" }, - { - "matchHost": "https://github.com/some-org", - "token": "ghp_token_for_different_org", - "hostType": "go" - }, - { - "matchHost": "https://api.github.com/repos/some-org", - "token": "ghp_token_for_different_org", - "hostType": "github" - } - ], - "customEnvVariables": { - "GOPRIVATE": "github.com/some-org,github.com/some-other-org,gitlab.com/some-org", - "GONOSUMDB": "github.com/some-org,github.com/some-other-org,gitlab.com/some-org", - "GONOPROXY": "github.com/some-org,github.com/some-other-org,gitlab.com/some-org" - }, - "postUpdateOptions": ["gomodTidy"] + "postUpdateOptions": ["gomodTidy"] } ``` @@ -153,8 +153,8 @@ It can be confusing for people who host their own source code privately to be as Currently the preferred way to configure `github.com` credentials for self-hosted Renovate is: -- Create a read-only Personal Access Token (PAT) for a `github.com` account. This can be any GitHub account, but we recommend you create an "empty" account for this purpose. -- Add the PAT to Renovate using the environment variable `GITHUB_COM_TOKEN` +- Create a read-only Personal Access Token (PAT) for a `github.com` account. This can be any GitHub account, but we recommend you create an "empty" account for this purpose. +- Add the PAT to Renovate using the environment variable `GITHUB_COM_TOKEN` ## Package Manager Credentials for Artifact Updating @@ -180,20 +180,20 @@ Any `hostRules` with `hostType=packagist` are also included. For dependencies on `github.com` without a Packagist server: use a Personal Access Token for `hostRule` with `hostType=git-tags`, do not use an application token. Avoid adding a `hostRule` with `hostType=github` because: -- it overrides the default Renovate application token for everything else -- it causes unwanted side effects +- it overrides the default Renovate application token for everything else +- it causes unwanted side effects The repository in `composer.json` should have the `vcs` type with a `https` URL. For example: ```json { - "repositories": [ - { - "type": "vcs", - "url": "https://github.com/organization/private-repository" - } - ] + "repositories": [ + { + "type": "vcs", + "url": "https://github.com/organization/private-repository" + } + ] } ``` @@ -210,14 +210,14 @@ This is how you connect to a private Helm repository: ```js title="Connecting to a private Helm repository" module.exports = { - hostRules: [ - { - matchHost: 'your.host.io', - hostType: 'helm', - username: '', - password: process.env.SELF_HOSTED_HELM_CHARTS_PASSWORD, - }, - ], + hostRules: [ + { + matchHost: 'your.host.io', + hostType: 'helm', + username: '', + password: process.env.SELF_HOSTED_HELM_CHARTS_PASSWORD, + }, + ], }; ``` @@ -239,28 +239,29 @@ Define `hostRules` like this: ```js module.exports = { - hostRules: [ - { - hostType: 'npm', - matchHost: 'registry.npmjs.org', - token: process.env.NPMJS_TOKEN, - }, - { - hostType: 'npm', - matchHost: - 'https://pkgs.dev.azure.com/{organization}/{project}/_packaging/{feed}/npm/registry/', - username: 'VssSessionToken', - password: process.env.AZURE_NPM_TOKEN, - }, - { - // https://www.jfrog.com/confluence/display/JFROG/npm+Registry - // Will be passed as `//artifactory.my-company.com/artifactory/api/npm/npm:_auth=` to `.npmrc` - hostType: 'npm', - matchHost: 'https://artifactory.my-company.com/artifactory/api/npm/npm/', - token: process.env.ARTIFACTORY_NPM_TOKEN, - authType: 'Basic', - }, - ], + hostRules: [ + { + hostType: 'npm', + matchHost: 'registry.npmjs.org', + token: process.env.NPMJS_TOKEN, + }, + { + hostType: 'npm', + matchHost: + 'https://pkgs.dev.azure.com/{organization}/{project}/_packaging/{feed}/npm/registry/', + username: 'VssSessionToken', + password: process.env.AZURE_NPM_TOKEN, + }, + { + // https://www.jfrog.com/confluence/display/JFROG/npm+Registry + // Will be passed as `//artifactory.my-company.com/artifactory/api/npm/npm:_auth=` to `.npmrc` + hostType: 'npm', + matchHost: + 'https://artifactory.my-company.com/artifactory/api/npm/npm/', + token: process.env.ARTIFACTORY_NPM_TOKEN, + authType: 'Basic', + }, + ], }; ``` @@ -274,7 +275,7 @@ You can add an `.npmrc` authentication line to your Renovate config under the fi ```json { - "npmrc": "//some.registry.com/:_authToken=abcdefghi-1234-jklmno-aac6-12345567889" + "npmrc": "//some.registry.com/:_authToken=abcdefghi-1234-jklmno-aac6-12345567889" } ``` @@ -288,7 +289,7 @@ If you are using the main npmjs registry then you can configure only the `npmTok ```json { - "npmToken": "abcdefghi-1234-jklmno-aac6-12345567889" + "npmToken": "abcdefghi-1234-jklmno-aac6-12345567889" } ``` @@ -302,9 +303,9 @@ Paste the encrypted result inside an `encrypted` object like this: ```json { - "encrypted": { - "npmToken": "xxT19RIdhAh09lkhdrK39HzKNBn3etoLZAwHdeJ25cX+5y52a9kAC7flXmdw5JrkciN08aQuRNqDaKxp53IVptB5AYOnQPrt8MCT+x0zHgp4A1zv1QOV84I6uugdWpFSjPUkmLGMgULudEZJMlY/dAn/IVwf/IImqwazY8eHyJAA4vyUqKkL9SXzHjvS+OBonQ/9/AHYYKmDJwT8vLSRCKrXxJCdUfH7ZnikZbFqjnURJ9nGUHP44rlYJ7PFl05RZ+X5WuZG/A27S5LuBvguyQGcw8A2AZilHSDta9S/4eG6kb22jX87jXTrT6orUkxh2WHI/xvNUEout0gxwWMDkA==" - } + "encrypted": { + "npmToken": "xxT19RIdhAh09lkhdrK39HzKNBn3etoLZAwHdeJ25cX+5y52a9kAC7flXmdw5JrkciN08aQuRNqDaKxp53IVptB5AYOnQPrt8MCT+x0zHgp4A1zv1QOV84I6uugdWpFSjPUkmLGMgULudEZJMlY/dAn/IVwf/IImqwazY8eHyJAA4vyUqKkL9SXzHjvS+OBonQ/9/AHYYKmDJwT8vLSRCKrXxJCdUfH7ZnikZbFqjnURJ9nGUHP44rlYJ7PFl05RZ+X5WuZG/A27S5LuBvguyQGcw8A2AZilHSDta9S/4eG6kb22jX87jXTrT6orUkxh2WHI/xvNUEout0gxwWMDkA==" + } } ``` @@ -313,10 +314,10 @@ If instead you use an alternative registry or need an `.npmrc` file for some oth ```json { - "encrypted": { - "npmToken": "xxT19RIdhAh09lkhdrK39HzKNBn3etoLZAwHdeJ25cX+5y52a9kAC7flXmdw5JrkciN08aQuRNqDaKxp53IVptB5AYOnQPrt8MCT+x0zHgp4A1zv1QOV84I6uugdWpFSjPUkmLGMgULudEZJMlY/dAn/IVwf/IImqwazY8eHyJAA4vyUqKkL9SXzHjvS+OBonQ/9/AHYYKmDJwT8vLSRCKrXxJCdUfH7ZnikZbFqjnURJ9nGUHP44rlYJ7PFl05RZ+X5WuZG/A27S5LuBvguyQGcw8A2AZilHSDta9S/4eG6kb22jX87jXTrT6orUkxh2WHI/xvNUEout0gxwWMDkA==" - }, - "npmrc": "registry=https://my.custom.registry/npm\n//my.custom.registry/npm:_authToken=${NPM_TOKEN}" + "encrypted": { + "npmToken": "xxT19RIdhAh09lkhdrK39HzKNBn3etoLZAwHdeJ25cX+5y52a9kAC7flXmdw5JrkciN08aQuRNqDaKxp53IVptB5AYOnQPrt8MCT+x0zHgp4A1zv1QOV84I6uugdWpFSjPUkmLGMgULudEZJMlY/dAn/IVwf/IImqwazY8eHyJAA4vyUqKkL9SXzHjvS+OBonQ/9/AHYYKmDJwT8vLSRCKrXxJCdUfH7ZnikZbFqjnURJ9nGUHP44rlYJ7PFl05RZ+X5WuZG/A27S5LuBvguyQGcw8A2AZilHSDta9S/4eG6kb22jX87jXTrT6orUkxh2WHI/xvNUEout0gxwWMDkA==" + }, + "npmrc": "registry=https://my.custom.registry/npm\n//my.custom.registry/npm:_authToken=${NPM_TOKEN}" } ``` @@ -335,9 +336,9 @@ The end-result looks like this: ```json { - "encrypted": { - "npmrc": "WOTWu+jliBtXYz3CU2eI7dDyMIvSJKS2N5PEHZmLB3XKT3vLaaYTGCU6m92Q9FgdaM/q2wLYun2JrTP4GPaW8eGZ3iiG1cm7lgOR5xPnkCzz0DUmSf6Cc/6geeVeSFdJ0zqlEAhdNMyJ4pUW6iQxC3WJKgM/ADvFtme077Acvc0fhCXv0XvbNSbtUwHF/gD6OJ0r2qlIzUMGJk/eI254xo5SwWVctc1iZS9LW+L0/CKjqhWh4SbyglP3lKE5shg3q7mzWDZepa/nJmAnNmXdoVO2aPPeQCG3BKqCtCfvLUUU/0LvnJ2SbQ1obyzL7vhh2OF/VsATS5cxbHvoX/hxWQ==" - } + "encrypted": { + "npmrc": "WOTWu+jliBtXYz3CU2eI7dDyMIvSJKS2N5PEHZmLB3XKT3vLaaYTGCU6m92Q9FgdaM/q2wLYun2JrTP4GPaW8eGZ3iiG1cm7lgOR5xPnkCzz0DUmSf6Cc/6geeVeSFdJ0zqlEAhdNMyJ4pUW6iQxC3WJKgM/ADvFtme077Acvc0fhCXv0XvbNSbtUwHF/gD6OJ0r2qlIzUMGJk/eI254xo5SwWVctc1iZS9LW+L0/CKjqhWh4SbyglP3lKE5shg3q7mzWDZepa/nJmAnNmXdoVO2aPPeQCG3BKqCtCfvLUUU/0LvnJ2SbQ1obyzL7vhh2OF/VsATS5cxbHvoX/hxWQ==" + } } ``` @@ -345,16 +346,16 @@ The end-result looks like this: ```json { - "hostRules": [ - { - "matchHost": "https://npm.pkg.github.com/", - "hostType": "npm", - "encrypted": { - "token": "" - } - } - ], - "npmrc": "@organizationName:registry=https://npm.pkg.github.com/" + "hostRules": [ + { + "matchHost": "https://npm.pkg.github.com/", + "hostType": "npm", + "encrypted": { + "token": "" + } + } + ], + "npmrc": "@organizationName:registry=https://npm.pkg.github.com/" } ``` @@ -368,15 +369,15 @@ For example, the Renovate configuration: ```json { - "hostRules": [ - { - "matchHost": "https://npm.pkg.github.com/", - "hostType": "npm", - "encrypted": { - "token": "" - } - } - ] + "hostRules": [ + { + "matchHost": "https://npm.pkg.github.com/", + "hostType": "npm", + "encrypted": { + "token": "" + } + } + ] } ``` @@ -386,16 +387,16 @@ If no registry currently set ```yaml npmRegistries: - //npm.pkg.github.com/: - npmAuthToken: + //npm.pkg.github.com/: + npmAuthToken: ``` If current registry key has protocol set: ```yaml npmRegistries: - https://npm.pkg.github.com: - npmAuthToken: + https://npm.pkg.github.com: + npmAuthToken: ``` ### maven @@ -405,11 +406,11 @@ In GitLab Pipelines authorization can be achieved using following config: ```js hostRules: [ - { - hostType: 'maven', - matchHost: 'https://gitlab.host.com/api/v4', - token: process.env.CI_JOB_TOKEN, - }, + { + hostType: 'maven', + matchHost: 'https://gitlab.host.com/api/v4', + token: process.env.CI_JOB_TOKEN, + }, ]; ``` @@ -420,12 +421,12 @@ For those found, a command like the following is run: `dotnet nuget add source $ ```js hostRules: [ - { - matchHost: 'https://pkgs.dev.azure.com//', - hostType: 'nuget', - username: 'user', // doesn't matter for azure - password: '', - }, + { + matchHost: 'https://pkgs.dev.azure.com//', + hostType: 'nuget', + username: 'user', // doesn't matter for azure + password: '', + }, ]; ``` @@ -439,12 +440,12 @@ For example: ```json { - "packageRules": [ - { - "matchManagers": ["pip_requirements"], - "registryUrls": ["https://docker.mycompany.domain"] - } - ] + "packageRules": [ + { + "matchManagers": ["pip_requirements"], + "registryUrls": ["https://docker.mycompany.domain"] + } + ] } ``` @@ -465,8 +466,8 @@ name = "pypi" The pip-compile manager can extract these directives from the input file given to Renovate: -- `--index-url` -- `--extra-index-url` +- `--index-url` +- `--extra-index-url` Renovate matches those URLs with credentials from matching `hostRules` blocks in the Renovate configuration. Then Renovate passes the information to `pip-compile` via environment variables. @@ -484,16 +485,16 @@ private-package==1.2.3 ```json { - "pip-compile": { - "fileMatch": ["requirements.in"] - }, - "hostRules": [ - { - "matchHost": "pypi.my.domain", - "username": "myuser", - "password": "mypassword" - } - ] + "pip-compile": { + "fileMatch": ["requirements.in"] + }, + "hostRules": [ + { + "matchHost": "pypi.my.domain", + "username": "myuser", + "password": "mypassword" + } + ] } ``` @@ -508,8 +509,8 @@ If you self-host and use Containerbase, or our Docker sidecar container, then Re But if you are self-hosting Renovate and: -- _not_ running Renovate in a Containerbase environment -- or, _not_ using the Docker sidecar container +- _not_ running Renovate in a Containerbase environment +- or, _not_ using the Docker sidecar container Then you must install the Python keyring package and the keyrigs.envvars package into your self-hosted environment. @@ -519,14 +520,14 @@ For every Poetry source, a `hostRules` search is done and then any found credent ```js module.exports = { - hostRules: [ - { - matchHost: 'pypi.example.com', - hostType: 'pypi', - username: process.env.PYPI_USERNAME, - password: process.env.PYPI_PASSWORD, - }, - ], + hostRules: [ + { + matchHost: 'pypi.example.com', + hostType: 'pypi', + username: process.env.PYPI_USERNAME, + password: process.env.PYPI_PASSWORD, + }, + ], }; ``` @@ -534,14 +535,14 @@ If you're self-hosting Renovate via the [GitLab Runner](../getting-started/runni ```js module.exports = { - hostRules: [ - { - matchHost: 'gitlab.example.com', - hostType: 'pypi', - username: 'gitlab-ci-token', - password: process.env.CI_JOB_TOKEN, - }, - ], + hostRules: [ + { + matchHost: 'gitlab.example.com', + hostType: 'pypi', + username: 'gitlab-ci-token', + password: process.env.CI_JOB_TOKEN, + }, + ], }; ``` @@ -557,13 +558,13 @@ For example: ```json { - "hostRules": [ - { - "matchHost": "npm.pkg.github.com", - "hostType": "npm", - "token": "some-personal-access-token" - } - ] + "hostRules": [ + { + "matchHost": "npm.pkg.github.com", + "hostType": "npm", + "token": "some-personal-access-token" + } + ] } ``` @@ -596,20 +597,20 @@ If you need to provide credentials to the Mend Renovate App, please do this: 1. Add each secret string in the Credentials section of Organisation or Repository settings in the web UI at [http://developer.mend.io](http://developer.mend.io). - ![Organization and repository secrets on the credentials settings page](../assets/images/app-settings/org-and-repo-secrets.png) + ![Organization and repository secrets on the credentials settings page](../assets/images/app-settings/org-and-repo-secrets.png) 2. Reference secrets inside your Renovate config files with notation: `{{ secrets.YOUR_SECRET }}`. - ```json - { - "hostRules": [ - { - "matchHost": "github.com", - "token": "{{ secrets.GITHUB_COM_TOKEN }}" - } - ] - } - ``` + ```json + { + "hostRules": [ + { + "matchHost": "github.com", + "token": "{{ secrets.GITHUB_COM_TOKEN }}" + } + ] + } + ``` For more details, see [Using Secrets with Mend Cloud Apps](app-secrets.md). @@ -617,8 +618,8 @@ For more details, see [Using Secrets with Mend Cloud Apps](app-secrets.md). The Mend Renovate App does not run using GitHub Actions, but such secrets would be a bad fit for the app anyway for the following reasons: -- The app would be granted access to _all_ the repository/org secrets, not just the ones you want -- If Renovate wants access to such secrets, it would need to ask for them from every user, not just the ones who want to use this approach (GitHub does not support the concept of optional permissions for Apps, so people do not have the option to decline) +- The app would be granted access to _all_ the repository/org secrets, not just the ones you want +- If Renovate wants access to such secrets, it would need to ask for them from every user, not just the ones who want to use this approach (GitHub does not support the concept of optional permissions for Apps, so people do not have the option to decline) ## Admin/Bot config vs User/Repository config for Self-hosted users @@ -630,11 +631,11 @@ If there is a need to supply custom rules for certain repository, it can still b If per-repository config must be done within the repository, it is still recommended against committing secrets directly (including e.g. `.npmrc` files with tokens) and instead encrypting them with a custom public key first. For instructions on this, see the above section on encrypting secrets for the Mend Renovate App but instead: -- Save a copy of the HTML file locally, or host it locally -- Generate a public/private key pair for the app using the instructions in [privateKey](../self-hosted-configuration.md#privatekey) -- Replace the existing public key in the HTML with the public key you generated in the step prior -- Use the resulting HTML encrypt page to encrypt secrets for your app before adding them to user/repository config -- Configure the app to run with `privateKey` set to the private key you generated above +- Save a copy of the HTML file locally, or host it locally +- Generate a public/private key pair for the app using the instructions in [privateKey](../self-hosted-configuration.md#privatekey) +- Replace the existing public key in the HTML with the public key you generated in the step prior +- Use the resulting HTML encrypt page to encrypt secrets for your app before adding them to user/repository config +- Configure the app to run with `privateKey` set to the private key you generated above !!! note diff --git a/docs/usage/getting-started/running.md b/docs/usage/getting-started/running.md index 5abf351cd7ebed..364aa8b5a71a18 100644 --- a/docs/usage/getting-started/running.md +++ b/docs/usage/getting-started/running.md @@ -2,9 +2,9 @@ As end user, you can choose from these ways to run Renovate: -- You use the Mend Renovate App -- You self-administer/host your own Renovate instance -- Someone else is hosting Renovate, and you install/configure it for the repositories you choose +- You use the Mend Renovate App +- You self-administer/host your own Renovate instance +- Someone else is hosting Renovate, and you install/configure it for the repositories you choose If you're using the Mend Renovate App, or if someone else is hosting Renovate for you, skip ahead to the [installing & onboarding](./installing-onboarding.md) page. @@ -12,10 +12,10 @@ If you're using the Mend Renovate App, or if someone else is hosting Renovate fo When self-hosting Renovate you're the "administrator" of the bot, this means you: -- provide the infrastructure that Renovate runs on, -- provision Renovate's global config, -- make sure Renovate bot runs regularly, -- make sure Renovate bot itself is updated +- provide the infrastructure that Renovate runs on, +- provision Renovate's global config, +- make sure Renovate bot runs regularly, +- make sure Renovate bot itself is updated If you're self-hosting Renovate on Windows, read [Self-hosting on Windows](./installing-onboarding.md#self-hosting-on-windows) to prevent line endings from confusing Renovate bot. @@ -44,8 +44,8 @@ In general, you can run Renovate natively on Windows as long as you have all too There are two Docker image flavors: -- The default image, which installs required tools at runtime (default for `latest` tag), -- The `-full` image, which comes with latest or very recent versions of every tool pre-installed +- The default image, which installs required tools at runtime (default for `latest` tag), +- The `-full` image, which comes with latest or very recent versions of every tool pre-installed ##### The default image (formerly `slim`) @@ -69,8 +69,8 @@ Update your Docker images regularly to keep the pre-installed tools up-to-date. The full image is for users who don't want to download or install things at runtime. This image has some downsides, because it: -- Comes pre-installed with _one_ version of each language/manager - usually the latest -- Weighs several gigabytes +- Comes pre-installed with _one_ version of each language/manager - usually the latest +- Weighs several gigabytes #### GitHub Action @@ -89,17 +89,17 @@ Mend Renovate Community Edition (Renovate CE) and Enterprise Edition (Renovate E Renovate CE and Renovate EE have support for GitHub (both `github.com` and GitHub Enterprise Server) as well as GitLab self-hosted. It is built similarly to the default "full" Renovate image described above, but with these differences: -- It is a stateful app and does not exit after processing all repositories -- It is installed as an App on GitHub, and behaves similarly on GitLab - for example responding to webhooks -- It includes a priority job queue which prioritizes events like merged PRs over scheduled jobs -- It is released every 1-2 months in a slower, more stable cadence than Renovate OSS, which releases on every commit -- It's licensed using an end-user license agreement (EULA) and not the Affero General Public License (AGPL) +- It is a stateful app and does not exit after processing all repositories +- It is installed as an App on GitHub, and behaves similarly on GitLab - for example responding to webhooks +- It includes a priority job queue which prioritizes events like merged PRs over scheduled jobs +- It is released every 1-2 months in a slower, more stable cadence than Renovate OSS, which releases on every commit +- It's licensed using an end-user license agreement (EULA) and not the Affero General Public License (AGPL) Plus, the Enterprise Edition has: -- Horizontal scaling to run multiple 'worker' containers -- Dedicated support from Mend.io -- Premium features, including Smart Merge Control +- Horizontal scaling to run multiple 'worker' containers +- Dedicated support from Mend.io +- Premium features, including Smart Merge Control Go to the Mend.io website to learn more about [Renovate Enterprise Edition](https://www.mend.io/renovate-enterprise/). @@ -128,8 +128,8 @@ Forking Renovate needs only `read` level access to the code of any repository it If you use Forking Renovate, you'll miss out on these features of the regular Renovate app: -- Automerge -- The `baseBranches` config option +- Automerge +- The `baseBranches` config option ### Hosting Renovate @@ -147,9 +147,9 @@ Mend Renovate On-Premises and Mend Remediate both run as long-lived containers, Renovate's server-side/admin config is referred to as its "global" config, and can be set by using either: -- a config file, or -- environment variables, or -- CLI parameters +- a config file, or +- environment variables, or +- CLI parameters By default Renovate checks if a file named `config.js` is present. Any other (`*.js`, `*.json`, `*.json5`, `*.yaml` or `*.yml`) file is supported, when you reference it with the `RENOVATE_CONFIG_FILE` environment variable (for example: `RENOVATE_CONFIG_FILE=config.yaml`). @@ -162,8 +162,8 @@ This way the Renovate end users can see as much of the bot's configuration as po If you are configuring Renovate using environment variables, there are two possibilities: -- Upper-cased, camel-cased, `RENOVATE_`-prefixed single config options like `RENOVATE_TOKEN=abc123` or `RENOVATE_GIT_AUTHOR=a@b.com` -- Set `RENOVATE_CONFIG` to a [stringified](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) version of the full JSON config, for example: `RENOVATE_CONFIG='{"token":"abc123","gitAuthor":"a@b.com"}'` +- Upper-cased, camel-cased, `RENOVATE_`-prefixed single config options like `RENOVATE_TOKEN=abc123` or `RENOVATE_GIT_AUTHOR=a@b.com` +- Set `RENOVATE_CONFIG` to a [stringified](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify) version of the full JSON config, for example: `RENOVATE_CONFIG='{"token":"abc123","gitAuthor":"a@b.com"}'` If you combine both of the above then any single config option in the environment variable will override what's in `RENOVATE_CONFIG`. @@ -179,7 +179,7 @@ The value can be either a plain JavaScript object like in this example where `co ```javascript module.exports = { - token: 'abcdefg', + token: 'abcdefg', }; ``` @@ -202,12 +202,12 @@ We also recommend you configure `config.gitAuthor` with the same identity as you Read the platform-specific docs to learn how to setup authentication on your platform: -- [Azure DevOps](../modules/platform/azure/index.md) -- [Bitbucket Cloud](../modules/platform/bitbucket/index.md) -- [Bitbucket Server](../modules/platform/bitbucket-server/index.md) -- [Gitea and Forgejo](../modules/platform/gitea/index.md) -- [github.com and GitHub Enterprise Server](../modules/platform/github/index.md) -- [GitLab](../modules/platform/gitlab/index.md) +- [Azure DevOps](../modules/platform/azure/index.md) +- [Bitbucket Cloud](../modules/platform/bitbucket/index.md) +- [Bitbucket Server](../modules/platform/bitbucket-server/index.md) +- [Gitea and Forgejo](../modules/platform/gitea/index.md) +- [github.com and GitHub Enterprise Server](../modules/platform/github/index.md) +- [GitLab](../modules/platform/gitlab/index.md) ### GitHub.com token for changelogs diff --git a/docs/usage/getting-started/use-cases.md b/docs/usage/getting-started/use-cases.md index 932b0d00b0ced9..dc6b2a4dd2c377 100644 --- a/docs/usage/getting-started/use-cases.md +++ b/docs/usage/getting-started/use-cases.md @@ -13,9 +13,9 @@ Package files are managed by a "package manager". Example package files include: -- `package.json`, managed by npm or Yarn -- `Gemfile`, managed by Bundler -- `go.mod`, managed by `go` modules +- `package.json`, managed by npm or Yarn +- `Gemfile`, managed by Bundler +- `go.mod`, managed by `go` modules #### How Renovate updates a package file @@ -29,8 +29,8 @@ The Pull Requests patch the package files directly, and include changelogs for t By default: -- You'll get separate Pull Requests for each dependency -- Major updates are kept separate from non-major updates +- You'll get separate Pull Requests for each dependency +- Major updates are kept separate from non-major updates ### Package managers with lock files @@ -55,15 +55,15 @@ Renovate supports 90+ types of package files. By default, Renovate finds most dependencies, but there are exceptions. This can be because: -- The package manager/file format is not supported, or -- The file format is not a standard or is proprietary +- The package manager/file format is not supported, or +- The file format is not a standard or is proprietary If your dependencies are not found by default, you can use our `custom` manager to set your own custom patterns to extract dependencies. You configure the custom manager by telling it: -- Which file pattern(s) to match -- How to find the dependency name and version from within the file -- Which datasource (e.g. Docker registry, npm registry, etc) to use to look up new versions +- Which file pattern(s) to match +- How to find the dependency name and version from within the file +- Which datasource (e.g. Docker registry, npm registry, etc) to use to look up new versions The end result is that Renovate can keep dependencies in custom file formats up-to-date as long as the dependency datasource is known to Renovate. @@ -88,13 +88,13 @@ Renovate finds these IaC files and then searches Docker registries to see if the An example of tag-based updating are `node` images from Docker Hub. The `node` images use these tag formats: -- `14.17.4` -- `14.17.4-alpine3.11` +- `14.17.4` +- `14.17.4-alpine3.11` Renovate understands both formats and raises updates like these: -- From `14.17.4` to `14.17.5` -- From `14.17.4-alpine3.11` to `14.17.5-alpine3.11` +- From `14.17.4` to `14.17.5` +- From `14.17.4-alpine3.11` to `14.17.5-alpine3.11` #### Docker digests @@ -111,8 +111,8 @@ Your company typically has dozens of repositories, if not hundreds or thousands. These repositories often rely on other repositories and may have upstream or downstream internal dependencies. In such cases, it is best practice to: -- Update downstream links as soon as possible, and -- Keep internal version use as consistent as possible +- Update downstream links as soon as possible, and +- Keep internal version use as consistent as possible You can use Renovate to follow this best practice. Renovate finds and updates internal dependencies just like external or Open Source dependencies. @@ -127,9 +127,9 @@ To learn more about "automerge" read the [key concepts, automerge](../key-concep We use these Renovate features to automerge an internal dependency: -- [Git submodule support](../modules/manager/git-submodules/index.md) -- [`automerge`](../configuration-options.md#automerge) set to `true` -- [`automergeType`](../configuration-options.md#automergetype) set to `branch` +- [Git submodule support](../modules/manager/git-submodules/index.md) +- [`automerge`](../configuration-options.md#automerge) set to `true` +- [`automergeType`](../configuration-options.md#automergetype) set to `branch` ##### Background information @@ -149,8 +149,8 @@ We split our work over two repositories: The way we've set things up means we avoid: -- reviewing PRs -- manually merging PRs +- reviewing PRs +- manually merging PRs In fact we don't even get the update PR anymore! @@ -178,9 +178,9 @@ You can set the time ranges during which Renovate creates updates in the `schedu You can use Renovate's "Dependency Dashboard" on platforms which support dynamic Markdown checkboxes: -- Gitea and Forgejo -- GitHub -- GitLab +- Gitea and Forgejo +- GitHub +- GitLab When you enable the Dependency Dashboard, Renovate creates a "Dependency Dashboard" issue. This issue lists all updates which are pending, in progress, or were previously closed ignored. @@ -194,15 +194,15 @@ We call this the "Dependency Dashboard Approval" workflow. Here's how it works: -- You tell Renovate which package updates need "Dashboard Approval" by setting a custom `packageRule` -- Renovate only raises updates for packages that need "Dashboard Approval" after you select the corresponding checkbox on the dashboard +- You tell Renovate which package updates need "Dashboard Approval" by setting a custom `packageRule` +- Renovate only raises updates for packages that need "Dashboard Approval" after you select the corresponding checkbox on the dashboard #### Benefits of using Dependency Dashboard Approval Benefits of using Dependency Dashboard Approval: -- By not raising PRs automatically, it allows you to request updates on-demand when you're ready, and -- It offers you an alternative to permanently ignoring/disabling certain types of updates, like major updates +- By not raising PRs automatically, it allows you to request updates on-demand when you're ready, and +- It offers you an alternative to permanently ignoring/disabling certain types of updates, like major updates When you use the Dependency Dashboard Approval workflow you have full visibility and control over your updates. @@ -217,8 +217,8 @@ Renovate includes over 100 built-in presets, like the default recommended `confi The typical workflow for a company is: -- Create a dedicated repository to store the company's default Renovate settings -- Set that repository as the default `extends` value when onboarding new repositories +- Create a dedicated repository to store the company's default Renovate settings +- Set that repository as the default `extends` value when onboarding new repositories This means that repositories get the centralized config by default, and any changes made to the centralized config repository are propagated to other repositories immediately. diff --git a/docs/usage/gitlab-bot-security.md b/docs/usage/gitlab-bot-security.md index 1fd31351cc129c..d82cc410513216 100644 --- a/docs/usage/gitlab-bot-security.md +++ b/docs/usage/gitlab-bot-security.md @@ -16,8 +16,8 @@ The concept of `CI_JOB_TOKEN` permissions was [overhauled in GitLab release 8.12 For security reasons the token was limited to read-only permissions and a limited set of API endpoints, but it’s been extended to allow [write access to the GitLab Package Registry](https://docs.gitlab.com/ee/api/index.html#gitlab-ci-job-token). Any pipeline triggered by a user account thus has permissions to: -- read any repository which that account has access to -- publish packages to them +- read any repository which that account has access to +- publish packages to them With the current GitLab CI permissions model, you should only commit to a project which you trust completely. Because that project could maliciously steal repository data, publish fake releases, or spam releases. @@ -32,8 +32,8 @@ This was a useful feature to leverage for a shared service. If you are running a self-hosted Renovate service, we recommend you: -- Run a shared service only within projects which have shared visibility/security within the users, or which have a low risk that a user would try to gain access to a private project they don't otherwise have access to -- If running with `autodiscover`, also configure a value for `autodiscoverFilter` so that the bot can't be invited to projects or groups you don't intend +- Run a shared service only within projects which have shared visibility/security within the users, or which have a low risk that a user would try to gain access to a private project they don't otherwise have access to +- If running with `autodiscover`, also configure a value for `autodiscoverFilter` so that the bot can't be invited to projects or groups you don't intend ## Security solutions and workarounds @@ -52,10 +52,10 @@ But you _can't stop users_ from inviting the bot into _private_ projects by acci [Project Access Tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) (PATs) are a recently added feature for GitLab. The main downsides to using PATs for a shared bot service are: -- You can not [provision PATs through the API](https://gitlab.com/gitlab-org/gitlab/-/issues/238991), so project maintainers would need to provision a project bot account and then save it to Renovate manually and per-project -- PATs are a paid-only feature for gitlab.com, which prevents users on the free plan from using them -- At the time of writing, there are still some issues with getting PATs to trigger and authenticate CI -- Any service using PATs would get MRs from a user like `@project_123_bot` instead of `@renovate-bot` +- You can not [provision PATs through the API](https://gitlab.com/gitlab-org/gitlab/-/issues/238991), so project maintainers would need to provision a project bot account and then save it to Renovate manually and per-project +- PATs are a paid-only feature for gitlab.com, which prevents users on the free plan from using them +- At the time of writing, there are still some issues with getting PATs to trigger and authenticate CI +- Any service using PATs would get MRs from a user like `@project_123_bot` instead of `@renovate-bot` The big benefit of PATs is their limited scope: users with write access to one project cannot read/write to other projects. diff --git a/docs/usage/golang.md b/docs/usage/golang.md index b4a6554406b036..33591be1dc7dd6 100644 --- a/docs/usage/golang.md +++ b/docs/usage/golang.md @@ -9,10 +9,10 @@ Renovate supports upgrading dependencies in `go.mod` files and associated `go.su If you're self-hosting Renovate, you may use these environment variables: -- `GOPROXY` -- `GONOPROXY` -- `GOPRIVATE` -- `GOINSECURE` +- `GOPROXY` +- `GONOPROXY` +- `GOPRIVATE` +- `GOINSECURE` To learn what these variables do, read the [Go Modules Reference about the`GOPROXY` protocol](https://go.dev/ref/mod#module-proxy). @@ -69,9 +69,9 @@ You can force Renovate to use a specific version of Go by setting a constraint. ```json title="Getting Renovate to use the latest patch version of the 1.16 Go binary" { - "constraints": { - "go": "1.16" - } + "constraints": { + "go": "1.16" + } } ``` @@ -85,16 +85,16 @@ All token `hostRules` with a `hostType` (e.g. `github`, `gitlab`, `bitbucket`, . ```js module.exports = { - hostRules: [ - { - matchHost: 'github.enterprise.com', - token: process.env.GO_GITHUB_TOKEN, - hostType: 'github', - }, - { - matchHost: 'someGitHost.enterprise.com', - token: process.env.GO_GIT_TOKEN, - }, - ], + hostRules: [ + { + matchHost: 'github.enterprise.com', + token: process.env.GO_GITHUB_TOKEN, + hostType: 'github', + }, + { + matchHost: 'someGitHost.enterprise.com', + token: process.env.GO_GIT_TOKEN, + }, + ], }; ``` diff --git a/docs/usage/index.md b/docs/usage/index.md index 57f15571e83a59..bcc7ed4b1d051a 100644 --- a/docs/usage/index.md +++ b/docs/usage/index.md @@ -63,14 +63,14 @@ Multi-platform and multi-language. Renovate works on these platforms: -- [GitHub (.com and Enterprise Server)](./modules/platform/github/index.md) -- [GitLab (.com and CE/EE)](./modules/platform/gitlab/index.md) -- [Bitbucket Cloud](./modules/platform/bitbucket/index.md) -- [Bitbucket Server](./modules/platform/bitbucket-server/index.md) -- [Azure DevOps](./modules/platform/azure/index.md) -- [AWS CodeCommit](./modules/platform/codecommit/index.md) -- [Gitea and Forgejo](./modules/platform/gitea/index.md) -- [Gerrit (experimental)](./modules/platform/gerrit/index.md) +- [GitHub (.com and Enterprise Server)](./modules/platform/github/index.md) +- [GitLab (.com and CE/EE)](./modules/platform/gitlab/index.md) +- [Bitbucket Cloud](./modules/platform/bitbucket/index.md) +- [Bitbucket Server](./modules/platform/bitbucket-server/index.md) +- [Azure DevOps](./modules/platform/azure/index.md) +- [AWS CodeCommit](./modules/platform/codecommit/index.md) +- [Gitea and Forgejo](./modules/platform/gitea/index.md) +- [Gerrit (experimental)](./modules/platform/gerrit/index.md) ## Who Uses Renovate? @@ -108,8 +108,8 @@ Renovate is used by: You can run Renovate as: -- an [Open Source npm package](https://www.npmjs.com/package/renovate) -- a [pre-built Open Source image on Docker Hub](https://hub.docker.com/r/renovate/renovate) +- an [Open Source npm package](https://www.npmjs.com/package/renovate) +- a [pre-built Open Source image on Docker Hub](https://hub.docker.com/r/renovate/renovate) Or you can use [the Mend Renovate App](https://github.com/marketplace/renovate) which is hosted by [Mend](https://www.mend.io/). diff --git a/docs/usage/java.md b/docs/usage/java.md index bec5049480a017..05f26b2c1d5d08 100644 --- a/docs/usage/java.md +++ b/docs/usage/java.md @@ -17,8 +17,8 @@ If you want Renovate to offer all `major` Java updates then add `workarounds:jav ```json { - "extends": ["config:recommended"], - "ignorePresets": ["workarounds:javaLTSVersions"] + "extends": ["config:recommended"], + "ignorePresets": ["workarounds:javaLTSVersions"] } ``` @@ -30,21 +30,21 @@ Renovate detects versions that are specified in a string `'group:artifact:versio Renovate can update: -- `*.gradle`/`*.gradle.kts` files -- Dependencies with version definitions in `gradle.properties` files -- Gradle lockfiles stored in `*.lockfile` files -- `*.versions.toml` files in any directory or `*.toml` files inside the `gradle` - directory ([Gradle Version Catalogs docs](https://docs.gradle.org/current/userguide/platforms.html)) -- `versions.props` and `versions.lock` from the [gradle-consistent-versions](https://github.com/palantir/gradle-consistent-versions) plugin +- `*.gradle`/`*.gradle.kts` files +- Dependencies with version definitions in `gradle.properties` files +- Gradle lockfiles stored in `*.lockfile` files +- `*.versions.toml` files in any directory or `*.toml` files inside the `gradle` + directory ([Gradle Version Catalogs docs](https://docs.gradle.org/current/userguide/platforms.html)) +- `versions.props` and `versions.lock` from the [gradle-consistent-versions](https://github.com/palantir/gradle-consistent-versions) plugin Renovate does not support: -- Android projects that require extra configuration to run (e.g. setting the Android SDK) -- Catalogs with version ranges -- Catalog versions using `reject`, and `rejectAll` constraints -- Catalog versions using more than one of `require`, `strictly`, `prefer` in a single declaration -- Catalogs with custom names that do not end in `.toml` -- Catalogs outside the `gradle` folder whose names do not end in `.versions.toml` (unless overridden via [`fileMatch`](./configuration-options.md#filematch) configuration) +- Android projects that require extra configuration to run (e.g. setting the Android SDK) +- Catalogs with version ranges +- Catalog versions using `reject`, and `rejectAll` constraints +- Catalog versions using more than one of `require`, `strictly`, `prefer` in a single declaration +- Catalogs with custom names that do not end in `.toml` +- Catalogs outside the `gradle` folder whose names do not end in `.versions.toml` (unless overridden via [`fileMatch`](./configuration-options.md#filematch) configuration) ## Gradle Wrapper @@ -71,14 +71,14 @@ In case the available versions at the defined source differ from those available ```json { - "packageRules": [ - { - "matchDatasources": ["gradle-version"], - "registryUrls": [ - "https://domain.tld/repository/custom-gradle-wrapper/versions.json" - ] - } - ] + "packageRules": [ + { + "matchDatasources": ["gradle-version"], + "registryUrls": [ + "https://domain.tld/repository/custom-gradle-wrapper/versions.json" + ] + } + ] } ``` @@ -92,9 +92,9 @@ Renovate will search repositories for all `pom.xml` files and processes them ind Renovate will also parse `settings.xml` files in the following locations: -- `.mvn/settings.xml` -- `.m2/settings.xml` -- `settings.xml` +- `.mvn/settings.xml` +- `.m2/settings.xml` +- `settings.xml` Any repository URLs found within will be added as `registryUrls` to extracted dependencies. @@ -108,14 +108,14 @@ We're using environment variables to pass the Artifactory username and password ```js title="config.js" module.exports = { - hostRules: [ - { - hostType: 'maven', - matchHost: 'https://artifactory.yourcompany.com/', - username: process.env.ARTIFACTORY_USERNAME, - password: process.env.ARTIFACTORY_PASSWORD, - }, - ], + hostRules: [ + { + hostType: 'maven', + matchHost: 'https://artifactory.yourcompany.com/', + username: process.env.ARTIFACTORY_USERNAME, + password: process.env.ARTIFACTORY_PASSWORD, + }, + ], }; ``` @@ -123,12 +123,15 @@ You can overwrite the repositories to use for version lookup through configurati ```js module.exports = { - packageRules: [ - { - matchDatasources: ['maven'], - registryUrls: ['https://repo-a.tld/repo', 'https://repo-b.tld/repo'], - }, - ], + packageRules: [ + { + matchDatasources: ['maven'], + registryUrls: [ + 'https://repo-a.tld/repo', + 'https://repo-b.tld/repo', + ], + }, + ], }; ``` @@ -145,8 +148,8 @@ Renovate will automatically retrieve the credentials using the `google-auth-libr To access the Google Artifact Registry, use the JSON service account with `Basic` authentication, and use the: -- `_json_key_base64` as username -- full Google Cloud Platform service account JSON as password +- `_json_key_base64` as username +- full Google Cloud Platform service account JSON as password To avoid JSON-in-JSON wrapping, which can cause problems, encode the JSON service account beforehand. @@ -154,43 +157,43 @@ To avoid JSON-in-JSON wrapping, which can cause problems, encode the JSON servic 2. Base64 encode the service account credentials by running `cat service-account.json | base64` 3. Add the encoded service account to your configuration file - 1. If you want to add it to your self-hosted configuration file: - - ```json - { - "hostRules": [ - { - "matchHost": "europe-maven.pkg.dev", - "username": "_json_key_base64", - "password": "" - } - ] - } - ``` - - 2. If you want to add it to your repository Renovate configuration file, [encrypt](./configuration-options.md#encrypted) it and then add it: - - ```json - { - "hostRules": [ - { - "matchHost": "europe-maven.pkg.dev", - "username": "_json_key_base64", - "encrypted": { - "password": "" - } - } - ] - } - ``` + 1. If you want to add it to your self-hosted configuration file: + + ```json + { + "hostRules": [ + { + "matchHost": "europe-maven.pkg.dev", + "username": "_json_key_base64", + "password": "" + } + ] + } + ``` + + 2. If you want to add it to your repository Renovate configuration file, [encrypt](./configuration-options.md#encrypted) it and then add it: + + ```json + { + "hostRules": [ + { + "matchHost": "europe-maven.pkg.dev", + "username": "_json_key_base64", + "encrypted": { + "password": "" + } + } + ] + } + ``` 4. Add the following to the `packageRules` in your repository Renovate configuration file: - ```json - { - "matchManagers": ["maven", "gradle"], - "registryUrls": [ - "https://europe-maven.pkg.dev//" - ] - } - ``` + ```json + { + "matchManagers": ["maven", "gradle"], + "registryUrls": [ + "https://europe-maven.pkg.dev//" + ] + } + ``` diff --git a/docs/usage/key-concepts/automerge.md b/docs/usage/key-concepts/automerge.md index 2f24b7ae2ebb04..f4fb77809b5b1c 100644 --- a/docs/usage/key-concepts/automerge.md +++ b/docs/usage/key-concepts/automerge.md @@ -38,10 +38,10 @@ When Renovate performs lock file maintenance, it leaves the project dependency d ```json title="Example of automerging lock file maintenance" { - "lockFileMaintenance": { - "enabled": true, - "automerge": true - } + "lockFileMaintenance": { + "enabled": true, + "automerge": true + } } ``` @@ -53,13 +53,13 @@ But in many cases the new version(s) will pass tests, and if so then there's rea ```json title="Example of automerging lint and Prettier development packages" { - "packageRules": [ - { - "matchDepTypes": ["devDependencies"], - "matchPackageNames": ["lint", "prettier"], - "automerge": true - } - ] + "packageRules": [ + { + "matchDepTypes": ["devDependencies"], + "matchPackageNames": ["lint", "prettier"], + "automerge": true + } + ] } ``` @@ -69,13 +69,13 @@ Non-major updates in SemVer ecosystems shouldn't have breaking changes (if they ```json title="Example of automerging non-major updates in SemVer ecosystem" { - "packageRules": [ - { - "matchUpdateTypes": ["minor", "patch"], - "matchCurrentVersion": "!/^0/", - "automerge": true - } - ] + "packageRules": [ + { + "matchUpdateTypes": ["minor", "patch"], + "matchCurrentVersion": "!/^0/", + "automerge": true + } + ] } ``` @@ -87,13 +87,13 @@ Say you want to automerge `patch` and `minor` updates for packages in the `group ```json title="Example of automerging patch and minor updates in a group from a preset" { - "packageRules": [ - { - "extends": ["monorepo:ionic-native"], - "matchUpdateTypes": ["patch", "minor"], - "automerge": true - } - ] + "packageRules": [ + { + "extends": ["monorepo:ionic-native"], + "matchUpdateTypes": ["patch", "minor"], + "automerge": true + } + ] } ``` @@ -104,12 +104,12 @@ If you don't want Renovate to use the platform-native automerge, then set `platf ```json title="Example of disabling platform-native automerge" { - "lockFileMaintenance": { - "enabled": true, - "automerge": true, - "automergeType": "pr", - "platformAutomerge": false - } + "lockFileMaintenance": { + "enabled": true, + "automerge": true, + "automergeType": "pr", + "platformAutomerge": false + } } ``` @@ -137,8 +137,8 @@ Add the `on.merge_group` event to your GitHub Action `.yaml` files, for example: ```yaml on: - pull_request: - merge_group: + pull_request: + merge_group: ``` On `github.com`, go to your repository's "homepage", click on Settings, scroll down to the Pull Requests section and [enable the "Allow auto-merge" checkbox](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/configuring-pull-request-merges/managing-auto-merge-for-pull-requests-in-your-repository#managing-auto-merge). @@ -150,13 +150,13 @@ Finally, allow Renovate to automerge by setting `automerge=true` in your Renovat ```json { - "packageRules": [ - { - "description": "Automerge non-major updates", - "matchUpdateTypes": ["minor", "patch"], - "automerge": true - } - ] + "packageRules": [ + { + "description": "Automerge non-major updates", + "matchUpdateTypes": ["minor", "patch"], + "automerge": true + } + ] } ``` @@ -178,12 +178,12 @@ Automerging is particularly beneficial if you have configured a schedule, becaus And this is especially so if your repository needs rebasing, like when you use lock files. Let's say you have dependencies `abc` and `xyz` with upgrades, and you use a `yarn.lock` file. -- At the start of the schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates -- After `abc` passes tests, `Renovate` will automerge it into the base branch -- The `xyz` branch has a `yarn.lock` conflict now -- Renovate will immediately check all other branches and rebase them -- The change to `xyz` branch will trigger another round of CI tests -- After the updated `xyz` branch passes, Renovate will automerge it too +- At the start of the schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates +- After `abc` passes tests, `Renovate` will automerge it into the base branch +- The `xyz` branch has a `yarn.lock` conflict now +- Renovate will immediately check all other branches and rebase them +- The change to `xyz` branch will trigger another round of CI tests +- After the updated `xyz` branch passes, Renovate will automerge it too This is a lot better than you waking up to two PRs and then having to deal with conflicts yourself after you merge the first one. @@ -192,9 +192,9 @@ This is a lot better than you waking up to two PRs and then having to deal with Even if you automerge PRs, you are likely to still get notification noise - one when the PR is created and another when it is merged. For this reason we recommend you consider setting `automergeType=branch` which will mean: -- Renovate first creates a branch and no PR -- If tests pass, Renovate pushes a commit directly to the base branch without PR -- If tests fail, Renovate raises a PR for you to review +- Renovate first creates a branch and no PR +- If tests pass, Renovate pushes a commit directly to the base branch without PR +- If tests fail, Renovate raises a PR for you to review Add the `renovate/**` branch to your testing workflow files, or Renovate will not work properly with the `automergeType=branch` setting. @@ -259,13 +259,13 @@ To turn off automerge for all dependencies of a selected repository, you need to ```json { - "$schema": "https://docs.renovatebot.com/renovate-schema.json", - "extends": ["local>org-name/.github:renovate-config"], - "packageRules": [ - { - "matchPackageNames": ["*"], - "automerge": false - } - ] + "$schema": "https://docs.renovatebot.com/renovate-schema.json", + "extends": ["local>org-name/.github:renovate-config"], + "packageRules": [ + { + "matchPackageNames": ["*"], + "automerge": false + } + ] } ``` diff --git a/docs/usage/key-concepts/changelogs.md b/docs/usage/key-concepts/changelogs.md index 5136b9835f8be2..8a9e6a94f1721b 100644 --- a/docs/usage/key-concepts/changelogs.md +++ b/docs/usage/key-concepts/changelogs.md @@ -20,9 +20,9 @@ Renovate detects and populates changelogs by: For private packages, the algorithm is mostly the same as described above, with the additional considerations: -- Renovate must be able to access the private package in the first place -- The private registry must include the source URL in its response -- Renovate must be able to detect and authenticate with whatever private repository corresponds to the source URL +- Renovate must be able to access the private package in the first place +- The private registry must include the source URL in its response +- Renovate must be able to detect and authenticate with whatever private repository corresponds to the source URL For more details, see [Private packages, looking up changelogs](../getting-started/private-packages.md#looking-up-changelogs). @@ -56,17 +56,17 @@ Read [Running Renovate, GitHub.com token for changelogs](../getting-started/runn Follow these steps to find out why Renovate does not find a changelog: 1. The datasource for this package does not support sourceUrls. - - If the registry fundamentally does not provide this data, then the only possibility is for it to be manually populated through PRs to Renovate's source code - - If the registry provides source URLs in its response but Renovate does not understand the required fields, then raise a feature request with examples, or better yet a Pull Request to implement support for the source URL parsing/mapping yourself - - Sometimes self-hosted versions of registries don't include the full metadata compared to what the public registries do + - If the registry fundamentally does not provide this data, then the only possibility is for it to be manually populated through PRs to Renovate's source code + - If the registry provides source URLs in its response but Renovate does not understand the required fields, then raise a feature request with examples, or better yet a Pull Request to implement support for the source URL parsing/mapping yourself + - Sometimes self-hosted versions of registries don't include the full metadata compared to what the public registries do 1. The package was published without source URL information being included. - - For example, occasionally `npm` packages don't have `repository` fields included - - For example, Docker images regularly do not have the required `LABEL` entry + - For example, occasionally `npm` packages don't have `repository` fields included + - For example, Docker images regularly do not have the required `LABEL` entry 1. Renovate cannot access the source repository - - This is typically a concern for private repositories only - - Check if the token Renovate uses has access rights to the repository you need it to access + - This is typically a concern for private repositories only + - Check if the token Renovate uses has access rights to the repository you need it to access 1. Renovate cannot detect the file names or release name convention within the repository - - In this case an enhancement to Renovate might be needed to better detect the releases/formats, assuming the package/repository has a reasonable convention to follow + - In this case an enhancement to Renovate might be needed to better detect the releases/formats, assuming the package/repository has a reasonable convention to follow If none of this helps, search the Renovate issues and discussions to see if this is a known problem. @@ -83,13 +83,13 @@ For example, we have seen cases where the `repository` field in npm's `package.j In general, Renovate can understand your versions and changelogs best when you: -- Use SemVer versioning, so `major.minor.patch` -- Use the [`semantic-release` bot](https://github.com/semantic-release/semantic-release) to automate the release process +- Use SemVer versioning, so `major.minor.patch` +- Use the [`semantic-release` bot](https://github.com/semantic-release/semantic-release) to automate the release process Try to avoid things like: -- Stripping out the trailing `.0` unnecessarily (e.g. having a package `3.1.0` on a registry but using only `3.1` in your changelogs) -- Using "Release names" in a way which makes the actual version hard to discern (e.g. instead of `3.0.0` you title your release notes `Big news! v3 is here` +- Stripping out the trailing `.0` unnecessarily (e.g. having a package `3.1.0` on a registry but using only `3.1` in your changelogs) +- Using "Release names" in a way which makes the actual version hard to discern (e.g. instead of `3.0.0` you title your release notes `Big news! v3 is here` ### npm package maintainers diff --git a/docs/usage/key-concepts/dashboard.md b/docs/usage/key-concepts/dashboard.md index 67e7245106c2ff..51d02acd0adc27 100644 --- a/docs/usage/key-concepts/dashboard.md +++ b/docs/usage/key-concepts/dashboard.md @@ -23,7 +23,7 @@ To turn on the Dashboard manually, add the `:dependencyDashboard` preset to your ```json { - "extends": ["config:recommended", ":dependencyDashboard"] + "extends": ["config:recommended", ":dependencyDashboard"] } ``` @@ -31,7 +31,7 @@ Or set `dependencyDashboard` to `true`: ```json { - "dependencyDashboard": true + "dependencyDashboard": true } ``` @@ -41,7 +41,7 @@ To disable the Dependency Dashboard, add the preset `:disableDependencyDashboard ```json { - "extends": ["config:recommended", ":disableDependencyDashboard"] + "extends": ["config:recommended", ":disableDependencyDashboard"] } ``` @@ -53,8 +53,8 @@ This section explains some common use cases where having the Dependency Dashboar If Renovate finds: -- packages flagged as deprecated on their registry, or -- packages that have a community-sourced replacement PR available +- packages flagged as deprecated on their registry, or +- packages that have a community-sourced replacement PR available Then Renovate adds a prominent warning about these packages near the top of the Dependency Dashboard. Here is an example of how this can look: @@ -80,9 +80,9 @@ You can customize this "wait for approval" behavior however you like best. At a high level the options are: -- Require approval for _all_ updates -- Require approval for a type of updates (`major` for example) -- Require approval for specific packages +- Require approval for _all_ updates +- Require approval for a type of updates (`major` for example) +- Require approval for specific packages You can mix and match these options as well. @@ -103,7 +103,7 @@ To require manual approval for _all updates_, add the `:dependencyDashboardAppro ```json { - "extends": ["config:recommended", ":dependencyDashboardApproval"] + "extends": ["config:recommended", ":dependencyDashboardApproval"] } ``` @@ -118,9 +118,9 @@ If you want to require approval for major updates, set `dependencyDashboardAppro ```json { - "major": { - "dependencyDashboardApproval": true - } + "major": { + "dependencyDashboardApproval": true + } } ``` @@ -136,11 +136,11 @@ If you want to approve specific packages, set `dependencyDashboardApproval` to ` ```json { - "packageRules": [ - { - "matchPackageName": ["@somescope/**"], - "dependencyDashboardApproval": true - } - ] + "packageRules": [ + { + "matchPackageName": ["@somescope/**"], + "dependencyDashboardApproval": true + } + ] } ``` diff --git a/docs/usage/key-concepts/how-renovate-works.md b/docs/usage/key-concepts/how-renovate-works.md index 2f2f4608e81dbd..941050ea7d7bc3 100644 --- a/docs/usage/key-concepts/how-renovate-works.md +++ b/docs/usage/key-concepts/how-renovate-works.md @@ -7,11 +7,11 @@ description: Learn how Renovate works Renovate usually performs these steps: -- Cloning the repository -- Scanning package files to extract dependencies -- Looking up registries to check for updates -- Applying any grouping rules defined -- Pushing branches and raising Pull Requests +- Cloning the repository +- Scanning package files to extract dependencies +- Looking up registries to check for updates +- Applying any grouping rules defined +- Pushing branches and raising Pull Requests Because Renovate must support a lot of dependency naming and versioning conventions, it has modules for each known convention. You can contribute your own modules, if you want. @@ -20,10 +20,10 @@ You can contribute your own modules, if you want. Renovate's modules are: -- [datasource](../modules/datasource/index.md) -- [manager](../modules/manager/index.md) -- [platform](../modules/platform/index.md) -- [versioning](../modules/versioning/index.md) +- [datasource](../modules/datasource/index.md) +- [manager](../modules/manager/index.md) +- [platform](../modules/platform/index.md) +- [versioning](../modules/versioning/index.md) Renovate uses these modules in order: diff --git a/docs/usage/key-concepts/presets.md b/docs/usage/key-concepts/presets.md index 4ffaa25de680f0..d5621209eaf42b 100644 --- a/docs/usage/key-concepts/presets.md +++ b/docs/usage/key-concepts/presets.md @@ -11,10 +11,10 @@ To learn how to create your own presets, how to host them, and how to extend fro Use presets to: -- Set up the bot with good default settings -- Reduce duplication of your configuration -- Share your configuration with others -- Use somebody else's configuration and extend it with your own rules +- Set up the bot with good default settings +- Reduce duplication of your configuration +- Share your configuration with others +- Use somebody else's configuration and extend it with your own rules ## How to use presets @@ -24,7 +24,7 @@ You find the the `helpers:pinGitHubActionDigests` preset and add it to the `exte ```json { - "extends": ["config:recommended", "helpers:pinGitHubActionDigests"] + "extends": ["config:recommended", "helpers:pinGitHubActionDigests"] } ``` @@ -58,5 +58,5 @@ Read [Contributing to presets](../config-presets.md#contributing-to-presets) to In short: -- Browse [Renovate's default presets](../presets-default.md) to find any that are useful to you -- Publish your own if you wish to reuse them across repositories +- Browse [Renovate's default presets](../presets-default.md) to find any that are useful to you +- Publish your own if you wish to reuse them across repositories diff --git a/docs/usage/key-concepts/pull-requests.md b/docs/usage/key-concepts/pull-requests.md index 456f3566f58cf9..01305211e98a67 100644 --- a/docs/usage/key-concepts/pull-requests.md +++ b/docs/usage/key-concepts/pull-requests.md @@ -12,8 +12,8 @@ Instead, it uses the code platform's APIs to search and find such PRs. Renovate finds existing PRs (open or closed) by matching both: -- the branch name, for example: `renovate/lodash-4.x`, -- _and_ the Pull Request title, for example: `Update lodash to v4.17.21` +- the branch name, for example: `renovate/lodash-4.x`, +- _and_ the Pull Request title, for example: `Update lodash to v4.17.21` In cases like the above, there is typically one existing PR with a matching branch name and PR title. But if you group PRs and use titles like "All non-major updates", then multiple past PRs may match. diff --git a/docs/usage/key-concepts/scheduling.md b/docs/usage/key-concepts/scheduling.md index 204bff8f1f2d24..5794fe71e3d194 100644 --- a/docs/usage/key-concepts/scheduling.md +++ b/docs/usage/key-concepts/scheduling.md @@ -17,8 +17,8 @@ You can override the default timezone by setting your own `timezone` config opti When we talk about scheduling Renovate, there are 2 senses in which you can schedule Renovate: -- A global sense: when the bot is allowed to do work at all. This is determined by the bot admin using tools such as `cron` -- A specific sense: when Renovate is allowed to look for updates to a specific dependency +- A global sense: when the bot is allowed to do work at all. This is determined by the bot admin using tools such as `cron` +- A specific sense: when Renovate is allowed to look for updates to a specific dependency While as an end user you may think of scheduling in terms of when you allow it to raise updates, it's important to remember that such updates can only occur if the bot gets the opportunity to run within the schedule window you provide. @@ -31,9 +31,9 @@ You may want to update certain repositories less often, or you may even want to Some common reasons to schedule when Renovate runs: -- Make Renovate run outside office hours, to free up continuous integration resources for developers during the day -- Get updates for certain packages on a regular interval instead of right away -- Reduce Renovate bot PR notifications during the day +- Make Renovate run outside office hours, to free up continuous integration resources for developers during the day +- Get updates for certain packages on a regular interval instead of right away +- Reduce Renovate bot PR notifications during the day ## Customizing the schedule @@ -54,7 +54,7 @@ The timezone must be a valid [IANA time zone](https://en.wikipedia.org/wiki/List ```json title="Setting a specific timezone in your local config file" { - "timezone": "America/Los_Angeles" + "timezone": "America/Los_Angeles" } ``` @@ -93,17 +93,17 @@ Some config examples: ```json title="Renovate should run each day before 4 am" { - "schedule": ["before 4am"] + "schedule": ["before 4am"] } ``` ```json title="Renovate should run outside of common office hours" { - "schedule": [ - "after 10pm every weekday", - "before 5am every weekday", - "every weekend" - ] + "schedule": [ + "after 10pm every weekday", + "before 5am every weekday", + "every weekend" + ] } ``` @@ -119,12 +119,12 @@ The scheduling feature can be very useful for "noisy" packages that are updated ```json title="Restrict aws-sdk to weekly updates" { - "packageRules": [ - { - "matchPackageNames": ["aws-sdk"], - "schedule": ["after 9pm on sunday"] - } - ] + "packageRules": [ + { + "matchPackageNames": ["aws-sdk"], + "schedule": ["after 9pm on sunday"] + } + ] } ``` diff --git a/docs/usage/known-limitations.md b/docs/usage/known-limitations.md index 5912b1556964e8..26175915f008bd 100644 --- a/docs/usage/known-limitations.md +++ b/docs/usage/known-limitations.md @@ -18,8 +18,8 @@ Additionally, the Renovate admin may have put the bot on its own schedule, or th For scheduled action to take place, both these need to happen: -- The bot needs to run against your repository -- The current time needs to fall within your repository's configured schedule +- The bot needs to run against your repository +- The current time needs to fall within your repository's configured schedule ### The Mend Renovate app and scheduled jobs @@ -30,10 +30,10 @@ This makes it likely that Renovate bot checks your repository at least once duri ## Automerge limitations -- Renovate automerges at most one branch/PR per run -- If an automerge happened, the repository run will be restarted at most once. The second run can also potentially automerge, so it may appear as like two automerges in one run. -- Renovate will only automerge a branch when it is up-to-date with the target branch -- Renovate may not be able to automerge as many branches as you expect, especially if your base branch is receiving regular commits at the same time +- Renovate automerges at most one branch/PR per run +- If an automerge happened, the repository run will be restarted at most once. The second run can also potentially automerge, so it may appear as like two automerges in one run. +- Renovate will only automerge a branch when it is up-to-date with the target branch +- Renovate may not be able to automerge as many branches as you expect, especially if your base branch is receiving regular commits at the same time The limitation to only merge one branch per run is because Renovate's dependency and branch state is based on what was present in the base branch at the start of the run. If a branch is merged into the base branch during Renovate's run - including by other users - it means that remaining Renovate branches may have Git conflicts. @@ -41,8 +41,8 @@ It also means that Renovate's knowledge about dependencies in the base branch is The limitation to only automerge branches which are up-to-date is a decision due to this example: -- Two dependencies are in use: `alice@1.0.0` and `bob@1.0.0` -- PRs exist for `alice@2.0.0` and `bob@2.0.0` and both pass tests -- The PR for `alice@2.0.0` is automerged -- The PR for `bob@2.0.0` remains open, does not have conflicts, and has all tests passing -- But `alice@2.0.0` and `bob@2.0.0` are incompatible so merging the PR without rebasing and retesting it first would result in a broken base branch +- Two dependencies are in use: `alice@1.0.0` and `bob@1.0.0` +- PRs exist for `alice@2.0.0` and `bob@2.0.0` and both pass tests +- The PR for `alice@2.0.0` is automerged +- The PR for `bob@2.0.0` remains open, does not have conflicts, and has all tests passing +- But `alice@2.0.0` and `bob@2.0.0` are incompatible so merging the PR without rebasing and retesting it first would result in a broken base branch diff --git a/docs/usage/language-constraints-and-upgrading.md b/docs/usage/language-constraints-and-upgrading.md index 3f1e4501451904..6cc96072ac26a5 100644 --- a/docs/usage/language-constraints-and-upgrading.md +++ b/docs/usage/language-constraints-and-upgrading.md @@ -7,8 +7,8 @@ For example, a npm package may support Node.js 18 and 20 in its `v1` releases an In an ideal scenario: -- Package files allow a project to show its supported language constraints, and -- Package registries allow packages to show the supported language constraints per release +- Package files allow a project to show its supported language constraints, and +- Package registries allow packages to show the supported language constraints per release ## Restricting upgrades to compatible releases @@ -22,8 +22,8 @@ For other ecosystems Renovate's default behavior may seem _wrong_. As a Renovate user, you can opt into strict compatibility filtering by setting `constraintsFiltering=strict`. Before you set `constraintsFiltering=strict`, you should: -- understand the limitations of this setting -- understand why `constraintsFiltering=strict` is _not_ the default behavior +- understand the limitations of this setting +- understand why `constraintsFiltering=strict` is _not_ the default behavior Please keep reading to learn more. @@ -56,8 +56,8 @@ What if the project _already_ used a current version of this library "in a way t A second problem is that if: -- Renovate can _not_ update the language constraints, or -- a user _ignores_ or does not see the language upgrade +- Renovate can _not_ update the language constraints, or +- a user _ignores_ or does not see the language upgrade Then the user may not know that many dependencies are out of date, because Renovate is not creating PRs. For example: a project may have 10 dependencies, and 8 of those have updates. @@ -81,17 +81,17 @@ For example: ```json title="Renovate config with Node.js constraints" { - "constraints": { - "node": "^18.0.0 || >=20.0.0" - } + "constraints": { + "node": "^18.0.0 || >=20.0.0" + } } ``` You may need to set constraints in the Renovate config when: -- The package manager of the project does not support constraints declarations, or -- The project has not declared any constraints, or -- You want Renovate to use _different_ constraints to what's declared in the _project_ +- The package manager of the project does not support constraints declarations, or +- The project has not declared any constraints, or +- You want Renovate to use _different_ constraints to what's declared in the _project_ Renovate will _not_ create "update" PRs to update any of these versions once they become outdated, so you must update those by hand. For this reason, setting constraints manually in the Renovate config is _undesirable_. @@ -102,5 +102,5 @@ We prefer to fix problems in Renovate itself, instead of you setting constraints Please start, or join, a GitHub Discussion if you are interested in this topic. Subtopics include: -- Improving language constraints update automation in package files -- Improving versioning calculations of "subset" (is range A a subset of range B) +- Improving language constraints update automation in package files +- Improving versioning calculations of "subset" (is range A a subset of range B) diff --git a/docs/usage/logo-brand-guidelines.md b/docs/usage/logo-brand-guidelines.md index 7acab6425cd537..a1e80179c88c9a 100644 --- a/docs/usage/logo-brand-guidelines.md +++ b/docs/usage/logo-brand-guidelines.md @@ -15,16 +15,16 @@ Avoid using our name, logo, or branding in a way that causes people to think you You are allowed to use the Renovate name: -- to refer to the official Renovate app -- as a nickname/shorthand, in contexts where it is clear you are referring to your self-hosted version +- to refer to the official Renovate app +- as a nickname/shorthand, in contexts where it is clear you are referring to your self-hosted version ## Allowed uses of the Renovate logo You are allowed to use our logo as: -- an icon in your repository readme, that says you are using Renovate -- part of a badge in your repository readme, that says you are using Renovate -- an avatar image for your self-hosted version of Renovate, but give your bot a _different_ name +- an icon in your repository readme, that says you are using Renovate +- part of a badge in your repository readme, that says you are using Renovate +- an avatar image for your self-hosted version of Renovate, but give your bot a _different_ name ## Allowed uses of the Renovate branding diff --git a/docs/usage/merge-confidence.md b/docs/usage/merge-confidence.md index 01a24c4633abbb..fc58221c055b35 100644 --- a/docs/usage/merge-confidence.md +++ b/docs/usage/merge-confidence.md @@ -2,8 +2,8 @@ Look at the Merge Confidence badges before merging to: -- Prevent updates which break in production -- See at a glance if you should update +- Prevent updates which break in production +- See at a glance if you should update Merge Confidence finds and flags undeclared breaking releases. It analyzes test and release adoption data from the Mend Renovate App users. @@ -14,10 +14,10 @@ It analyzes test and release adoption data from the Mend Renovate App users. Merge Confidence adds the following badges to your pull requests: -- **Age**: The age of the package -- **Adoption**: The percentage of this package's users (within Renovate) which are using this release -- **Passing**: The percentage of updates which have passing tests for this package -- **Confidence**: The confidence level for this update +- **Age**: The age of the package +- **Adoption**: The percentage of this package's users (within Renovate) which are using this release +- **Passing**: The percentage of updates which have passing tests for this package +- **Confidence**: The confidence level for this update ## Supported platforms @@ -47,7 +47,7 @@ If you're self-hosting Renovate, you can enable the badges by adding the `mergeC ```json { - "extends": ["mergeConfidence:all-badges"] + "extends": ["mergeConfidence:all-badges"] } ``` @@ -59,7 +59,7 @@ If you want to disable the badges in the Mend Renovate App, add the `mergeConfid ```json { - "ignorePresets": ["mergeConfidence:all-badges"] + "ignorePresets": ["mergeConfidence:all-badges"] } ``` @@ -67,10 +67,10 @@ If you want to disable the badges in the Mend Renovate App, add the `mergeConfid Merge Confidence uses the following confidence levels: -- **Low**: We think the update contains breaking changes. Often this is expected because it's a `major` version update, but updates can have unknown breaking changes -- **Neutral**: We don't have enough data about the update, or we can't decide if the update should be Low or High confidence -- **High**: We rank updates as High confidence when the combination of `Age`, `Adoption` and `Passing` tests means there's a very low chance of breaking changes -- **Very High**: We only use this for updates which are months old and have either high `Adoption` or have very high test `Passing` scores +- **Low**: We think the update contains breaking changes. Often this is expected because it's a `major` version update, but updates can have unknown breaking changes +- **Neutral**: We don't have enough data about the update, or we can't decide if the update should be Low or High confidence +- **High**: We rank updates as High confidence when the combination of `Age`, `Adoption` and `Passing` tests means there's a very low chance of breaking changes +- **Very High**: We only use this for updates which are months old and have either high `Adoption` or have very high test `Passing` scores ## How it works diff --git a/docs/usage/modules/datasource/index.md b/docs/usage/modules/datasource/index.md index 63af0121af17d6..8c72c10f98d85b 100644 --- a/docs/usage/modules/datasource/index.md +++ b/docs/usage/modules/datasource/index.md @@ -12,13 +12,13 @@ But you may use datasources in a `packageRules` array to configure Renovate's be ```json { - "packageRules": [ - { - "matchDatasources": ["npm"], - "matchPackageNames": ["lodash"], - "automerge": true - } - ] + "packageRules": [ + { + "matchDatasources": ["npm"], + "matchPackageNames": ["lodash"], + "automerge": true + } + ] } ``` diff --git a/docs/usage/modules/index.md b/docs/usage/modules/index.md index 50f7fe12b8805c..a7a42e9c5ce7c2 100644 --- a/docs/usage/modules/index.md +++ b/docs/usage/modules/index.md @@ -8,7 +8,7 @@ Renovate modules, please select a subsection. ## Supported modules -- [Datasources](./datasource/index.md) -- [Managers](./manager/index.md) -- [Platform](./platform/index.md) -- [Versioning](./versioning/index.md) +- [Datasources](./datasource/index.md) +- [Managers](./manager/index.md) +- [Platform](./platform/index.md) +- [Versioning](./versioning/index.md) diff --git a/docs/usage/modules/manager/index.md b/docs/usage/modules/manager/index.md index 237c33194a4ee6..ac28a636a9beb0 100644 --- a/docs/usage/modules/manager/index.md +++ b/docs/usage/modules/manager/index.md @@ -28,9 +28,9 @@ In such a case, the manager will be disabled until you create a `fileMatch` regu ```json { - "kubernetes": { - "fileMatch": ["^config/.*\\.yaml$"] - } + "kubernetes": { + "fileMatch": ["^config/.*\\.yaml$"] + } } ``` @@ -40,9 +40,9 @@ If the default `fileMatch` regular expression for a manager does not match again ```json { - "dockerfile": { - "fileMatch": ["does-not-look-like-a-docker-file"] - } + "dockerfile": { + "fileMatch": ["does-not-look-like-a-docker-file"] + } } ``` @@ -64,9 +64,9 @@ If there was a manager called `some-new-manager` you would enable it like this: ```json { - "some-new-manager": { - "enabled": true - } + "some-new-manager": { + "enabled": true + } } ``` @@ -74,9 +74,9 @@ If there was a manager called `some-new-manager` you would enable it like this: ```json title="Example of disabling a specific manager (gradle)" { - "gradle": { - "enabled": false - } + "gradle": { + "enabled": false + } } ``` @@ -89,7 +89,7 @@ You can use the `enabledManagers` array, to list the managers you want to use (` ```json { - "enabledManagers": ["npm", "dockerfile"] + "enabledManagers": ["npm", "dockerfile"] } ``` diff --git a/docs/usage/modules/versioning/index.md b/docs/usage/modules/versioning/index.md index e9bad3fa2cc8a2..5aa3d9deccd261 100644 --- a/docs/usage/modules/versioning/index.md +++ b/docs/usage/modules/versioning/index.md @@ -21,10 +21,10 @@ Configuring or overriding the default `versioning` can be extra helpful for ecos ## General concepts behind overriding versioning -- Although you can reconfigure versioning per-manager or per-datasource, you probably don't need such a broad change -- More commonly you would need to configure `versioning` for individual packages or potentially package patterns -- The best way to do this is with `packageRules`, with a combination of `matchManagers`, `matchDatasources`, and `matchPackageNames`. - Avoid configuring `versioning` in a rule that also uses `matchUpdateTypes`, as the update types aren't known at the time the `versioning` is applied +- Although you can reconfigure versioning per-manager or per-datasource, you probably don't need such a broad change +- More commonly you would need to configure `versioning` for individual packages or potentially package patterns +- The best way to do this is with `packageRules`, with a combination of `matchManagers`, `matchDatasources`, and `matchPackageNames`. + Avoid configuring `versioning` in a rule that also uses `matchUpdateTypes`, as the update types aren't known at the time the `versioning` is applied ## Examples of versioning overrides @@ -34,13 +34,13 @@ The configuration below overrides Renovate's default `docker` versioning for the ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNames": ["python"], - "versioning": "pep440" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNames": ["python"], + "versioning": "pep440" + } + ] } ``` @@ -48,12 +48,12 @@ The configuration below overrides Renovate's default `docker` versioning for the ```json { - "packageRules": [ - { - "matchPackageNames": ["foo/bar"], - "versioning": "regex:^(?.*)-v?(?\\d+)\\.(?\\d+)\\.(?\\d+)?$" - } - ] + "packageRules": [ + { + "matchPackageNames": ["foo/bar"], + "versioning": "regex:^(?.*)-v?(?\\d+)\\.(?\\d+)\\.(?\\d+)?$" + } + ] } ``` diff --git a/docs/usage/node.md b/docs/usage/node.md index 4fcca5e694b1e1..ac0cc7ee56796f 100644 --- a/docs/usage/node.md +++ b/docs/usage/node.md @@ -16,13 +16,13 @@ Renovate understands [codenames for Node.js LTS releases](https://github.com/nod Renovate can manage the Node.js version in the following files: -- The [`engines`](https://docs.npmjs.com/files/package.json#engines) field in [`package.json`](https://docs.npmjs.com/files/package.json) -- The [`volta`](https://docs.volta.sh/guide/understanding#managing-your-project) field in [`package.json`](https://docs.npmjs.com/files/package.json) -- The [`.nvmrc`](https://github.com/creationix/nvm#nvmrc) file for the [Node Version Manager](https://github.com/creationix/nvm) -- The [`.node-version`](https://github.com/nodenv/nodenv#choosing-the-node-version) file for the [nodenv](https://github.com/nodenv/nodenv) environment manager -- The [`.tool-versions`](https://asdf-vm.com/manage/configuration.html#tool-versions) file for the [asdf](https://github.com/asdf-vm/asdf) version manager -- The [`.mise.toml`](https://mise.jdx.dev/configuration.html#mise-toml) file for the [mise](https://github.com/jdx/mise) version manager -- The [`node_js`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#Specifying-Node.js-versions) field in [`.travis.yml`](https://docs.travis-ci.com/user/customizing-the-build/) +- The [`engines`](https://docs.npmjs.com/files/package.json#engines) field in [`package.json`](https://docs.npmjs.com/files/package.json) +- The [`volta`](https://docs.volta.sh/guide/understanding#managing-your-project) field in [`package.json`](https://docs.npmjs.com/files/package.json) +- The [`.nvmrc`](https://github.com/creationix/nvm#nvmrc) file for the [Node Version Manager](https://github.com/creationix/nvm) +- The [`.node-version`](https://github.com/nodenv/nodenv#choosing-the-node-version) file for the [nodenv](https://github.com/nodenv/nodenv) environment manager +- The [`.tool-versions`](https://asdf-vm.com/manage/configuration.html#tool-versions) file for the [asdf](https://github.com/asdf-vm/asdf) version manager +- The [`.mise.toml`](https://mise.jdx.dev/configuration.html#mise-toml) file for the [mise](https://github.com/jdx/mise) version manager +- The [`node_js`](https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#Specifying-Node.js-versions) field in [`.travis.yml`](https://docs.travis-ci.com/user/customizing-the-build/) ## Configuring which version of npm Renovate uses @@ -35,9 +35,9 @@ For example, if you want to use at least npm `8.1.0` and also allow newer versio ```json title="package.json" { - "engines": { - "npm": "^8.1.0" - } + "engines": { + "npm": "^8.1.0" + } } ``` diff --git a/docs/usage/noise-reduction.md b/docs/usage/noise-reduction.md index d88a39671a5eff..057c3b674ba53e 100644 --- a/docs/usage/noise-reduction.md +++ b/docs/usage/noise-reduction.md @@ -29,12 +29,12 @@ In that case you might create a config like this: ```json { - "packageRules": [ - { - "matchPackageNames": ["/eslint/"], - "groupName": "eslint" - } - ] + "packageRules": [ + { + "matchPackageNames": ["/eslint/"], + "groupName": "eslint" + } + ] } ``` @@ -47,10 +47,10 @@ Sometimes you're better off getting a single PR per dependency! Grouping dependencies versus single PRs: -- Grouping dependencies increases the chance that the branch has an error ("break" your build) -- When you upgrade multiple dependencies in one PR, it takes longer to find out which package broke the build -- If a group PR "breaks", you'll have to wait upgrading your other dependencies until _all_ updates in the PR pass -- You will have less flexibility when one (or more) dependencies in the group have a major upgrade, but the other dependencies are good to go +- Grouping dependencies increases the chance that the branch has an error ("break" your build) +- When you upgrade multiple dependencies in one PR, it takes longer to find out which package broke the build +- If a group PR "breaks", you'll have to wait upgrading your other dependencies until _all_ updates in the PR pass +- You will have less flexibility when one (or more) dependencies in the group have a major upgrade, but the other dependencies are good to go ## Scheduling Renovate @@ -89,13 +89,13 @@ You don't want to get too far behind, so how about we update `eslint` packages o ```json title="Update ESLint packages once a month" { - "packageRules": [ - { - "matchPackageNames": ["/eslint/"], - "groupName": "eslint", - "schedule": ["on the first day of the month"] - } - ] + "packageRules": [ + { + "matchPackageNames": ["/eslint/"], + "groupName": "eslint", + "schedule": ["on the first day of the month"] + } + ] } ``` @@ -103,13 +103,13 @@ Or perhaps at least weekly: ```json title="Update ESLint packages weekly" { - "packageRules": [ - { - "matchPackageNames": ["/eslint/"], - "groupName": "eslint", - "schedule": ["before 4am on monday"] - } - ] + "packageRules": [ + { + "matchPackageNames": ["/eslint/"], + "groupName": "eslint", + "schedule": ["before 4am on monday"] + } + ] } ``` @@ -138,9 +138,9 @@ If you have an API with 100% test coverage and `express` is updated: automerge i Those of you familiar with GitHub might note that even if you automerge PRs, you are still going to get notifications (noise) anyway - one when the PR is created and another when it is merged. For this reason we recommend you consider setting `automergeType=branch` which will mean: -- Renovate first creates a branch and no PR -- If tests pass, Renovate pushes a commit directly to the base branch without PR -- If tests fail, Renovate raises a PR for you to review +- Renovate first creates a branch and no PR +- If tests pass, Renovate pushes a commit directly to the base branch without PR +- If tests fail, Renovate raises a PR for you to review The result is that passing updates are essentially "silent" - the only sign of them are the commits to your base branch. @@ -149,12 +149,12 @@ The result is that passing updates are essentially "silent" - the only sign of t Automerging is particularly beneficial if you have configured a schedule, because Renovate on its own may be able to automerge the majority of your updates. And this is especially so if your repository needs rebasing, e.g. because you use lock files. e.g. let's say you have dependencies `abc` and `xyz` with upgrades, and you use a `yarn.lock` file. -- At the start of the schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates -- After `abc` passes tests, `Renovate` will automerge it to your base branch -- The `xyz` branch probably now has `yarn.lock` conflicts -- Renovate will immediately check all other branches and rebase them -- The change to `xyz` branch will trigger another round of CI tests -- After the updated `xyz` branch passes, Renovate will automerge it too +- At the start of the schedule, `Renovate` will create branches for `abc` and `xyz` upgrades, including `yarn.lock` updates +- After `abc` passes tests, `Renovate` will automerge it to your base branch +- The `xyz` branch probably now has `yarn.lock` conflicts +- Renovate will immediately check all other branches and rebase them +- The change to `xyz` branch will trigger another round of CI tests +- After the updated `xyz` branch passes, Renovate will automerge it too This is a lot better than you waking up to two PRs and then having to deal with conflicts yourself after you merge the first one. @@ -163,15 +163,15 @@ Let's automerge it if all the linting updates pass: ```json title="Automerge ESLint packages" { - "packageRules": [ - { - "matchPackageNames": ["/eslint/"], - "groupName": "eslint", - "schedule": ["before 4am on monday"], - "automerge": true, - "automergeType": "branch" - } - ] + "packageRules": [ + { + "matchPackageNames": ["/eslint/"], + "groupName": "eslint", + "schedule": ["before 4am on monday"], + "automerge": true, + "automergeType": "branch" + } + ] } ``` diff --git a/docs/usage/nuget.md b/docs/usage/nuget.md index 151da12225bb96..948428a1d82283 100644 --- a/docs/usage/nuget.md +++ b/docs/usage/nuget.md @@ -7,18 +7,18 @@ description: NuGet (.NET) dependencies support in Renovate Renovate can upgrade dependencies in these files: -- `.csproj` -- `.fsproj` -- `.vbproj` +- `.csproj` +- `.fsproj` +- `.vbproj` ## Version Support Renovate only works with SDK-style `.csproj`, `.fsproj` or `.vbproj` files. By default, this includes: -- .NET Core 1.0 and above -- .NET Standard class libraries -- `.csproj`, `.fsproj` or `.vbproj` files that use the SDK-style syntax +- .NET Core 1.0 and above +- .NET Standard class libraries +- `.csproj`, `.fsproj` or `.vbproj` files that use the SDK-style syntax To convert your .NET Framework `.csproj`, `.fsproj` or `.vbproj` files into an SDK-style project, follow the steps in this [guide](https://natemcmaster.com/blog/2017/03/09/vs2015-to-vs2017-upgrade/). @@ -29,10 +29,10 @@ To convert your .NET Framework `.csproj`, `.fsproj` or `.vbproj` files into an S 1. Renovate looks up the latest version on [nuget.org](https://nuget.org) (or an alternative feed if configured) to see if any upgrades are available 1. If the source package includes a GitHub URL as its source, and has either: - - a "changelog" file, or - - uses GitHub releases + - a "changelog" file, or + - uses GitHub releases - then release notes for each version are embedded in the generated PR + then release notes for each version are embedded in the generated PR If your project file references a `packages.config` file, no dependencies will be extracted. Find out here how to [migrate from `packages.config` to `PackageReference`](https://docs.microsoft.com/en-us/nuget/consume-packages/migrate-packages-config-to-package-reference). @@ -42,18 +42,18 @@ Find out here how to [migrate from `packages.config` to `PackageReference`](http By default Renovate performs all lookups on `https://api.nuget.org/v3/index.json`, but you can set alternative NuGet feeds. You can set alternative feeds: -- in a [`NuGet.config` file](https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file#package-source-sections) within your repository (Renovate will not search outside the repository), or -- in a Renovate configuration options file like `renovate.json` +- in a [`NuGet.config` file](https://docs.microsoft.com/en-us/nuget/reference/nuget-config-file#package-source-sections) within your repository (Renovate will not search outside the repository), or +- in a Renovate configuration options file like `renovate.json` ```json { - "nuget": { - "registryUrls": [ - "https://api.nuget.org/v3/index.json", - "https://example1.com/nuget/", - "https://example2.com/nuget/v3/index.json" - ] - } + "nuget": { + "registryUrls": [ + "https://api.nuget.org/v3/index.json", + "https://example1.com/nuget/", + "https://example2.com/nuget/v3/index.json" + ] + } } ``` @@ -80,24 +80,24 @@ So Renovate behaves like the official NuGet client. If a `v3` feed URL does not end with `index.json`, you must specify the version explicitly. -- If the feed is defined in a `NuGet.config` file set the `protocolVersion` attribute to `3`: +- If the feed is defined in a `NuGet.config` file set the `protocolVersion` attribute to `3`: - ```xml - - - - - ``` + ```xml + + + + + ``` -- If the feed is defined via Renovate configuration append `#protocolVersion=3` to the registry URL: +- If the feed is defined via Renovate configuration append `#protocolVersion=3` to the registry URL: - ```json - { - "nuget": { - "registryUrls": ["http://myV3feed#protocolVersion=3"] + ```json + { + "nuget": { + "registryUrls": ["http://myV3feed#protocolVersion=3"] + } } - } - ``` + ``` You may need this workaround when you use the JFrog Artifactory. @@ -107,14 +107,14 @@ Credentials for authenticated/private feeds can be given via host rules in the c ```json { - "hostRules": [ - { - "hostType": "nuget", - "matchHost": "http://example1.com/nuget", - "username": "root", - "password": "p4$$w0rd" - } - ] + "hostRules": [ + { + "hostType": "nuget", + "matchHost": "http://example1.com/nuget", + "username": "root", + "password": "p4$$w0rd" + } + ] } ``` diff --git a/docs/usage/opentelemetry.md b/docs/usage/opentelemetry.md index bfec6276211516..57670371641644 100644 --- a/docs/usage/opentelemetry.md +++ b/docs/usage/opentelemetry.md @@ -13,9 +13,9 @@ Renovate partially supports OpenTelemetry, the emerging monitoring standard. OpenTelemetry has three types of observability data: -- traces -- metrics -- logs +- traces +- metrics +- logs ## Limitations @@ -32,9 +32,9 @@ This variable controls the endpoint for the telemetry data. Once this endpoint is set, you can use all environment variables listed in the [OpenTelemetry specification](https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/configuration/sdk-environment-variables.md). You can also set the following environment variables: -- `OTEL_SERVICE_NAME`: to control the service name that will be emitted in traces, defaults to `renovate` -- `OTEL_SERVICE_NAMESPACE`: to control the service namespace that will be emitted in traces, defaults to `renovatebot.com` -- `OTEL_SERVICE_VERSION`: to control the service version that will be emitted in traces, defaults to using the release version of Renovate +- `OTEL_SERVICE_NAME`: to control the service name that will be emitted in traces, defaults to `renovate` +- `OTEL_SERVICE_NAMESPACE`: to control the service namespace that will be emitted in traces, defaults to `renovatebot.com` +- `OTEL_SERVICE_VERSION`: to control the service version that will be emitted in traces, defaults to using the release version of Renovate ## Debugging diff --git a/docs/usage/php.md b/docs/usage/php.md index 358d14c0143981..a02827fcb3f36b 100644 --- a/docs/usage/php.md +++ b/docs/usage/php.md @@ -25,19 +25,19 @@ If you are using a [privately hosted Composer package](https://getcomposer.org/d ```json { - "hostRules": [ - { - "matchHost": "some.vendor.com", - "hostType": "packagist", - "username": "", - "password": "" - }, - { - "matchHost": "bearer-auth.for.vendor.com", - "hostType": "packagist", - "token": "abcdef0123456789" - } - ] + "hostRules": [ + { + "matchHost": "some.vendor.com", + "hostType": "packagist", + "username": "", + "password": "" + }, + { + "matchHost": "bearer-auth.for.vendor.com", + "hostType": "packagist", + "token": "abcdef0123456789" + } + ] } ``` @@ -49,22 +49,22 @@ You may encrypt your `password` only, but you can encrypt your `username` as wel ```json { - "hostRules": [ - { - "matchHost": "some.vendor.com", - "hostType": "packagist", - "encrypted": { - "username": "", - "password": "" - } - }, - { - "matchHost": "bearer-auth.for.vendor.com", - "hostType": "packagist", - "encrypted": { - "token": "" - } - } - ] + "hostRules": [ + { + "matchHost": "some.vendor.com", + "hostType": "packagist", + "encrypted": { + "username": "", + "password": "" + } + }, + { + "matchHost": "bearer-auth.for.vendor.com", + "hostType": "packagist", + "encrypted": { + "token": "" + } + } + ] } ``` diff --git a/docs/usage/python.md b/docs/usage/python.md index 6b3751c2134360..314e65ecc03791 100644 --- a/docs/usage/python.md +++ b/docs/usage/python.md @@ -37,10 +37,10 @@ By default Renovate checks for upgrades on the `pypi.org` registry. If you want, you can set alternative index URLs. There are three ways to do this: -- index-url in `requirements.txt` -- sources in `Pipfile` -- sources in `pyproject.toml` -- set URL in Renovate configuration +- index-url in `requirements.txt` +- sources in `Pipfile` +- sources in `pyproject.toml` +- set URL in Renovate configuration ### index-url in `requirements.txt` @@ -65,12 +65,12 @@ Fill the array with alternate index URL(s). ```json { - "packageRules": [ - { - "matchDatasources": ["pypi"], - "registryUrls": ["http://example.com/private-pypi/"] - } - ] + "packageRules": [ + { + "matchDatasources": ["pypi"], + "registryUrls": ["http://example.com/private-pypi/"] + } + ] } ``` @@ -84,9 +84,9 @@ Fill the array with alternate index URL(s). ```json title="Disabling all managers where language is set to Python" { - "python": { - "enabled": false - } + "python": { + "enabled": false + } } ``` @@ -94,6 +94,6 @@ Alternatively, you can use `enabledManagers` to tell Renovate what package manag ```json title="Only use Renovate's npm package manager" { - "enabledManagers": ["npm"] + "enabledManagers": ["npm"] } ``` diff --git a/docs/usage/reading-list.md b/docs/usage/reading-list.md index e36b01a1b15987..b90abcd6cad09b 100644 --- a/docs/usage/reading-list.md +++ b/docs/usage/reading-list.md @@ -10,9 +10,9 @@ How much you should read depends on how much you want to customize Renovate's be We created reading lists for these types of users: -- Beginners -- Intermediate -- Advanced +- Beginners +- Intermediate +- Advanced Start with the "Beginners" reading list. If you're self-hosting or need to update private packages, complete the relevant reading lists for those. @@ -21,35 +21,35 @@ If you're self-hosting or need to update private packages, complete the relevant If you're new to Renovate, you should: -- Use the Mend Renovate App, or let someone else host Renovate for you -- Stick with the `config:recommended` preset -- Use the Dependency Dashboard (`config:recommended` enables it automatically) -- Read the pages in the "Beginners" list -- Only create custom Renovate configuration when really needed +- Use the Mend Renovate App, or let someone else host Renovate for you +- Stick with the `config:recommended` preset +- Use the Dependency Dashboard (`config:recommended` enables it automatically) +- Read the pages in the "Beginners" list +- Only create custom Renovate configuration when really needed ## Beginners Start by reading: -- [Installing & Onboarding](./getting-started/installing-onboarding.md) -- [Key concepts, Dependency Dashboard](./key-concepts/dashboard.md) -- [Use Cases](./getting-started/use-cases.md) -- [Running Renovate](./getting-started/running.md) -- [Troubleshooting](./troubleshooting.md) -- [Known limitations](./known-limitations.md) -- [Release notes for major versions](./release-notes-for-major-versions.md) +- [Installing & Onboarding](./getting-started/installing-onboarding.md) +- [Key concepts, Dependency Dashboard](./key-concepts/dashboard.md) +- [Use Cases](./getting-started/use-cases.md) +- [Running Renovate](./getting-started/running.md) +- [Troubleshooting](./troubleshooting.md) +- [Known limitations](./known-limitations.md) +- [Release notes for major versions](./release-notes-for-major-versions.md) ## Intermediate First, complete the "Beginners" reading list. Read this list _after_ experiencing Renovate's default behavior, once you really want/need to make changes to Renovate's behavior. -- [Upgrade best practices](./upgrade-best-practices.md) -- [Key concepts, presets](./key-concepts/presets.md) -- [Key concepts, Renovate scheduling](./key-concepts/scheduling.md) -- [Key concepts, automerge](./key-concepts/automerge.md) -- [Key concepts, pull requests](./key-concepts/pull-requests.md) -- [Noise Reduction](./noise-reduction.md) +- [Upgrade best practices](./upgrade-best-practices.md) +- [Key concepts, presets](./key-concepts/presets.md) +- [Key concepts, Renovate scheduling](./key-concepts/scheduling.md) +- [Key concepts, automerge](./key-concepts/automerge.md) +- [Key concepts, pull requests](./key-concepts/pull-requests.md) +- [Noise Reduction](./noise-reduction.md) Skim the [repository configuration options](./configuration-options.md) to learn about the kind of customizations you can make to Renovate. Feel free to read up on anything that looks interesting to you. @@ -59,20 +59,20 @@ Feel free to read up on anything that looks interesting to you. First, complete the "Beginners" and the "Intermediate" reading list. Then read: -- Define your own custom manager with [`customManagers`](./configuration-options.md#custommanagers) (previously `regexManagers`) -- Define your own custom datasources with [`customDatasources`](./configuration-options.md#customdatasources) -- [Shareable config presets](./config-presets.md) +- Define your own custom manager with [`customManagers`](./configuration-options.md#custommanagers) (previously `regexManagers`) +- Define your own custom datasources with [`customDatasources`](./configuration-options.md#customdatasources) +- [Shareable config presets](./config-presets.md) ## Self-hosting Renovate If you're going to self-host Renovate then read: -- [Running Renovate](./getting-started/running.md) -- [Self-hosting examples](./examples/self-hosting.md) -- Skim the [self hosted configuration options](./self-hosted-configuration.md) +- [Running Renovate](./getting-started/running.md) +- [Self-hosting examples](./examples/self-hosting.md) +- Skim the [self hosted configuration options](./self-hosted-configuration.md) ## Private packages If you want Renovate to update private packages then read: -- [Private package support](./getting-started/private-packages.md) +- [Private package support](./getting-started/private-packages.md) diff --git a/docs/usage/release-notes-for-major-versions.md b/docs/usage/release-notes-for-major-versions.md index cc1b650b2908c4..6b4df70af7088a 100644 --- a/docs/usage/release-notes-for-major-versions.md +++ b/docs/usage/release-notes-for-major-versions.md @@ -13,26 +13,26 @@ You also don't have to scroll to the bottom of the page to find the latest relea General: -- Require Node.js 20 ([#30291](https://github.com/renovatebot/renovate/pull/30291)) -- The Renovate Docker images no longer have `-slim` tags. You must stop using the `-slim` prefix. Renovate now defaults to the `-slim` tag type behavior. +- Require Node.js 20 ([#30291](https://github.com/renovatebot/renovate/pull/30291)) +- The Renovate Docker images no longer have `-slim` tags. You must stop using the `-slim` prefix. Renovate now defaults to the `-slim` tag type behavior. Specific: -- **bitbucket-server:** autodetect `gitAuthor`, if possible ([#29525](https://github.com/renovatebot/renovate/pull/29525)) -- **config:** change from `boolean` to `enum` for `onboardingNoDeps`. Renovate now onboards repositories with no dependencies, with one exception: if you run Renovate in `autodiscover` mode then you must manually onboard Renovate for repos with no dependencies -- **config:** sanitize special characters from branch names for vulnerability type PRs. This may cause Renovate to autoclose/replace existing PRs -- **config:** change the order of `globalExtends` resolution, it is applied _first_ and remaining global config takes precedence -- **datasource/docker:** Docker Hub lookups prefers `hub.docker.com` over `index.docker.io`. To revert to the old behavior: set `RENOVATE_X_DOCKER_HUB_TAGS_DISABLE=true` in your env -- **git:** check _all_ commits on the branch to decide if the branch was modified ([#28225](https://github.com/renovatebot/renovate/pull/28225)) -- **gitea:** use "bearer auth" instead of "token auth" to authenticate to the Gitea platform -- **github:** if you run Renovate as a GitHub app then `platformCommit` is automatically enabled -- **http:** remove `dnsCache` -- **logging:** you must set file logging via env, not in `config.js` -- **manager/pep621:** change `depName` for `pep621` dependencies. This causes the branch name for `pep621` updates to change, which in turn means Renovate may autoclose and re-open some `pep621` PRs. Also, Renovate may start grouping dependencies into a single PR. -- **npm:** for npm versions lower than 7, drop support for remediating vulnerabilities in _transitive_ dependencies -- **npm:** remove `RENOVATE_CACHE_NPM_MINUTES` ([#28715](https://github.com/renovatebot/renovate/pull/28715)) -- **packageRules:** `matchPackageNames` (and related functions) no longer fall back to checking `depName` -- **packageRules:** `matchPackageNames` exact matches are now case-insensitive +- **bitbucket-server:** autodetect `gitAuthor`, if possible ([#29525](https://github.com/renovatebot/renovate/pull/29525)) +- **config:** change from `boolean` to `enum` for `onboardingNoDeps`. Renovate now onboards repositories with no dependencies, with one exception: if you run Renovate in `autodiscover` mode then you must manually onboard Renovate for repos with no dependencies +- **config:** sanitize special characters from branch names for vulnerability type PRs. This may cause Renovate to autoclose/replace existing PRs +- **config:** change the order of `globalExtends` resolution, it is applied _first_ and remaining global config takes precedence +- **datasource/docker:** Docker Hub lookups prefers `hub.docker.com` over `index.docker.io`. To revert to the old behavior: set `RENOVATE_X_DOCKER_HUB_TAGS_DISABLE=true` in your env +- **git:** check _all_ commits on the branch to decide if the branch was modified ([#28225](https://github.com/renovatebot/renovate/pull/28225)) +- **gitea:** use "bearer auth" instead of "token auth" to authenticate to the Gitea platform +- **github:** if you run Renovate as a GitHub app then `platformCommit` is automatically enabled +- **http:** remove `dnsCache` +- **logging:** you must set file logging via env, not in `config.js` +- **manager/pep621:** change `depName` for `pep621` dependencies. This causes the branch name for `pep621` updates to change, which in turn means Renovate may autoclose and re-open some `pep621` PRs. Also, Renovate may start grouping dependencies into a single PR. +- **npm:** for npm versions lower than 7, drop support for remediating vulnerabilities in _transitive_ dependencies +- **npm:** remove `RENOVATE_CACHE_NPM_MINUTES` ([#28715](https://github.com/renovatebot/renovate/pull/28715)) +- **packageRules:** `matchPackageNames` (and related functions) no longer fall back to checking `depName` +- **packageRules:** `matchPackageNames` exact matches are now case-insensitive ### Commentary for 38 @@ -83,8 +83,8 @@ We also enabled patterns for the `matchPackageNames` config option. This means you can now use regex or glob patterns: -- `"matchPackageNames": "/^com.renovatebot/"` (regex) -- `"matchPackageNames": "@renovate/*"` (glob) +- `"matchPackageNames": "/^com.renovatebot/"` (regex) +- `"matchPackageNames": "@renovate/*"` (glob) And of course, you can still use exact name matching. @@ -96,7 +96,7 @@ And of course, you can still use exact name matching. ### Breaking changes for 37 -- **npm:** drop explicit lerna support +- **npm:** drop explicit lerna support ### Commentary for 37 @@ -113,34 +113,34 @@ If you're on a version of Lerna before v7, you should prioritize upgrading to v7 ### Breaking changes for 36 -- postUpgradeTasks.fileFilters is now optional and defaults to all files -- `languages` are now called `categories` instead. Use `matchCategories` in `packageRules` -- Node v19 is no longer supported -- **datasource:** `semver-coerced` is now the default versioning -- **presets:** Preset `config:base` is now called `config:recommended` (will be migrated automatically) -- remove `BUILDPACK` env support -- **package-rules:** `matchPackageNames` now matches both `depName` (existing) and `packageName` (new) and warns if only `depName` matches -- **release-notes:** Release notes won't be fetched early for `commitBody` insertion unless explicitly configured with `fetchReleaseNotes=branch` -- `dockerImagePrefix` is now replaced by `dockerSidecarImage` -- `matchPaths` and `matchFiles` are now combined into `matchFileNames`, supporting exact match and glob-only. The "any string match" functionality of `matchPaths` is now removed -- **presets:** v25 compatibility for language-based branch prefixes is removed -- **npm:** Rollback PRs will no longer be enabled by default for npm (they are now disabled by default for all managers) -- **post-upgrade-tasks:** dot files will now be included by default for all minimatch results -- **platform/gitlab:** GitLab `gitAuthor` will change from the account's "email" to "commit_email" if they are different -- **automerge:** Platform automerge will now be chosen by default whenever automerge is enabled -- Post upgrade templating is now allowed by default, as long as the post upgrade task command is itself already allowed -- Official Renovate Docker images now use the "slim" approach with `binarySource=install` by default. e.g. `renovate/renovate:latest` is the slim image, not full -- The "full" image is now available via the tag `full`, e.g. `renovate/renovate:38-full`, and defaults to `binarySource=global` (no dynamic installs) -- Third party tools in the full image have been updated to latest/LTS major version +- postUpgradeTasks.fileFilters is now optional and defaults to all files +- `languages` are now called `categories` instead. Use `matchCategories` in `packageRules` +- Node v19 is no longer supported +- **datasource:** `semver-coerced` is now the default versioning +- **presets:** Preset `config:base` is now called `config:recommended` (will be migrated automatically) +- remove `BUILDPACK` env support +- **package-rules:** `matchPackageNames` now matches both `depName` (existing) and `packageName` (new) and warns if only `depName` matches +- **release-notes:** Release notes won't be fetched early for `commitBody` insertion unless explicitly configured with `fetchReleaseNotes=branch` +- `dockerImagePrefix` is now replaced by `dockerSidecarImage` +- `matchPaths` and `matchFiles` are now combined into `matchFileNames`, supporting exact match and glob-only. The "any string match" functionality of `matchPaths` is now removed +- **presets:** v25 compatibility for language-based branch prefixes is removed +- **npm:** Rollback PRs will no longer be enabled by default for npm (they are now disabled by default for all managers) +- **post-upgrade-tasks:** dot files will now be included by default for all minimatch results +- **platform/gitlab:** GitLab `gitAuthor` will change from the account's "email" to "commit_email" if they are different +- **automerge:** Platform automerge will now be chosen by default whenever automerge is enabled +- Post upgrade templating is now allowed by default, as long as the post upgrade task command is itself already allowed +- Official Renovate Docker images now use the "slim" approach with `binarySource=install` by default. e.g. `renovate/renovate:latest` is the slim image, not full +- The "full" image is now available via the tag `full`, e.g. `renovate/renovate:38-full`, and defaults to `binarySource=global` (no dynamic installs) +- Third party tools in the full image have been updated to latest/LTS major version ### Commentary for 36 If you're self-hosting Renovate, pay particular attention to: -- Do you want to run the full, or slim versions of the image? We have switched the defaults (latest is now slim, not full) -- Have you configured `dockerImagePrefix`? If so then you need to use `dockerSidecarImage` instead -- If you're using `config:base` in your `onboardingConfig` then switch to `config:recommended` -- `gitAuthor` may change if you're on GitLab and have a different commit email for your bot account. If so then configure `gitIgnoredAuthors` with the old email +- Do you want to run the full, or slim versions of the image? We have switched the defaults (latest is now slim, not full) +- Have you configured `dockerImagePrefix`? If so then you need to use `dockerSidecarImage` instead +- If you're using `config:base` in your `onboardingConfig` then switch to `config:recommended` +- `gitAuthor` may change if you're on GitLab and have a different commit email for your bot account. If so then configure `gitIgnoredAuthors` with the old email ### Link to release notes for 36 @@ -150,18 +150,18 @@ If you're self-hosting Renovate, pay particular attention to: ### Breaking changes for 35 -- require NodeJS v18.12+ ([#20838](https://github.com/renovatebot/renovate/pull/20838)) -- **config:** Forked repos will now be processed automatically if `autodiscover=false`. `includeForks` is removed and replaced by new option `forkProcessing` -- Internal checks such as `renovate/stability-days` will no longer count as passing/green, meaning that actions such as `automerge` won't occur if the only checks are Renovate internal ones. Set `internalChecksAsSuccess=true` to restore existing behavior -- **versioning:** default versioning is now `semver-coerced`, instead of `semver` -- **datasource/github-releases:** Regex Manager configurations relying on the github-release data-source with digests will have different digest semantics. The digest will now always correspond to the underlying Git SHA of the release/version. The old behavior can be preserved by switching to the github-release-attachments datasource -- **versioning:** bump short ranges to version ([#20494](https://github.com/renovatebot/renovate/pull/20494)) -- **config:** `containerbase/` account used for sidecar containers instead of `renovate/` -- **go:** Renovate will now use go's default `GOPROXY` settings. To avoid using the public proxy, configure `GOPROXY=direct` -- **datasource/npm:** Package cache will include entries for up to 24 hours after the last lookup. Set `cacheHardTtlMinutes=0` to revert to existing behavior -- **config:** Renovate now defaults to applying hourly and concurrent PR limits. To revert to unlimited, configure them back to `0` -- **config:** Renovate will now default to updating locked dependency versions. To revert to previous behavior, configure `rangeStrategy=replace` -- **config:** PyPI releases will no longer be filtered by default based on `constraints.python` compatibility. To retain existing functionality, set `constraintsFiltering=strict` +- require NodeJS v18.12+ ([#20838](https://github.com/renovatebot/renovate/pull/20838)) +- **config:** Forked repos will now be processed automatically if `autodiscover=false`. `includeForks` is removed and replaced by new option `forkProcessing` +- Internal checks such as `renovate/stability-days` will no longer count as passing/green, meaning that actions such as `automerge` won't occur if the only checks are Renovate internal ones. Set `internalChecksAsSuccess=true` to restore existing behavior +- **versioning:** default versioning is now `semver-coerced`, instead of `semver` +- **datasource/github-releases:** Regex Manager configurations relying on the github-release data-source with digests will have different digest semantics. The digest will now always correspond to the underlying Git SHA of the release/version. The old behavior can be preserved by switching to the github-release-attachments datasource +- **versioning:** bump short ranges to version ([#20494](https://github.com/renovatebot/renovate/pull/20494)) +- **config:** `containerbase/` account used for sidecar containers instead of `renovate/` +- **go:** Renovate will now use go's default `GOPROXY` settings. To avoid using the public proxy, configure `GOPROXY=direct` +- **datasource/npm:** Package cache will include entries for up to 24 hours after the last lookup. Set `cacheHardTtlMinutes=0` to revert to existing behavior +- **config:** Renovate now defaults to applying hourly and concurrent PR limits. To revert to unlimited, configure them back to `0` +- **config:** Renovate will now default to updating locked dependency versions. To revert to previous behavior, configure `rangeStrategy=replace` +- **config:** PyPI releases will no longer be filtered by default based on `constraints.python` compatibility. To retain existing functionality, set `constraintsFiltering=strict` ### Commentary for 35 @@ -179,7 +179,7 @@ This will mean that you start seeing some "lockfile-only" PRs for in-range updat ### Breaking changes for 34 -- Revert `branchNameStrict` to `false` +- Revert `branchNameStrict` to `false` ### Commentary for 34 @@ -190,8 +190,8 @@ If you are upgrading from v32 to v34 then it means that the setting for `branchN If you already upgraded from v32 to v33 then you have a decision to make first: -- set `branchNameStrict` to `true` (like in v33), -- or let it set back to `false` (like in v32). +- set `branchNameStrict` to `true` (like in v33), +- or let it set back to `false` (like in v32). Strict branch naming meant that all special characters other than letters, numbers and hyphens were converted to hyphens and then deduplicated, e.g. a branch which in v32 was like `renovate/abc.def-2.x` would become `renovate/abc-def-2-x` in v33. If you prefer to revert back to the old way then that will happen automatically in v34. @@ -207,32 +207,32 @@ Apologies to anyone negatively affected by this v33 change. ### Breaking changes for 33 -- Node 16 is the required runtime for Renovate -- [NOTE: This was reverted in `v34`] **config:** `branchNameStrict` default value is now `true` -- **config:** `internalChecksFilter` default value is now `"strict"` -- **config:** `ignoreScripts` default value is now `true`. If `allowScripts=true` in global config, `ignoreScripts` must be set to `false` in repo config if you want all repos to run scripts -- **config:** `autodiscover` filters can no longer include commas -- **config:** boolean variables must be `true` or `false` when configured in environment variables, and errors will be thrown for invalid values. Previously invalided values were ignored and treated as `false` -- **datasource/go:** `git-tags` datasource will be used as the fallback instead of `github-tags` if a go package's host type is unknown -- **jsonnet-bundler:** `depName` now uses the "absolute import" format (e.g. `bar`-> `github.com/foo/bar/baz-wow`) -- **azure-pipelines:** azure-pipelines manager is now disabled by default -- **github:** No longer necessary to configure forkMode. Forking mode is now experimental -- Users of `containerbase` images (such as official Renovate images) will now have dynamic package manager installs enabled by default -- Dependencies are no longer automatically pinned if `rangeStrategy=auto`, pinning must be opted into using `rangeStrategy=pin` +- Node 16 is the required runtime for Renovate +- [NOTE: This was reverted in `v34`] **config:** `branchNameStrict` default value is now `true` +- **config:** `internalChecksFilter` default value is now `"strict"` +- **config:** `ignoreScripts` default value is now `true`. If `allowScripts=true` in global config, `ignoreScripts` must be set to `false` in repo config if you want all repos to run scripts +- **config:** `autodiscover` filters can no longer include commas +- **config:** boolean variables must be `true` or `false` when configured in environment variables, and errors will be thrown for invalid values. Previously invalided values were ignored and treated as `false` +- **datasource/go:** `git-tags` datasource will be used as the fallback instead of `github-tags` if a go package's host type is unknown +- **jsonnet-bundler:** `depName` now uses the "absolute import" format (e.g. `bar`-> `github.com/foo/bar/baz-wow`) +- **azure-pipelines:** azure-pipelines manager is now disabled by default +- **github:** No longer necessary to configure forkMode. Forking mode is now experimental +- Users of `containerbase` images (such as official Renovate images) will now have dynamic package manager installs enabled by default +- Dependencies are no longer automatically pinned if `rangeStrategy=auto`, pinning must be opted into using `rangeStrategy=pin` ### Commentary for 33 This release contains some changes of default values/behavior: -- `internalChecksFilter` will now default to `strict`, meaning that updates will be withheld by default when internal status checks are pending. This should reduce the number of "non-actionable" Pull Requests you get -- `azure-pipelines` manager is disabled by default, because its primary datasource can unfortunately suggest updates which aren't yet installable. Users should opt into this manager once they know the risks -- `binarySource=install` will now be used instead of `global` whenever Renovate is run within a "containerbase" image. This means dynamic installation of most package managers and languages -- Dependencies will no longer be pinned by default if `rangeStrategy=auto`. While we recommend pinning dependencies, we decided users should opt into this more explicitly +- `internalChecksFilter` will now default to `strict`, meaning that updates will be withheld by default when internal status checks are pending. This should reduce the number of "non-actionable" Pull Requests you get +- `azure-pipelines` manager is disabled by default, because its primary datasource can unfortunately suggest updates which aren't yet installable. Users should opt into this manager once they know the risks +- `binarySource=install` will now be used instead of `global` whenever Renovate is run within a "containerbase" image. This means dynamic installation of most package managers and languages +- Dependencies will no longer be pinned by default if `rangeStrategy=auto`. While we recommend pinning dependencies, we decided users should opt into this more explicitly And two major features! -- AWS CodeCommit platform support -- OpenTelemetry support +- AWS CodeCommit platform support +- OpenTelemetry support Both the above are considered "experimental". Please test them out and let us know your feedback - both positive or negative - so that we can progress them to fully available. diff --git a/docs/usage/rust.md b/docs/usage/rust.md index 594abea989aab8..00c8b367d126be 100644 --- a/docs/usage/rust.md +++ b/docs/usage/rust.md @@ -23,8 +23,8 @@ Renovate updates Rust crates by default. Renovate can find private registry URLs in these Cargo configuration files: -- `.cargo/config.toml` -- `.cargo/config` (legacy) +- `.cargo/config.toml` +- `.cargo/config` (legacy) Renovate can also find private registry URLs via a `CARGO_REGISTRIES__INDEX` environment variable. Read the [Rust environment variables docs](https://doc.rust-lang.org/cargo/reference/environment-variables.html#configuration-environment-variables) to learn more. @@ -38,17 +38,17 @@ You can also configure a `hostRules` that's only for Cargo authentication (e.g. ```js title="Example of authentication for a private GitHub and Cargo registry:" module.exports = { - hostRules: [ - { - matchHost: 'github.enterprise.com', - token: process.env.GITHUB_TOKEN, - hostType: 'github', - }, - { - matchHost: 'someGitHost.enterprise.com', - token: process.env.CARGO_GIT_TOKEN, - hostType: 'cargo', - }, - ], + hostRules: [ + { + matchHost: 'github.enterprise.com', + token: process.env.GITHUB_TOKEN, + hostType: 'github', + }, + { + matchHost: 'someGitHost.enterprise.com', + token: process.env.CARGO_GIT_TOKEN, + hostType: 'cargo', + }, + ], }; ``` diff --git a/docs/usage/security-and-permissions.md b/docs/usage/security-and-permissions.md index 3509847d322958..0f30800d269c37 100644 --- a/docs/usage/security-and-permissions.md +++ b/docs/usage/security-and-permissions.md @@ -78,8 +78,8 @@ This also means the process has the same level of access to information and reso All self-hosted Renovate instances must operate under a trust relationship with the developers of the monitored repositories. This has the following implications: -- Access to information -- Execution of code +- Access to information +- Execution of code Keep reading to learn more. @@ -93,8 +93,8 @@ This includes sensitive data that may be stored within the environment where Ren In certain scenarios, code from the monitored repository is executed as part of the update process. This is particularly true during, for example: -- `postUpgradeTasks`, where scripts specified by the repository are run -- when a wrapper within the repository is called, like `gradlew` +- `postUpgradeTasks`, where scripts specified by the repository are run +- when a wrapper within the repository is called, like `gradlew` These scripts can contain arbitrary code. This may pose a significant security risk if the repository's integrity is compromised, or if the repository maintainers have malicious intentions. @@ -116,10 +116,10 @@ The Renovate maintainers recommend you follow these guidelines. _Before_ integrating a repository with your self-hosted Renovate instance, thoroughly vet the repository for security and trustworthiness. This means that you should review the: -- repository's ownership -- contribution history -- open issues -- open pull requests +- repository's ownership +- contribution history +- open issues +- open pull requests ###### Limit permissions @@ -147,9 +147,9 @@ This makes sure that sensitive data is not exposed as plain text. Ensure that the logging infrastructure is configured to handle logs as sensitive data. This includes measures like: -- log encryption -- access controls to restrict log viewing to authorized personnel only -- secure storage and transmission of log data +- log encryption +- access controls to restrict log viewing to authorized personnel only +- secure storage and transmission of log data ###### Log review and redaction processes diff --git a/docs/usage/self-hosted-configuration.md b/docs/usage/self-hosted-configuration.md index 895ea0a3bd774e..3d91d94a354b93 100644 --- a/docs/usage/self-hosted-configuration.md +++ b/docs/usage/self-hosted-configuration.md @@ -27,7 +27,7 @@ Let's look at an example of configuring packages with existing Angular migration ```javascript module.exports = { - allowedPostUpgradeCommands: ['^npm ci --ignore-scripts$', '^npx ng update'], + allowedPostUpgradeCommands: ['^npm ci --ignore-scripts$', '^npx ng update'], }; ``` @@ -37,17 +37,17 @@ The command to install dependencies (`npm ci --ignore-scripts`) is needed becaus ```json { - "packageRules": [ - { - "matchPackageNames": ["@angular/core"], - "postUpgradeTasks": { - "commands": [ - "npm ci --ignore-scripts", - "npx ng update {{{depName}}} --from={{{currentVersion}}} --to={{{newVersion}}} --migrate-only --allow-dirty --force" - ] - } - } - ] + "packageRules": [ + { + "matchPackageNames": ["@angular/core"], + "postUpgradeTasks": { + "commands": [ + "npm ci --ignore-scripts", + "npx ng update {{{depName}}} --from={{{currentVersion}}} --to={{{newVersion}}} --migrate-only --allow-dirty --force" + ] + } + } + ] } ``` @@ -72,10 +72,10 @@ Examples: ```json title="renovate.json" { - "env": { - "SOME_ENV_VARIABLE": "some_value", - "EXTRA_ENV_NAME": "value" - } + "env": { + "SOME_ENV_VARIABLE": "some_value", + "EXTRA_ENV_NAME": "value" + } } ``` @@ -83,7 +83,7 @@ The above would require `allowedEnv` to be configured similar to the following: ```js title="config.js" module.exports = { - allowedEnv: ['SOME_ENV_*', 'EXTRA_ENV_NAME'], + allowedEnv: ['SOME_ENV_*', 'EXTRA_ENV_NAME'], }; ``` @@ -110,14 +110,14 @@ Examples: ```json { - "hostRules": [ - { - "matchHost": "https://domain.com/all-versions", - "headers": { - "X-Auth-Token": "secret" - } - } - ] + "hostRules": [ + { + "matchHost": "https://domain.com/all-versions", + "headers": { + "X-Auth-Token": "secret" + } + } + ] } ``` @@ -125,7 +125,7 @@ Or with custom `allowedHeaders`: ```js title="config.js" module.exports = { - allowedHeaders: ['custom-header'], + allowedHeaders: ['custom-header'], }; ``` @@ -138,7 +138,7 @@ For example: ```json { - "allowedPostUpgradeCommands": ["^tslint --fix$", "^tslint --[a-z]+$"] + "allowedPostUpgradeCommands": ["^tslint --fix$", "^tslint --[a-z]+$"] } ``` @@ -173,7 +173,7 @@ The configuration: ```json { - "autodiscoverFilter": ["my-org/*"] + "autodiscoverFilter": ["my-org/*"] } ``` @@ -185,7 +185,7 @@ All text inside the start and end `/` will be treated as a regular expression. ```json { - "autodiscoverFilter": ["/project/.*/"] + "autodiscoverFilter": ["/project/.*/"] } ``` @@ -195,7 +195,7 @@ If using negations, all repositories except those who match the regex are added ```json { - "autodiscoverFilter": ["!/project/.*/"] + "autodiscoverFilter": ["!/project/.*/"] } ``` @@ -208,8 +208,8 @@ For example: ```json { - "platform": "gitlab", - "autodiscoverNamespaces": ["a-group", "another-group/some-subgroup"] + "platform": "gitlab", + "autodiscoverNamespaces": ["a-group", "another-group/some-subgroup"] } ``` @@ -225,8 +225,8 @@ This feature is useful for users who want Renovate to only work on repositories ```json title="Example for Bitbucket" { - "platform": "bitbucket", - "autodiscoverProjects": ["a-group", "!another-group/some-subgroup"] + "platform": "bitbucket", + "autodiscoverProjects": ["a-group", "!another-group/some-subgroup"] } ``` @@ -254,7 +254,7 @@ For example: ```json { - "autodiscoverTopics": ["managed-by-renovate"] + "autodiscoverTopics": ["managed-by-renovate"] } ``` @@ -267,7 +267,7 @@ For example: ```json { - "baseDir": "/my-own-different-temporary-folder" + "baseDir": "/my-own-different-temporary-folder" } ``` @@ -285,10 +285,10 @@ Renovate often needs to use third-party tools in its PRs, like `npm` to update ` Renovate supports four possible ways to access those tools: -- `global`: Uses pre-installed tools, e.g. `npm` installed via `npm install -g npm`. -- `install` (default): Downloads and installs tools at runtime if running in a [Containerbase](https://github.com/containerbase/base) environment, otherwise falls back to `global` -- `docker`: Runs tools inside Docker "sidecar" containers using `docker run`. -- `hermit`: Uses the [Hermit](https://github.com/cashapp/hermit) tool installation approach. +- `global`: Uses pre-installed tools, e.g. `npm` installed via `npm install -g npm`. +- `install` (default): Downloads and installs tools at runtime if running in a [Containerbase](https://github.com/containerbase/base) environment, otherwise falls back to `global` +- `docker`: Runs tools inside Docker "sidecar" containers using `docker run`. +- `hermit`: Uses the [Hermit](https://github.com/cashapp/hermit) tool installation approach. Starting in v36, Renovate's default Docker image (previously referred to as the "slim" image) uses `binarySource=install` while the "full" Docker image uses `binarySource=global`. If you are running Renovate in an environment where runtime download and install of tools is not possible then you should use the "full" image. @@ -311,8 +311,8 @@ For example: ```json { - "baseDir": "/my-own-different-temporary-folder", - "cacheDir": "/my-own-different-cache-folder" + "baseDir": "/my-own-different-temporary-folder", + "cacheDir": "/my-own-different-cache-folder" } ``` @@ -324,8 +324,8 @@ It should be set to a non-zero value, recommended to be at least 60 (i.e. one ho When this value is set, the `npm` datasource will use the `cacheHardTtlMinutes` value for cache expiry, instead of its default expiry of 15 minutes, which becomes the "soft" expiry value. Results which are soft expired are reused in the following manner: -- The `etag` from the cached results will be reused, and may result in a 304 response, meaning cached results are revalidated -- If an error occurs when querying the `npmjs` registry, then soft expired results will be reused if they are present +- The `etag` from the cached results will be reused, and may result in a 304 response, meaning cached results are revalidated +- If an error occurs when querying the `npmjs` registry, then soft expired results will be reused if they are present ## cachePrivatePackages @@ -338,9 +338,9 @@ For example, to override the default TTL of 60 minutes for the `docker` datasour ```json { - "cacheTtlOverride": { - "datasource-docker-tags": 120 - } + "cacheTtlOverride": { + "datasource-docker-tags": 120 + } } ``` @@ -401,11 +401,11 @@ If found, it will be imported into `config.npmrc` with `config.npmrcMerge` set t The format of the environment variables must follow: -- Datasource name (e.g. `NPM`, `PYPI`) or Platform name (only `GITHUB`) -- Underscore (`_`) -- `matchHost` -- Underscore (`_`) -- Field name (`TOKEN`, `USERNAME`, `PASSWORD`, `HTTPSPRIVATEKEY`, `HTTPSCERTIFICATE`, `HTTPSCERTIFICATEAUTHORITY`) +- Datasource name (e.g. `NPM`, `PYPI`) or Platform name (only `GITHUB`) +- Underscore (`_`) +- `matchHost` +- Underscore (`_`) +- Field name (`TOKEN`, `USERNAME`, `PASSWORD`, `HTTPSPRIVATEKEY`, `HTTPSCERTIFICATE`, `HTTPSCERTIFICATEAUTHORITY`) Hyphens (`-`) in datasource or host name must be replaced with double underscores (`__`). Periods (`.`) in host names must be replaced with a single underscore (`_`). @@ -421,13 +421,13 @@ Periods (`.`) in host names must be replaced with a single underscore (`_`). ```json { - "hostRules": [ - { - "hostType": "npm", - "matchHost": "registry.npmjs.org", - "token": "abc123" - } - ] + "hostRules": [ + { + "hostType": "npm", + "matchHost": "registry.npmjs.org", + "token": "abc123" + } + ] } ``` @@ -437,14 +437,14 @@ Periods (`.`) in host names must be replaced with a single underscore (`_`). ```json { - "hostRules": [ - { - "hostType": "gitlab-tags", - "matchHost": "code-host.company.com", - "username": "bot", - "password": "botpass123" - } - ] + "hostRules": [ + { + "hostType": "gitlab-tags", + "matchHost": "code-host.company.com", + "username": "bot", + "password": "botpass123" + } + ] } ``` @@ -456,13 +456,13 @@ You can skip the host part, and use only the datasource and credentials. ```json { - "hostRules": [ - { - "hostType": "docker", - "username": "bot", - "password": "botpass123" - } - ] + "hostRules": [ + { + "hostType": "docker", + "username": "bot", + "password": "botpass123" + } + ] } ``` @@ -472,15 +472,15 @@ You can skip the host part, and use only the datasource and credentials. ```json { - "hostRules": [ - { - "hostType": "github", - "matchHost": "some.github-enterprise.host", - "httpsPrivateKey": "private-key", - "httpsCertificate": "certificate", - "httpsCertificateAuthority": "certificate-authority" - } - ] + "hostRules": [ + { + "hostType": "github", + "matchHost": "some.github-enterprise.host", + "httpsPrivateKey": "private-key", + "httpsCertificate": "certificate", + "httpsCertificateAuthority": "certificate-authority" + } + ] } ``` @@ -490,8 +490,8 @@ Adds a custom prefix to the default Renovate sidecar Docker containers name and For example, if you set `dockerChildPrefix=myprefix_` then the final container created from the `containerbase/sidecar` is: -- called `myprefix_sidecar` instead of `renovate_sidecar` -- labeled `myprefix_child` instead of `renovate_child` +- called `myprefix_sidecar` instead of `renovate_sidecar` +- labeled `myprefix_child` instead of `renovate_child` !!! note @@ -515,7 +515,7 @@ You would put this in your configuration file: ```json { - "dockerSidecarImage": "ghcr.io/your_company/sidecar" + "dockerSidecarImage": "ghcr.io/your_company/sidecar" } ``` @@ -531,7 +531,7 @@ Set this to `1001:1002` to use UID 1001 and GID 1002. ```json title="Setting UID to 1001 and GID to 1002" { - "dockerUser": "1001:1002" + "dockerUser": "1001:1002" } ``` @@ -550,10 +550,10 @@ Use `dryRun` to preview the behavior of Renovate in logs, without making any cha You can choose from the following behaviors for the `dryRun` config option: -- `null`: Default behavior - Performs a regular Renovate run including creating/updating/deleting branches and PRs -- `"extract"`: Performs a very quick package file scan to identify the extracted dependencies -- `"lookup"`: Performs a package file scan to identify the extracted dependencies and updates available -- `"full"`: Performs a dry run by logging messages instead of creating/updating/deleting branches and PRs +- `null`: Default behavior - Performs a regular Renovate run including creating/updating/deleting branches and PRs +- `"extract"`: Performs a very quick package file scan to identify the extracted dependencies +- `"lookup"`: Performs a package file scan to identify the extracted dependencies and updates available +- `"full"`: Performs a dry run by logging messages instead of creating/updating/deleting branches and PRs Information provided mainly in debug log level. @@ -620,8 +620,8 @@ If you've set a `forkOrg` then Renovate will: If this value is configured then Renovate: -- forks the target repository into the account that owns the PAT -- keep this fork's default branch up-to-date with the target +- forks the target repository into the account that owns the PAT +- keep this fork's default branch up-to-date with the target Renovate will then create branches on the fork and opens Pull Requests on the parent repository. @@ -665,9 +665,9 @@ Currently works for Bitbucket Server and GitLab only. Possible values: -- `default`: use HTTPS URLs provided by the platform for Git -- `ssh`: use SSH URLs provided by the platform for Git -- `endpoint`: ignore URLs provided by the platform and use the configured endpoint directly +- `default`: use HTTPS URLs provided by the platform for Git +- `ssh`: use SSH URLs provided by the platform for Git +- `endpoint`: ignore URLs provided by the platform and use the configured endpoint directly ## githubTokenWarn @@ -715,16 +715,16 @@ If the file exists but cannot be parsed, then Renovate will raise a config warni The inherited config may include all valid repository config and these config options: -- `bbUseDevelopmentBranch` -- `onboarding` -- `onboardingBranch` -- `onboardingCommitMessage` -- `onboardingConfig` -- `onboardingConfigFileName` -- `onboardingNoDeps` -- `onboardingPrTitle` -- `onboardingRebaseCheckbox` -- `requireConfig` +- `bbUseDevelopmentBranch` +- `onboarding` +- `onboardingBranch` +- `onboardingCommitMessage` +- `onboardingConfig` +- `onboardingConfigFileName` +- `onboardingNoDeps` +- `onboardingPrTitle` +- `onboardingRebaseCheckbox` +- `requireConfig` !!! note @@ -772,7 +772,7 @@ Example: ```js modules.exports = { - mergeConfidenceDatasources: ['npm'], + mergeConfidenceDatasources: ['npm'], }; ``` @@ -785,8 +785,8 @@ Otherwise, it will use the default URL, which is . If you use the Mend Renovate Enterprise Edition (Renovate EE) and: -- have a static merge confidence token that you set via `MEND_RNV_MC_TOKEN` -- _or_ set `MEND_RNV_MC_TOKEN` to `auto` +- have a static merge confidence token that you set via `MEND_RNV_MC_TOKEN` +- _or_ set `MEND_RNV_MC_TOKEN` to `auto` Then you must set this variable at the _server_ and the _workers_. @@ -804,9 +804,9 @@ Example: ```js modules.exports = { - migratePresets: { - '@company': 'local>org/renovate-config', - }, + migratePresets: { + '@company': 'local>org/renovate-config', + }, }; ``` @@ -820,9 +820,9 @@ In the above example any reference to the `@company` preset will be replaced wit Only set this to `false` if all three statements are true: -- You've configured Renovate entirely on the bot side (e.g. empty `renovate.json` in repositories) -- You want to run Renovate on every repository the bot has access to -- You want to skip all onboarding PRs +- You've configured Renovate entirely on the bot side (e.g. empty `renovate.json` in repositories) +- You want to run Renovate on every repository the bot has access to +- You want to skip all onboarding PRs ## onboardingBranch @@ -850,8 +850,8 @@ The default `auto` setting is converted to `disabled` if `autodiscoverRepositori In other words, the default behavior is: -- If you run Renovate on discovered repositories then it will skip onboarding those without dependencies detected, but -- If you run Renovate on _specific_ repositories then Renovate will onboard all such repositories even if no dependencies are found +- If you run Renovate on discovered repositories then it will skip onboarding those without dependencies detected, but +- If you run Renovate on _specific_ repositories then Renovate will onboard all such repositories even if no dependencies are found ## onboardingPrTitle @@ -878,9 +878,9 @@ Otherwise, it will continue as normal. A second, advanced, use also exists when the bot global config has `extends: [":disableRenovate"]`. In that case, Renovate searches the repository config file for any of these configurations: -- `extends: [":enableRenovate"]` -- `ignorePresets: [":disableRenovate"]` -- `enabled: true` +- `extends: [":enableRenovate"]` +- `ignorePresets: [":disableRenovate"]` +- `enabled: true` If Renovate finds any of the above configurations, it continues initializing the repository. If not, then Renovate skips the repository without cloning it. @@ -922,7 +922,7 @@ If you want a UI to encrypt values you can put the public key in a HTML page sim To create the PGP key pair with GPG use the following commands: -- `gpg --full-generate-key` and follow the prompts to generate a key. Name and email are not important to Renovate, and do not configure a passphrase. Use a 4096bit key. +- `gpg --full-generate-key` and follow the prompts to generate a key. Name and email are not important to Renovate, and do not configure a passphrase. Use a 4096bit key.
key generation log @@ -1004,9 +1004,9 @@ gpg> save
-- Copy the key ID from the output (`794B820F34B34A8DF32AADB20649CEXAMPLEONLY` in the above example) or run `gpg --list-secret-keys` if you forgot to take a copy -- Run `gpg --armor --export-secret-keys YOUR_NEW_KEY_ID > renovate-private-key.asc` to generate an armored (text-based) private key file -- Run `gpg --armor --export YOUR_NEW_KEY_ID > renovate-public-key.asc` to generate an armored (text-based) public key file +- Copy the key ID from the output (`794B820F34B34A8DF32AADB20649CEXAMPLEONLY` in the above example) or run `gpg --list-secret-keys` if you forgot to take a copy +- Run `gpg --armor --export-secret-keys YOUR_NEW_KEY_ID > renovate-private-key.asc` to generate an armored (text-based) private key file +- Run `gpg --armor --export YOUR_NEW_KEY_ID > renovate-public-key.asc` to generate an armored (text-based) public key file The private key should then be added to your Renovate Bot global config (either using `privateKeyPath` or exporting it to the `RENOVATE_PRIVATE_KEY` environment variable). The public key can be used to replace the existing key in for your own use. @@ -1079,10 +1079,10 @@ For example: `s3://bucket-name/key-name`. Defines how the report is exposed: -- `` If unset, no report will be provided, though the debug logs will still have partial information of the report -- `logging` The report will be printed as part of the log messages on `INFO` level -- `file` The report will be written to a path provided by [`reportPath`](#reportpath) -- `s3` The report is pushed to an S3 bucket defined by [`reportPath`](#reportpath). This option reuses [`RENOVATE_X_S3_ENDPOINT`](./self-hosted-experimental.md#renovate_x_s3_endpoint) and [`RENOVATE_X_S3_PATH_STYLE`](./self-hosted-experimental.md#renovate_x_s3_path_style) +- `` If unset, no report will be provided, though the debug logs will still have partial information of the report +- `logging` The report will be printed as part of the log messages on `INFO` level +- `file` The report will be written to a path provided by [`reportPath`](#reportpath) +- `s3` The report is pushed to an S3 bucket defined by [`reportPath`](#reportpath). This option reuses [`RENOVATE_X_S3_ENDPOINT`](./self-hosted-experimental.md#renovate_x_s3_endpoint) and [`RENOVATE_X_S3_PATH_STYLE`](./self-hosted-experimental.md#renovate_x_s3_path_style) ## repositories @@ -1090,7 +1090,7 @@ Elements in the `repositories` array can be an object if you wish to define more ```js { - repositories: [{ repository: 'g/r1', bumpVersion: true }, 'g/r2']; + repositories: [{ repository: 'g/r1', bumpVersion: true }, 'g/r2']; } ``` @@ -1104,7 +1104,7 @@ JSON files will be stored inside the `cacheDir` beside the existing file-based p ```ts title="Set repositoryCacheType to an S3 URI to enable S3 backed repository cache" { - repositoryCacheType: 's3://bucket-name'; + repositoryCacheType: 's3://bucket-name'; } ``` @@ -1127,9 +1127,9 @@ By default, Renovate needs a Renovate config file in each repository where it ru You can choose any of these settings: -- `"required"` (default): a repository config file must be present -- `"optional"`: if a config file exists, Renovate will use it when it runs -- `"ignored"`: config files in the repo will be ignored, and have no effect +- `"required"` (default): a repository config file must be present +- `"optional"`: if a config file exists, Renovate will use it when it runs +- `"ignored"`: config files in the repo will be ignored, and have no effect This feature is closely related to the `onboarding` config option. The combinations of `requireConfig` and `onboarding` are: @@ -1147,9 +1147,9 @@ For example, to configure a `GOOGLE_TOKEN` to be accessible by all repositories: ```js module.exports = { - secrets: { - GOOGLE_TOKEN: 'abc123', - }, + secrets: { + GOOGLE_TOKEN: 'abc123', + }, }; ``` @@ -1157,14 +1157,14 @@ They can also be configured per repository, e.g. ```js module.exports = { - repositories: [ - { - repository: 'abc/def', - secrets: { - GOOGLE_TOKEN: 'abc123', - }, - }, - ], + repositories: [ + { + repository: 'abc/def', + secrets: { + GOOGLE_TOKEN: 'abc123', + }, + }, + ], }; ``` @@ -1172,12 +1172,12 @@ It could then be used in a repository config or preset like so: ```json { - "hostRules": [ - { - "matchHost": "google.com", - "token": "{{ secrets.GOOGLE_TOKEN }}" - } - ] + "hostRules": [ + { + "matchHost": "google.com", + "token": "{{ secrets.GOOGLE_TOKEN }}" + } + ] } ``` @@ -1204,8 +1204,8 @@ Otherwise, it will default to `RenovateBot/${renovateVersion} (https://github.co You may need to set a `username` if you: -- use the Bitbucket platform, or -- use a self-hosted GitHub App with CLI (required) +- use the Bitbucket platform, or +- use a self-hosted GitHub App with CLI (required) If you're using a Personal Access Token (PAT) to authenticate then you should not set a `username`. diff --git a/docs/usage/self-hosted-experimental.md b/docs/usage/self-hosted-experimental.md index 0bb89f977834ec..e6030ed205942c 100644 --- a/docs/usage/self-hosted-experimental.md +++ b/docs/usage/self-hosted-experimental.md @@ -2,10 +2,10 @@ The following environment variables are "experimental" because they: -- are not commonly needed -- are typically an effort to work around some other service's or platform's problem -- can be removed at any time -- are variables for Renovate's internal use to validate they work as intended +- are not commonly needed +- are typically an effort to work around some other service's or platform's problem +- can be removed at any time +- are variables for Renovate's internal use to validate they work as intended Experimental variables which are commonly used and for which there is no external solution in sight can be converted to an official configuration option by the Renovate bot developers. @@ -43,9 +43,9 @@ Due to the missing label information like sourceUrl, Renovate will not be able t This includes the following: -- Generating changelogs -- Applying package rules dependent on the labels -- Including the sourceUrls in PR bodies +- Generating changelogs +- Applying package rules dependent on the labels +- Including the sourceUrls in PR bodies ## `RENOVATE_X_DOCKER_HUB_TAGS_DISABLE` diff --git a/docs/usage/semantic-commits.md b/docs/usage/semantic-commits.md index 39b6c754dc77f6..f35336cfb81269 100644 --- a/docs/usage/semantic-commits.md +++ b/docs/usage/semantic-commits.md @@ -12,15 +12,15 @@ Renovate can only find Angular-style conventional commits, it does not "understa When Renovate finds Angular-style commits, Renovate creates commit messages and PR titles like this: -- chore(deps): update eslint to v7.30.0 +- chore(deps): update eslint to v7.30.0 By default, Renovate uses the `chore` prefix. If you extend from `config:recommended` then Renovate uses the `chore` prefix for nearly all updates. There are some exceptions: -- if the `depType` is a known "production dependency" type (e.g. `dependencies` or `require`), then Renovate uses the `fix` prefix -- if an update uses the `maven` datasource _and_ `matchDepTypes` is a known production type (e.g. `compile`, `provided`, `runtime`, `system`, `import` or `parent`) then Renovate uses the `fix` prefix +- if the `depType` is a known "production dependency" type (e.g. `dependencies` or `require`), then Renovate uses the `fix` prefix +- if an update uses the `maven` datasource _and_ `matchDepTypes` is a known production type (e.g. `compile`, `provided`, `runtime`, `system`, `import` or `parent`) then Renovate uses the `fix` prefix ## Manually enabling or disabling semantic commits @@ -28,13 +28,13 @@ You can override the default settings, and disable or enable Semantic Commits. ```json title="If you want Renovate to use Semantic Commits" { - "extends": [":semanticCommits"] + "extends": [":semanticCommits"] } ``` ```json title="If you want Renovate to stop using Semantic Commits" { - "extends": [":semanticCommitsDisabled"] + "extends": [":semanticCommitsDisabled"] } ``` @@ -43,25 +43,25 @@ You can override the default settings, and disable or enable Semantic Commits. You can change the Semantic Commit type that Renovate uses. For example: -- If you want Renovate to use the "chore" type for every PR, add `":semanticCommitTypeAll(chore)"` to your `extends` array: +- If you want Renovate to use the "chore" type for every PR, add `":semanticCommitTypeAll(chore)"` to your `extends` array: - ```json - { - "extends": [":semanticCommitTypeAll(chore)"] - } - ``` + ```json + { + "extends": [":semanticCommitTypeAll(chore)"] + } + ``` - PR titles and commit messages start with `chore(deps):`. + PR titles and commit messages start with `chore(deps):`. -- If you want Renovate to use the "ci" type for every PR, add `":semanticCommitTypeAll(ci)"` to your `extends` array: +- If you want Renovate to use the "ci" type for every PR, add `":semanticCommitTypeAll(ci)"` to your `extends` array: - ```json - { - "extends": [":semanticCommitTypeAll(ci)"] - } - ``` + ```json + { + "extends": [":semanticCommitTypeAll(ci)"] + } + ``` - PR titles and commit messages start with `ci(deps):`. + PR titles and commit messages start with `ci(deps):`. ## Changing the Semantic Commit scope @@ -70,7 +70,7 @@ For example, to set the scope to "package", add the preset `":semanticCommitScop ```json { - "extends": [":semanticCommitScope(package)"] + "extends": [":semanticCommitScope(package)"] } ``` @@ -78,6 +78,6 @@ To _remove_ the Semantic Commit scope, so Renovate uses `chore:` instead of `cho ```json { - "extends": [":semanticCommitScopeDisabled"] + "extends": [":semanticCommitScopeDisabled"] } ``` diff --git a/docs/usage/string-pattern-matching.md b/docs/usage/string-pattern-matching.md index c22001a58a4817..e991456c9153df 100644 --- a/docs/usage/string-pattern-matching.md +++ b/docs/usage/string-pattern-matching.md @@ -2,8 +2,8 @@ Renovate string matching syntax for some configuration options allows you, as user, to choose between: -- [`minimatch`](https://github.com/isaacs/minimatch) glob patterns, including exact strings matches -- regular expression (regex) patterns +- [`minimatch`](https://github.com/isaacs/minimatch) glob patterns, including exact strings matches +- regular expression (regex) patterns In cases where there are potentially multiple _inputs_, e.g. managers can have multiple categories, then the matcher will return `true` if _any_ of them match. @@ -14,19 +14,19 @@ It is not valid to combine `*` with any other positive or negative match. ```json title="Example of valid wildcard use" { - "allowedEnv": ["*"] + "allowedEnv": ["*"] } ``` ```json title="Example of invalid wildcard use with additional match" { - "allowedEnv": ["*", "ABC"] + "allowedEnv": ["*", "ABC"] } ``` ```json title="Example of invalid wildcard use with negation" { - "allowedEnv": ["*", "!ABC"] + "allowedEnv": ["*", "!ABC"] } ``` @@ -95,13 +95,13 @@ Renovate has a specific approach to negative matching strings. For an array of patterns to match, the following must be true: -- If any _positive_ matches are included, at least _one_ must match -- If any _negative_ matches are included, _none_ must match +- If any _positive_ matches are included, at least _one_ must match +- If any _negative_ matches are included, _none_ must match For example, the pattern `["/^abc/", "!/^abcd/", "!/abce/"]`: -- matches `"abc"` and `"abcf"` -- does _not_ match `"foo"`, `"abcd"`, `"abce"`, or `"abcdef"` +- matches `"abc"` and `"abcf"` +- does _not_ match `"foo"`, `"abcd"`, `"abce"`, or `"abcdef"` If you find yourself in a situation where you need to positive-match a string which starts with `!`, then you need to do so using a regular expression pattern. For example, `["/^!abc$/"]` will positively match against the string `"!abc"`. diff --git a/docs/usage/troubleshooting.md b/docs/usage/troubleshooting.md index f97a58d7d68ac3..fa194847808654 100644 --- a/docs/usage/troubleshooting.md +++ b/docs/usage/troubleshooting.md @@ -40,11 +40,11 @@ This can be achieved by adding `LOG_FORMAT=json` to your environment variables b There are different severity levels for the log output. From least severe to most severe: -- `DEBUG` -- `INFO` -- `WARN` -- `ERROR` -- `FATAL` +- `DEBUG` +- `INFO` +- `WARN` +- `ERROR` +- `FATAL` To check for problems, look for `WARN` or `ERROR` logs (level 40 or 50 if in JSON format). To troubleshoot further, you usually need to look at `DEBUG` logs. diff --git a/docs/usage/updating-rebasing.md b/docs/usage/updating-rebasing.md index 67d50660edc42d..87640797e116df 100644 --- a/docs/usage/updating-rebasing.md +++ b/docs/usage/updating-rebasing.md @@ -9,13 +9,13 @@ There are many situations in which Renovate must update/rebase a branch. Here is a list of the most common cases where Renovate must update/rebase the branch: -- When a pull request has conflicts due to changes on the base branch -- When you have enabled "Require branches to be up to date before merging" on GitHub -- When you have manually told Renovate to rebase when behind the base branch with `"rebaseWhen": "behind-base-branch"` -- When you have set `keepUpdatedLabel` and included the label on a PR -- When a newer version of the dependency is released -- When you request a manual rebase from the Renovate bot -- When you use `"automerge": true` and `"rebaseWhen": "auto"` on a branch / pr +- When a pull request has conflicts due to changes on the base branch +- When you have enabled "Require branches to be up to date before merging" on GitHub +- When you have manually told Renovate to rebase when behind the base branch with `"rebaseWhen": "behind-base-branch"` +- When you have set `keepUpdatedLabel` and included the label on a PR +- When a newer version of the dependency is released +- When you request a manual rebase from the Renovate bot +- When you use `"automerge": true` and `"rebaseWhen": "auto"` on a branch / pr Renovate uses its own version of "rebasing", which is _not the same_ as doing a `git rebase` with Git. Instead, Renovate reapplies all updates into a new commit based off of the head of the base branch. @@ -53,8 +53,8 @@ In that case Renovate PRs will be rebased off the repository's base branch whene If an existing PR is open to upgrade dependency "foo" to v1.1.0 and then v1.1.1 is released, then Renovate will regenerate the branch again. This way: -- Each Renovate branch will always have 1 and only 1 commit -- The newest version will be based off the latest base branch commit at the time +- Each Renovate branch will always have 1 and only 1 commit +- The newest version will be based off the latest base branch commit at the time ## Manual rebasing @@ -65,6 +65,6 @@ The label name is configurable via the `rebaseLabel` option. If you apply a rebase label then Renovate will regenerate its commit for the branch, even if the branch has been modified. The rebase label is useful in situations like: -- If a branch is behind the base branch but you don't have `rebaseWhen=behind-base-branch` enabled -- If a branch has been edited and you want to discard the edits and have Renovate create it again -- If a branch was created with an error (e.g. lockfile generation) and you want Renovate to try again +- If a branch is behind the base branch but you don't have `rebaseWhen=behind-base-branch` enabled +- If a branch has been edited and you want to discard the edits and have Renovate create it again +- If a branch was created with an error (e.g. lockfile generation) and you want Renovate to try again diff --git a/docs/usage/upgrade-best-practices.md b/docs/usage/upgrade-best-practices.md index 9f95f0714aac0a..8cdfea244b2a9c 100644 --- a/docs/usage/upgrade-best-practices.md +++ b/docs/usage/upgrade-best-practices.md @@ -9,13 +9,13 @@ We explain why you should update often, and how to nudge your team to update the In general, you should: -- Run Renovate on _every_ repository -- Use the `config:best-practices` preset instead of `config:recommended` -- Use the Dependency Dashboard issue (it's on by default) -- Update your dependencies often -- Read the changelogs for the updates -- Update to new `major` versions in good time -- Talk with your team about the update strategy +- Run Renovate on _every_ repository +- Use the `config:best-practices` preset instead of `config:recommended` +- Use the Dependency Dashboard issue (it's on by default) +- Update your dependencies often +- Read the changelogs for the updates +- Update to new `major` versions in good time +- Talk with your team about the update strategy If Renovate is too noisy for you, read the [noise reduction docs](./noise-reduction.md). @@ -28,7 +28,7 @@ You should extend from the `config:best-practices` preset: ```json { - "extends": ["config:best-practices"] + "extends": ["config:best-practices"] } ``` @@ -45,13 +45,13 @@ The [`config:best-practices` preset](./presets-config.md#configbest-practices) h ```json { - "configMigration": true, - "extends": [ - "config:recommended", - "docker:pinDigests", - "helpers:pinGitHubActionDigests", - ":pinDevDependencies" - ] + "configMigration": true, + "extends": [ + "config:recommended", + "docker:pinDigests", + "helpers:pinGitHubActionDigests", + ":pinDevDependencies" + ] } ``` @@ -93,10 +93,10 @@ Debugging faulty versions of your tools is easier, because you can use Git to ch You may think that updating takes too much time. But updating regularly actually _saves_ you time, because: -- Regular updates tend to be small -- Applying `major` updates is easier -- You'll be ready for CVE patches -- You'll look for ways to automate the updates +- Regular updates tend to be small +- Applying `major` updates is easier +- You'll be ready for CVE patches +- You'll look for ways to automate the updates #### Regular updates tend to be small @@ -110,9 +110,9 @@ Because you're reading the changelogs regularly, you'll get a feel for the direc Secondly, when you're current with upstream, `major` updates are easier. This is because you already: -- follow the latest best practices of upstream -- use the latest names for features/variables -- read the previous changelogs +- follow the latest best practices of upstream +- use the latest names for features/variables +- read the previous changelogs #### You'll be ready for CVE patches @@ -163,8 +163,8 @@ Now you're up to date, you should think how to make updating a regular habit. Let's assume your Dependency Dashboard lists more than 50 updates, and you have a few `major` version updates pending. If your project is this badly behind on updates, you have two problems: -- Updating your dependencies -- Improving your update process +- Updating your dependencies +- Improving your update process ### Focus on critical updates first @@ -216,13 +216,13 @@ Let's assume most developers _want_ a project that's up to date. So why are your developers avoiding updates? Some common reasons: -- Developers get blamed when things break in production -- There are no tests, so merging updates is scary -- The test suite is slow -- Releasing a new version of the project must be done by hand -- Updating must be done by hand -- The company doesn't allow developer time for updates -- The company has complex rules about updates +- Developers get blamed when things break in production +- There are no tests, so merging updates is scary +- The test suite is slow +- Releasing a new version of the project must be done by hand +- Updating must be done by hand +- The company doesn't allow developer time for updates +- The company has complex rules about updates If updating is painful, or takes a lot of time, developers tend to avoid it. Make it easy and fast to update dependencies. @@ -236,32 +236,32 @@ Then fix each problem as best as you can. Respect your developer's time and brains: -- Run Renovate on _all_ projects -- Use Renovate to propose updates -- Building the project _must_ be as fast as possible -- Have automated tests for the critical path of your project -- Run the automated tests on _every_ pull request -- If you're on GitHub: use [GitHub's Merge Queue](./key-concepts/automerge.md#github-merge-queue) to speed up merges -- Follow SemVer versioning -- Use the [`semantic-release` bot](https://github.com/semantic-release/semantic-release) to automate the release process -- Refactor existing code to make future changes easier +- Run Renovate on _all_ projects +- Use Renovate to propose updates +- Building the project _must_ be as fast as possible +- Have automated tests for the critical path of your project +- Run the automated tests on _every_ pull request +- If you're on GitHub: use [GitHub's Merge Queue](./key-concepts/automerge.md#github-merge-queue) to speed up merges +- Follow SemVer versioning +- Use the [`semantic-release` bot](https://github.com/semantic-release/semantic-release) to automate the release process +- Refactor existing code to make future changes easier #### Ground rules As a starting point: -- Avoid long lived branches that diverge from `main` over time -- Dig beyond "developer error" when things go wrong, again: focus on the process -- Ensure company policy allows frequent updates +- Avoid long lived branches that diverge from `main` over time +- Dig beyond "developer error" when things go wrong, again: focus on the process +- Ensure company policy allows frequent updates ## How we use Renovate -- We run Renovate on all repositories -- Most of our repositories have automated tests for the critical path of the application -- We automerge some dependencies, but request `major` updates from the Dependency Dashboard -- When a developer merges a breaking change, we revert to a known-good version, and try again later -- We automated the release with the [`semantic-release`](https://github.com/semantic-release/semantic-release) bot -- We spend time to make our build and automated tests as fast as possible +- We run Renovate on all repositories +- Most of our repositories have automated tests for the critical path of the application +- We automerge some dependencies, but request `major` updates from the Dependency Dashboard +- When a developer merges a breaking change, we revert to a known-good version, and try again later +- We automated the release with the [`semantic-release`](https://github.com/semantic-release/semantic-release) bot +- We spend time to make our build and automated tests as fast as possible ## How others use Renovate @@ -273,8 +273,8 @@ There's a lot of good information out there, so we can only highlight a few reso Martin Fowler has two great resources: -- The free page [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) to help you decide what Git branch pattern to use -- The book [Refactoring, Improving the Design of Existing Code](https://martinfowler.com/books/refactoring.html) to help your developers gradually refactor to clean, modular and easy to read code +- The free page [Patterns for Managing Source Code Branches](https://martinfowler.com/articles/branching-patterns.html) to help you decide what Git branch pattern to use +- The book [Refactoring, Improving the Design of Existing Code](https://martinfowler.com/books/refactoring.html) to help your developers gradually refactor to clean, modular and easy to read code The `git bisect` command can help you find out which commit introduced a bug, or other behavior change. Read the [ProGit 2 book, section on binary search](https://git-scm.com/book/en/v2/Git-Tools-Debugging-with-Git#_binary_search) to learn more. diff --git a/docs/usage/user-stories/maintaining-aur-packages-with-renovate.md b/docs/usage/user-stories/maintaining-aur-packages-with-renovate.md index abdc119a870992..8e3b78b32af4c5 100644 --- a/docs/usage/user-stories/maintaining-aur-packages-with-renovate.md +++ b/docs/usage/user-stories/maintaining-aur-packages-with-renovate.md @@ -43,24 +43,24 @@ I can create a `renovate.json` configuration with the following custom manager c ```json title="renovate.json" { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["(^|/)PKGBUILD$"], - "matchStrings": [ - "pkgver=(?.*) # renovate: datasource=(?.*) depName=(?.*)" - ], - "extractVersionTemplate": "^v?(?.*)$" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["(^|/)PKGBUILD$"], + "matchStrings": [ + "pkgver=(?.*) # renovate: datasource=(?.*) depName=(?.*)" + ], + "extractVersionTemplate": "^v?(?.*)$" + } + ] } ``` Breaking that down: -- The `fileMatch` setting tells Renovate to look for any `PKGBUILD` files in a repository -- The `matchStrings` is the regex format to extract the version, datasource, and dependency name from the `PKGBUILD` -- The `extractVersionTemplate` is to handle a “v” in front of any version number that is sometimes added to Git tags +- The `fileMatch` setting tells Renovate to look for any `PKGBUILD` files in a repository +- The `matchStrings` is the regex format to extract the version, datasource, and dependency name from the `PKGBUILD` +- The `extractVersionTemplate` is to handle a “v” in front of any version number that is sometimes added to Git tags And here’s an extract from the PKGBUILD for the [bicep-bin](https://aur.archlinux.org/packages/bicep-bin) AUR package that I maintain: @@ -86,26 +86,26 @@ First, I only want to run this workflow on pull requests targeting the `main` br ```yaml on: - pull_request: - types: - - opened - - synchronize - branches: - - main + pull_request: + types: + - opened + - synchronize + branches: + - main ``` Next, I’m going to need to check out the entire history of the repository, so I can compare the files changed in the latest commit with the Git history. ```yaml jobs: - updpkgsums: - runs-on: ubuntu-latest - steps: - - name: Checkout - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0 - with: - fetch-depth: 0 - ref: ${{ github.ref }} + updpkgsums: + runs-on: ubuntu-latest + steps: + - name: Checkout + uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0 + with: + fetch-depth: 0 + ref: ${{ github.ref }} ``` Getting the package that changed in a pull request requires a little bit of shell magic. @@ -113,10 +113,10 @@ Getting the package that changed in a pull request requires a little bit of shel ```yaml - name: Find updated package run: | - #!/usr/bin/env bash - set -euxo pipefail + #!/usr/bin/env bash + set -euxo pipefail - echo "pkgbuild=$(git diff --name-only origin/main origin/${GITHUB_HEAD_REF} "*PKGBUILD" | head -1 | xargs dirname)" >> $GITHUB_ENV + echo "pkgbuild=$(git diff --name-only origin/main origin/${GITHUB_HEAD_REF} "*PKGBUILD" | head -1 | xargs dirname)" >> $GITHUB_ENV ``` Now I’ve found the package that changed in the Renovate pull request, I can update the files. @@ -130,8 +130,8 @@ You can [check out the full code on GitHub](https://github.com/JamieMagee/aur-pa if: ${{ env.pkgbuild != '' }} uses: ./.github/actions/aur with: - action: 'updpkgsums' - pkgname: ${{ env.pkgbuild }} + action: 'updpkgsums' + pkgname: ${{ env.pkgbuild }} ``` Finally, once the `PKGBUILD` and `.SRCINFO` are updated I need to commit that change back to the pull request. @@ -141,7 +141,7 @@ Finally, once the `PKGBUILD` and `.SRCINFO` are updated I need to commit that ch if: ${{ env.pkgbuild != '' }} uses: stefanzweifel/git-auto-commit-action@3ea6ae190baf489ba007f7c92608f33ce20ef04a # v4.16.0 with: - file_pattern: '*/PKGBUILD */.SRCINFO' + file_pattern: '*/PKGBUILD */.SRCINFO' ``` Check out [this pull request for `bicep-bin`](https://github.com/JamieMagee/aur-packages/pull/62) where Renovate opened a pull request, and my GitHub Actions workflow updated the `b2sums` in the `PKGBUILD` and updated the `.SRCINFO`. @@ -163,11 +163,11 @@ Then all I need to do is to use the `github-actions-deploy-aur` GitHub Action: uses: KSXGitHub/github-actions-deploy-aur@065b6056b25bdd43830d5a3f01899d0ff7169819 # v2.6.0 if: ${{ env.pkgbuild != '' }} with: - pkgname: ${{ env.pkgbuild }} - pkgbuild: ${{ env.pkgbuild }}/PKGBUILD - commit_username: ${{ secrets.AUR_USERNAME }} - commit_email: ${{ secrets.AUR_EMAIL }} - ssh_private_key: ${{ secrets.AUR_SSH_PRIVATE_KEY }} + pkgname: ${{ env.pkgbuild }} + pkgbuild: ${{ env.pkgbuild }}/PKGBUILD + commit_username: ${{ secrets.AUR_USERNAME }} + commit_email: ${{ secrets.AUR_EMAIL }} + ssh_private_key: ${{ secrets.AUR_SSH_PRIVATE_KEY }} ``` ### All together now diff --git a/docs/usage/user-stories/swissquote.md b/docs/usage/user-stories/swissquote.md index 2b64c320013662..dfe71bd575e1d7 100644 --- a/docs/usage/user-stories/swissquote.md +++ b/docs/usage/user-stories/swissquote.md @@ -79,17 +79,17 @@ There is a chance you need to know how each library works, and your present and Which of these two would you prefer to start with: -- A project that is fairly up-to-date where you can bump the dependency, run the deployment pipeline and go back to your day -- A project that wasn’t touched in years; every dependency is outdated and Continuous Integration is red on all branches, if running at all +- A project that is fairly up-to-date where you can bump the dependency, run the deployment pipeline and go back to your day +- A project that wasn’t touched in years; every dependency is outdated and Continuous Integration is red on all branches, if running at all Am I exaggerating with my examples? Maybe a little, but I have seen cases very close to those. Let me ask you some questions about your projects: -- How many times did you create a project and never upgrade its dependencies? -- How many times did you have to get back to an old project, and had to use a new library but couldn’t because there is another library at an old version that isn’t compatible? -- How fast can you upgrade a single dependency on all your applications? +- How many times did you create a project and never upgrade its dependencies? +- How many times did you have to get back to an old project, and had to use a new library but couldn’t because there is another library at an old version that isn’t compatible? +- How fast can you upgrade a single dependency on all your applications? As time goes forward, projects come and go, you will most likely have decade-old, and recent ones. Some might be using the latest version of Java with the latest Spring, some with slightly outdated libraries and others might be using Stripes and libraries that have had no release in 7 years. @@ -150,18 +150,18 @@ We received 700 Pull Requests in the first month, it was a never ending Pull Req The awesome thing with Renovate is that it’s very configurable, and this configuration can be shared. Very early on we created a shared configuration for our team with some custom policies, here are a few things we decided to do: -- Group PRs for `minor` and `patch` dependencies -- Internal dependencies could create a PR anytime of the day -- Third party dependencies could create PRs only during the weekend +- Group PRs for `minor` and `patch` dependencies +- Internal dependencies could create a PR anytime of the day +- Third party dependencies could create PRs only during the weekend This helped a lot to reduce the noise in PRs, the second month we got 400 Pull Requests, and on the third month only 200. ## What we learned from automating dependencies updates -- You need to be confident that your code coverage will warn you in case of updates. At the beginning we missed quite a few breaking updates because the build was green but the application broke as soon as it was deployed -- Once you’re confident enough, auto-merge is a must have. In our team we enabled Renovate on about 100 of our repositories and generally spend 1–2 hours per week to stay up-to-date -- “On the bleeding edge it’s not the edge that’s bleeding; it’s you”. When updating to a new major version as soon as it’s released you might encounter some surprises. It happened to us a few times that a patch version breaks the library. Usually a fix came out the next day, but we still spent a few hours debugging why the update broke our applications. We’ve opened quite a few Issues and sent some PRs to fix issues like this -- Updating dependencies is one thing, but when should you release them? As our team mostly provides libraries, we don’t want to release them on every dependency upgrade (as this would create PRs downstream and create noise for them). We’ve decided to release right after critical upgrades or contributions and a dashboard informs us when a repository hasn’t been released for 30 days +- You need to be confident that your code coverage will warn you in case of updates. At the beginning we missed quite a few breaking updates because the build was green but the application broke as soon as it was deployed +- Once you’re confident enough, auto-merge is a must have. In our team we enabled Renovate on about 100 of our repositories and generally spend 1–2 hours per week to stay up-to-date +- “On the bleeding edge it’s not the edge that’s bleeding; it’s you”. When updating to a new major version as soon as it’s released you might encounter some surprises. It happened to us a few times that a patch version breaks the library. Usually a fix came out the next day, but we still spent a few hours debugging why the update broke our applications. We’ve opened quite a few Issues and sent some PRs to fix issues like this +- Updating dependencies is one thing, but when should you release them? As our team mostly provides libraries, we don’t want to release them on every dependency upgrade (as this would create PRs downstream and create noise for them). We’ve decided to release right after critical upgrades or contributions and a dashboard informs us when a repository hasn’t been released for 30 days ### A word on Renovate @@ -172,12 +172,12 @@ But what confirmed our choice is the insane crazy amount of features and [config Some features and options we enjoy: -- [Shared configurations (presets)](../key-concepts/presets.md), we have a Swissquote default configuration we set for all repositories, each team can extend it with their own practices -- [Integration with GitHub’s Dependabot alerts](../configuration-options.md#vulnerabilityalerts) to raise the priority and send security remediation PRs as soon as possible -- Each rule can be customized either globally [or specified per package](../configuration-options.md#packagerules) -- Works with your [private package registry](../getting-started/private-packages.md) -- Supports more than 70 [languages and package managers](../modules/manager/index.md#supported-managers): Maven, Docker, npm, Docker Compose, Python -- If you are using dependencies in a custom way, [there is a `customManagers` option](../configuration-options.md#custommanagers) that allows you to transform patterns into dependencies +- [Shared configurations (presets)](../key-concepts/presets.md), we have a Swissquote default configuration we set for all repositories, each team can extend it with their own practices +- [Integration with GitHub’s Dependabot alerts](../configuration-options.md#vulnerabilityalerts) to raise the priority and send security remediation PRs as soon as possible +- Each rule can be customized either globally [or specified per package](../configuration-options.md#packagerules) +- Works with your [private package registry](../getting-started/private-packages.md) +- Supports more than 70 [languages and package managers](../modules/manager/index.md#supported-managers): Maven, Docker, npm, Docker Compose, Python +- If you are using dependencies in a custom way, [there is a `customManagers` option](../configuration-options.md#custommanagers) that allows you to transform patterns into dependencies There is an [on-premise option](https://www.mend.io/free-developer-tools/renovate/on-premises/), but you can also use [the Mend Renovate App](https://github.com/marketplace/renovate). On our side, we’re not using the on-premise but rather a custom scheduler using the open source Docker image. @@ -206,10 +206,10 @@ We don’t force any team to use Renovate, each team can decide to opt-in and do Some statistics: -- 857 repositories enabled out of about 2000 active repositories -- 11000 PRs were merged since we installed Renovate -- 239 PRs were merged last month -- 2 SSDs died on our Renovate machine with the number of projects to clone again and again +- 857 repositories enabled out of about 2000 active repositories +- 11000 PRs were merged since we installed Renovate +- 239 PRs were merged last month +- 2 SSDs died on our Renovate machine with the number of projects to clone again and again ### How does the scheduler work? @@ -264,10 +264,10 @@ We were so quick to do it, in fact, that we had to do that three times with the Keep in mind that keeping your dependencies up-to-date is not just about the tooling, it’s also about having a process: -- When will you merge this PR? -- How will you handle the PR that doesn’t build? -- The new major version of an external library that’s not yet compatible with the rest of your libraries? -- When will you release this constant flow of library updates? -- Do you want PRs during the day? During the night? Or on weekends only? +- When will you merge this PR? +- How will you handle the PR that doesn’t build? +- The new major version of an external library that’s not yet compatible with the rest of your libraries? +- When will you release this constant flow of library updates? +- Do you want PRs during the day? During the night? Or on weekends only? We know the answers for our situation, we’ll let you decide what the answers are for you. :smile: diff --git a/lib/data/readme.md b/lib/data/readme.md index a015ba386092fa..027691205b732e 100644 --- a/lib/data/readme.md +++ b/lib/data/readme.md @@ -34,25 +34,25 @@ The `replacements.json` file has all the replacement presets. When a package gets renamed, you need to tell Renovate: -- the datasource of the package -> `matchDatasources` -- the old package name -> `matchPackageNames` -- the new package name -> `replacementName` -- the last version available for the old package name -> `matchCurrentVersion` -- the first version available for the new package name -> `replacementVersion` +- the datasource of the package -> `matchDatasources` +- the old package name -> `matchPackageNames` +- the new package name -> `replacementName` +- the last version available for the old package name -> `matchCurrentVersion` +- the first version available for the new package name -> `replacementVersion` Example: ```json { - "matchCurrentVersion": ">=3.10.3", - "matchDatasources": ["npm"], - "matchPackageNames": [ - "apollo-server", - "apollo-server-core", - "apollo-server-express" - ], - "replacementName": "@apollo/server", - "replacementVersion": "4.0.0" + "matchCurrentVersion": ">=3.10.3", + "matchDatasources": ["npm"], + "matchPackageNames": [ + "apollo-server", + "apollo-server-core", + "apollo-server-express" + ], + "replacementName": "@apollo/server", + "replacementVersion": "4.0.0" } ``` @@ -67,15 +67,15 @@ If this does not happen, for whatever reason, Renovate can not show the changelo You can use these config options to let Renovate find the correct changelog: -- [`changelogUrl`](https://docs.renovatebot.com/configuration-options/#changelogurl) +- [`changelogUrl`](https://docs.renovatebot.com/configuration-options/#changelogurl) Read the [Renovate docs, key concepts page for changelogs](https://docs.renovatebot.com/key-concepts/changelogs/) to learn more about how Renovate fetches and displays changelogs. To locate the changelogs, Renovate requires: -- the name of the package (`packageName`) -- the datasource of the package -- the URL to the changelog file (`changelogUrl`) +- the name of the package (`packageName`) +- the datasource of the package +- the URL to the changelog file (`changelogUrl`) Example: For the `zone.js` package, the changelog URL is . @@ -99,9 +99,9 @@ If Renovate does not find the right source URls automatically: use the [`sourceU To locate the source repository, Renovate requires: -- the name of the package (`packageName`) -- the datasource of the package -- the URL to the source repository (`sourceUrl`) +- the name of the package (`packageName`) +- the datasource of the package +- the URL to the source repository (`sourceUrl`) Example: The source URL for the repository `cypress-io/cypress` is . diff --git a/lib/modules/datasource/aws-machine-image/readme.md b/lib/modules/datasource/aws-machine-image/readme.md index bbda36b359eec0..af9e872a3af2e3 100644 --- a/lib/modules/datasource/aws-machine-image/readme.md +++ b/lib/modules/datasource/aws-machine-image/readme.md @@ -8,9 +8,9 @@ This datasource returns the latest [Amazon Machine Image](https://docs.aws.amazo Because the datasource uses the AWS-SDK for JavaScript, you can configure it like other AWS Tools. You can use common AWS configuration options, for example (partial list): -- Setting the region via `AWS_REGION` (environment variable) or your `~/.aws/config` file -- Provide credentials via `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` (environment variable) or your `~/.aws/credentials` file -- Select the profile to use via `AWS_PROFILE` environment variable +- Setting the region via `AWS_REGION` (environment variable) or your `~/.aws/config` file +- Provide credentials via `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` (environment variable) or your `~/.aws/credentials` file +- Select the profile to use via `AWS_PROFILE` environment variable Read the [Developer guide](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/configuring-the-jssdk.html) for more information on configuration options. @@ -18,10 +18,10 @@ The least IAM privileges required for this datasource are: ```json { - "Sid": "AllowEc2ImageLookup", - "Effect": "Allow", - "Action": ["ec2:DescribeImages"], - "Resource": "*" + "Sid": "AllowEc2ImageLookup", + "Effect": "Allow", + "Action": ["ec2:DescribeImages"], + "Resource": "*" } ``` @@ -59,17 +59,17 @@ Here's an example of using the custom manager: ```javascript module.exports = { - customManagers: [ - { - customType: 'regex', - fileMatch: ['.*'], - matchStrings: [ - '.*amiFilter=(?.*?)\n(.*currentImageName=(?.*?)\n)?(.*\n)?.*?(?[a-zA-Z0-9-_:]*)[ ]*?[:|=][ ]*?["|\']?(?ami-[a-z0-9]{17})["|\']?.*', - ], - datasourceTemplate: 'aws-machine-image', - versioningTemplate: 'aws-machine-image', - }, - ], + customManagers: [ + { + customType: 'regex', + fileMatch: ['.*'], + matchStrings: [ + '.*amiFilter=(?.*?)\n(.*currentImageName=(?.*?)\n)?(.*\n)?.*?(?[a-zA-Z0-9-_:]*)[ ]*?[:|=][ ]*?["|\']?(?ami-[a-z0-9]{17})["|\']?.*', + ], + datasourceTemplate: 'aws-machine-image', + versioningTemplate: 'aws-machine-image', + }, + ], }; ``` @@ -77,19 +77,19 @@ Or as JSON: ```yaml { - 'customManagers': - [ - { - 'customType': 'regex', - 'fileMatch': ['.*'], - 'matchStrings': - [ - ".*amiFilter=(?.*?)\n(.*currentImageName=(?.*?)\n)?(.*\n)?.*?(?[a-zA-Z0-9-_:]*)[ ]*?[:|=][ ]*?[\"|']?(?ami-[a-z0-9]{17})[\"|']?.*", - ], - 'datasourceTemplate': 'aws-machine-image', - 'versioningTemplate': 'aws-machine-image', - }, - ], + 'customManagers': + [ + { + 'customType': 'regex', + 'fileMatch': ['.*'], + 'matchStrings': + [ + ".*amiFilter=(?.*?)\n(.*currentImageName=(?.*?)\n)?(.*\n)?.*?(?[a-zA-Z0-9-_:]*)[ ]*?[:|=][ ]*?[\"|']?(?ami-[a-z0-9]{17})[\"|']?.*", + ], + 'datasourceTemplate': 'aws-machine-image', + 'versioningTemplate': 'aws-machine-image', + }, + ], } ``` @@ -113,10 +113,10 @@ ami = "ami-0083e9407e275acf2" ```typescript const myConfigObject = { - // With AMI name mentioned in the comments - // amiFilter=[{"Name":"owner-id","Values":["602401143452"]},{"Name":"name","Values":["amazon-eks-node-1.21-*"]}] - // currentImageName=unknown - my_ami1: 'ami-02ce3d9008cab69cb', + // With AMI name mentioned in the comments + // amiFilter=[{"Name":"owner-id","Values":["602401143452"]},{"Name":"name","Values":["amazon-eks-node-1.21-*"]}] + // currentImageName=unknown + my_ami1: 'ami-02ce3d9008cab69cb', }; /** diff --git a/lib/modules/datasource/aws-rds/readme.md b/lib/modules/datasource/aws-rds/readme.md index be47f3644d2c1b..93c1fbecd5161f 100644 --- a/lib/modules/datasource/aws-rds/readme.md +++ b/lib/modules/datasource/aws-rds/readme.md @@ -8,9 +8,9 @@ In addition, AWS may pull existing versions if serious problems arise during the Since the datasource uses the AWS SDK for JavaScript, you can configure it like other AWS Tools. You can use common AWS configuration options, for example: -- Set the region via the `AWS_REGION` environment variable or your `~/.aws/config` file -- Provide credentials via the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables or your `~/.aws/credentials` file -- Select the profile to use via `AWS_PROFILE` environment variable +- Set the region via the `AWS_REGION` environment variable or your `~/.aws/config` file +- Provide credentials via the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` environment variables or your `~/.aws/credentials` file +- Select the profile to use via `AWS_PROFILE` environment variable Read the [AWS Developer Guide - Configuring the SDK for JavaScript](https://docs.aws.amazon.com/sdk-for-javascript/v3/developer-guide/configuring-the-jssdk.html) for more information on these configuration options. @@ -18,10 +18,10 @@ The minimal IAM privileges required for this datasource are: ```json { - "Sid": "AllowDBEngineVersionLookup", - "Effect": "Allow", - "Action": ["rds:DescribeDBEngineVersions"], - "Resource": "*" + "Sid": "AllowDBEngineVersionLookup", + "Effect": "Allow", + "Action": ["rds:DescribeDBEngineVersions"], + "Resource": "*" } ``` @@ -57,16 +57,16 @@ Here's an example of using the custom manager to configure this datasource: ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["\\.yaml$"], - "matchStrings": [ - ".*amiFilter=(?.+?)[ ]*\n[ ]*(?[a-zA-Z0-9-_:]*)[ ]*?:[ ]*?[\"|']?(?[.\\d]+)[\"|']?.*" - ], - "datasourceTemplate": "aws-rds" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["\\.yaml$"], + "matchStrings": [ + ".*amiFilter=(?.+?)[ ]*\n[ ]*(?[a-zA-Z0-9-_:]*)[ ]*?:[ ]*?[\"|']?(?[.\\d]+)[\"|']?.*" + ], + "datasourceTemplate": "aws-rds" + } + ] } ``` @@ -74,6 +74,6 @@ The configuration above matches every YAML file, and recognizes these lines: ```yaml spec: - # amiFilter=[{"Name":"engine","Values":["mysql"]},{"Name":"engine-version","Values":["5.7"]}] - engineVersion: 5.7.34 + # amiFilter=[{"Name":"engine","Values":["mysql"]},{"Name":"engine-version","Values":["5.7"]}] + engineVersion: 5.7.34 ``` diff --git a/lib/modules/datasource/bitrise/readme.md b/lib/modules/datasource/bitrise/readme.md index e80b3fabaaa398..2ca71a9ae051a4 100644 --- a/lib/modules/datasource/bitrise/readme.md +++ b/lib/modules/datasource/bitrise/readme.md @@ -7,20 +7,20 @@ Renovate uses this datasource to fetch Bitrise steps from GitHub repositories. For example, in the YAML snippet below: -- `packageName` is `script` -- `registryUrl` is `https://github.com/bitrise-io/bitrise-steplib.git` +- `packageName` is `script` +- `registryUrl` is `https://github.com/bitrise-io/bitrise-steplib.git` ```yaml format_version: 11 default_step_lib_source: https://github.com/bitrise-io/bitrise-steplib.git project_type: android app: - envs: - - MY_NAME: My Name + envs: + - MY_NAME: My Name workflows: - test: - steps: - - script@1.1.5: - inputs: - - content: echo "Hello ${MY_NAME}!" + test: + steps: + - script@1.1.5: + inputs: + - content: echo "Hello ${MY_NAME}!" ``` diff --git a/lib/modules/datasource/custom/readme.md b/lib/modules/datasource/custom/readme.md index 0764f76feb9796..bbf44ae6f98130 100644 --- a/lib/modules/datasource/custom/readme.md +++ b/lib/modules/datasource/custom/readme.md @@ -15,29 +15,29 @@ Options: Available template variables: -- `packageName` -- `currentValue` +- `packageName` +- `currentValue` ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["k3s.version"], - "matchStrings": ["(?\\S+)"], - "depNameTemplate": "k3s", - "versioningTemplate": "semver-coerced", - "datasourceTemplate": "custom.k3s" - } - ], - "customDatasources": { - "k3s": { - "defaultRegistryUrlTemplate": "https://update.k3s.io/v1-release/channels", - "transformTemplates": [ - "{\"releases\":[{\"version\": $$.(data[id = 'stable'].latest),\"sourceUrl\":\"https://github.com/k3s-io/k3s\",\"changelogUrl\":$join([\"https://github.com/k3s-io/k3s/releases/tag/\",data[id = 'stable'].latest])}],\"sourceUrl\": \"https://github.com/k3s-io/k3s\",\"homepage\": \"https://k3s.io/\"}" - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["k3s.version"], + "matchStrings": ["(?\\S+)"], + "depNameTemplate": "k3s", + "versioningTemplate": "semver-coerced", + "datasourceTemplate": "custom.k3s" + } + ], + "customDatasources": { + "k3s": { + "defaultRegistryUrlTemplate": "https://update.k3s.io/v1-release/channels", + "transformTemplates": [ + "{\"releases\":[{\"version\": $$.(data[id = 'stable'].latest),\"sourceUrl\":\"https://github.com/k3s-io/k3s\",\"changelogUrl\":$join([\"https://github.com/k3s-io/k3s/releases/tag/\",data[id = 'stable'].latest])}],\"sourceUrl\": \"https://github.com/k3s-io/k3s\",\"homepage\": \"https://k3s.io/\"}" + ] + } } - } } ``` @@ -47,14 +47,14 @@ Minimal-supported object: ```json { - "releases": [ - { - "version": "v1.1.0" - }, - { - "version": "v1.2.0" - } - ] + "releases": [ + { + "version": "v1.1.0" + }, + { + "version": "v1.2.0" + } + ] } ``` @@ -62,22 +62,22 @@ All available options: ```json { - "releases": [ - { - "version": "v1.0.0", - "isDeprecated": true, - "releaseTimestamp": "2022-12-24T18:21Z", - "changelogUrl": "https://github.com/demo-org/demo/blob/main/CHANGELOG.md#v0710", - "sourceUrl": "https://github.com/demo-org/demo", - "sourceDirectory": "monorepo/folder", - "digest": "c667f758f9e46e1d8111698e8d3a181c0b10f430", - "isStable": true - } - ], - "sourceUrl": "https://github.com/demo-org/demo", - "sourceDirectory": "monorepo/folder", - "changelogUrl": "https://github.com/demo-org/demo/blob/main/CHANGELOG.md", - "homepage": "https://demo.org" + "releases": [ + { + "version": "v1.0.0", + "isDeprecated": true, + "releaseTimestamp": "2022-12-24T18:21Z", + "changelogUrl": "https://github.com/demo-org/demo/blob/main/CHANGELOG.md#v0710", + "sourceUrl": "https://github.com/demo-org/demo", + "sourceDirectory": "monorepo/folder", + "digest": "c667f758f9e46e1d8111698e8d3a181c0b10f430", + "isStable": true + } + ], + "sourceUrl": "https://github.com/demo-org/demo", + "sourceDirectory": "monorepo/folder", + "changelogUrl": "https://github.com/demo-org/demo/blob/main/CHANGELOG.md", + "homepage": "https://demo.org" } ``` @@ -92,12 +92,12 @@ If you use the Mend Renovate app, use the [`logLevelRemap` config option](../../ ```json title="Getting trace logs from the Mend Renovate app" { - "logLevelRemap": [ - { - "matchMessage": "/^Custom manager fetcher/", - "newLogLevel": "info" - } - ] + "logLevelRemap": [ + { + "matchMessage": "/^Custom manager fetcher/", + "newLogLevel": "info" + } + ] } ``` @@ -132,17 +132,17 @@ When Renovate receives this response with the `plain` format, it will convert it ```json { - "releases": [ - { - "version": "1.0.0" - }, - { - "version": "2.0.0" - }, - { - "version": "3.0.0" - } - ] + "releases": [ + { + "version": "1.0.0" + }, + { + "version": "2.0.0" + }, + { + "version": "3.0.0" + } + ] } ``` @@ -156,26 +156,26 @@ Suppose the body of the HTTP response is as follows: ```yaml releases: - - version: 1.0.0 - - version: 2.0.0 - - version: 3.0.0 + - version: 1.0.0 + - version: 2.0.0 + - version: 3.0.0 ``` When Renovate receives this response with the `yaml` format, it will convert it into the following: ```json { - "releases": [ - { - "version": "1.0.0" - }, - { - "version": "2.0.0" - }, - { - "version": "3.0.0" - } - ] + "releases": [ + { + "version": "1.0.0" + }, + { + "version": "2.0.0" + }, + { + "version": "3.0.0" + } + ] } ``` @@ -190,10 +190,10 @@ For the following HTML document: ```html - - package-1.0.tar.gz - package-2.0.tar.gz - + + package-1.0.tar.gz + package-2.0.tar.gz + ``` @@ -201,14 +201,14 @@ The following JSON will be generated: ```json { - "releases": [ - { - "version": "package-1.0.tar.gz" - }, - { - "version": "package-1.0.tar.gz" - } - ] + "releases": [ + { + "version": "package-1.0.tar.gz" + }, + { + "version": "package-1.0.tar.gz" + } + ] } ``` @@ -224,14 +224,14 @@ You can use this configuration to request the newest version available to [K3s]( ```json { - "customDatasources": { - "k3s": { - "defaultRegistryUrlTemplate": "https://update.k3s.io/v1-release/channels", - "transformTemplates": [ - "{\"releases\":[{\"version\": $$.(data[id = 'stable'].latest),\"sourceUrl\":\"https://github.com/k3s-io/k3s\",\"changelogUrl\":$join([\"https://github.com/k3s-io/k3s/releases/tag/\",data[id = 'stable'].latest])}],\"sourceUrl\": \"https://github.com/k3s-io/k3s\",\"homepage\": \"https://k3s.io/\"}" - ] + "customDatasources": { + "k3s": { + "defaultRegistryUrlTemplate": "https://update.k3s.io/v1-release/channels", + "transformTemplates": [ + "{\"releases\":[{\"version\": $$.(data[id = 'stable'].latest),\"sourceUrl\":\"https://github.com/k3s-io/k3s\",\"changelogUrl\":$join([\"https://github.com/k3s-io/k3s/releases/tag/\",data[id = 'stable'].latest])}],\"sourceUrl\": \"https://github.com/k3s-io/k3s\",\"homepage\": \"https://k3s.io/\"}" + ] + } } - } } ``` @@ -241,25 +241,25 @@ You can use this configuration to request the newest versions of the Hashicorp p ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["\\.yml$"], - "datasourceTemplate": "custom.hashicorp", - "matchStrings": [ - "#\\s*renovate:\\s*(datasource=(?.*?) )?depName=(?.*?)( versioning=(?.*?))?\\s*\\w*:\\s*(?.*)\\s" - ], - "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" - } - ], - "customDatasources": { - "hashicorp": { - "defaultRegistryUrlTemplate": "https://api.releases.hashicorp.com/v1/releases/{{packageName}}?license_class=oss", - "transformTemplates": [ - "{ \"releases\": $map($, function($v) { { \"version\": $v.version, \"releaseTimestamp\": $v.timestamp_created, \"changelogUrl\": $v.url_changelog, \"sourceUrl\": $v.url_source_repository } }), \"homepage\": $[0].url_project_website, \"sourceUrl\": $[0].url_source_repository }" - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["\\.yml$"], + "datasourceTemplate": "custom.hashicorp", + "matchStrings": [ + "#\\s*renovate:\\s*(datasource=(?.*?) )?depName=(?.*?)( versioning=(?.*?))?\\s*\\w*:\\s*(?.*)\\s" + ], + "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" + } + ], + "customDatasources": { + "hashicorp": { + "defaultRegistryUrlTemplate": "https://api.releases.hashicorp.com/v1/releases/{{packageName}}?license_class=oss", + "transformTemplates": [ + "{ \"releases\": $map($, function($v) { { \"version\": $v.version, \"releaseTimestamp\": $v.timestamp_created, \"changelogUrl\": $v.url_changelog, \"sourceUrl\": $v.url_source_repository } }), \"homepage\": $[0].url_project_website, \"sourceUrl\": $[0].url_source_repository }" + ] + } } - } } ``` @@ -276,26 +276,26 @@ You can use the following configuration to upgrade the Grafana Dashboards versio ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["\\.yml$"], - "matchStrings": [ - "#\\s+renovate:\\s+depName=\"(?.*)\"\\n\\s+gnetId:\\s+(?.*?)\\n\\s+revision:\\s+(?.*)" - ], - "versioningTemplate": "regex:^(?\\d+)$", - "datasourceTemplate": "custom.grafana-dashboards" - } - ], - "customDatasources": { - "grafana-dashboards": { - "defaultRegistryUrlTemplate": "https://grafana.com/api/dashboards/{{packageName}}", - "format": "json", - "transformTemplates": [ - "{\"releases\":[{\"version\": $string(revision)}]}" - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["\\.yml$"], + "matchStrings": [ + "#\\s+renovate:\\s+depName=\"(?.*)\"\\n\\s+gnetId:\\s+(?.*?)\\n\\s+revision:\\s+(?.*)" + ], + "versioningTemplate": "regex:^(?\\d+)$", + "datasourceTemplate": "custom.grafana-dashboards" + } + ], + "customDatasources": { + "grafana-dashboards": { + "defaultRegistryUrlTemplate": "https://grafana.com/api/dashboards/{{packageName}}", + "format": "json", + "transformTemplates": [ + "{\"releases\":[{\"version\": $string(revision)}]}" + ] + } } - } } ``` @@ -303,17 +303,17 @@ Grafana Helm chart `values.yaml` snippet: ```yml dashboards: - default: - 1860-node-exporter-full: - # renovate: depName="Node Exporter Full" - gnetId: 1860 - revision: 31 - datasource: Prometheus - 15760-kubernetes-views-pods: - # renovate: depName="Kubernetes / Views / Pods" - gnetId: 15760 - revision: 20 - datasource: Prometheus + default: + 1860-node-exporter-full: + # renovate: depName="Node Exporter Full" + gnetId: 1860 + revision: 31 + datasource: Prometheus + 15760-kubernetes-views-pods: + # renovate: depName="Kubernetes / Views / Pods" + gnetId: 15760 + revision: 20 + datasource: Prometheus ``` ### Custom offline dependencies @@ -325,12 +325,12 @@ For example, imagine the following file `versiontracker.json` for the software ` ```json [ - { - "version": "77" - }, - { - "version": "76" - } + { + "version": "77" + }, + { + "version": "76" + } ] ``` @@ -339,14 +339,14 @@ This example uses Nexus as the webserver. ```json { - "customDatasources": { - "nexus_generic": { - "defaultRegistryUrlTemplate": "https://nexus.example.com/repository/versiontrackers/{{packageName}}/versiontracker.json", - "transformTemplates": [ - "{ \"releases\": $map($, function($v) { { \"version\": $v.version, \"sourceUrl\": $v.filelink } }) }" - ] + "customDatasources": { + "nexus_generic": { + "defaultRegistryUrlTemplate": "https://nexus.example.com/repository/versiontrackers/{{packageName}}/versiontracker.json", + "transformTemplates": [ + "{ \"releases\": $map($, function($v) { { \"version\": $v.version, \"sourceUrl\": $v.filelink } }) }" + ] + } } - } } ``` @@ -362,17 +362,17 @@ And the following custom manager: ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["\\.yml$"], - "datasourceTemplate": "custom.nexus_generic", - "matchStrings": [ - "#\\s*renovate:\\s*(datasource=(?.*?)\\s*)?depName=(?.*?)(\\s*versioning=(?.*?))?\\s*\\w*:\\s*[\"']?(?.+?)[\"']?\\s" - ], - "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["\\.yml$"], + "datasourceTemplate": "custom.nexus_generic", + "matchStrings": [ + "#\\s*renovate:\\s*(datasource=(?.*?)\\s*)?depName=(?.*?)(\\s*versioning=(?.*?))?\\s*\\w*:\\s*[\"']?(?.+?)[\"']?\\s" + ], + "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" + } + ] } ``` @@ -380,14 +380,14 @@ Or if you have the datasource locally, you can also define your local registry b ```json { - "customDatasources": { - "local_generic": { - "defaultRegistryUrlTemplate": "file://dependencies/{{packageName}}/versiontracker.json", - "transformTemplates": [ - "{ \"releases\": $map($, function($v) { { \"version\": $v.version, \"sourceUrl\": $v.filelink } }) }" - ] + "customDatasources": { + "local_generic": { + "defaultRegistryUrlTemplate": "file://dependencies/{{packageName}}/versiontracker.json", + "transformTemplates": [ + "{ \"releases\": $map($, function($v) { { \"version\": $v.version, \"sourceUrl\": $v.filelink } }) }" + ] + } } - } } ``` @@ -401,18 +401,18 @@ Let's use nginx itself as an example: ```json { - "customDatasources": { - "nginx": { - "defaultRegistryUrlTemplate": "https://nginx.org/download", - "format": "html" - } - }, - "packageRules": [ - { - "matchDatasources": ["custom.nginx"], - "extractVersion": "^nginx-(?.+)\\.tar\\.gz$" - } - ] + "customDatasources": { + "nginx": { + "defaultRegistryUrlTemplate": "https://nginx.org/download", + "format": "html" + } + }, + "packageRules": [ + { + "matchDatasources": ["custom.nginx"], + "extractVersion": "^nginx-(?.+)\\.tar\\.gz$" + } + ] } ``` @@ -422,17 +422,17 @@ You can use the `html` format to extract versions from a typical "Downloads" pag ```json { - "customDatasources": { - "curl": { - "defaultRegistryUrlTemplate": "https://curl.se/download.html", - "format": "html" - } - }, - "packageRules": [ - { - "matchDatasources": ["custom.curl"], - "extractVersion": "/curl-(?.+)\\.tar\\.gz$" - } - ] + "customDatasources": { + "curl": { + "defaultRegistryUrlTemplate": "https://curl.se/download.html", + "format": "html" + } + }, + "packageRules": [ + { + "matchDatasources": ["custom.curl"], + "extractVersion": "/curl-(?.+)\\.tar\\.gz$" + } + ] } ``` diff --git a/lib/modules/datasource/endoflife-date/readme.md b/lib/modules/datasource/endoflife-date/readme.md index 202f25039f19a3..6a6d1480bb828a 100644 --- a/lib/modules/datasource/endoflife-date/readme.md +++ b/lib/modules/datasource/endoflife-date/readme.md @@ -20,24 +20,24 @@ Given the above `.tfvars` file, you put this in your `renovate.json`: ```json { - "customManagers": [ - { - "customType": "regex", - "description": "Update Kubernetes version for Amazon EKS in tfvars files", - "fileMatch": [".+\\.tfvars$"], - "matchStrings": [ - "#\\s*renovate:\\s*datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?\\s.*?_version\\s*=\\s*\"(?.*)\"" - ], - "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{/if}}" - } - ], - "packageRules": [ - { - "matchDatasources": ["endoflife-date"], - "matchPackageNames": ["amazon-eks"], - "extractVersion": "^(?.*)-eks.+$" - } - ] + "customManagers": [ + { + "customType": "regex", + "description": "Update Kubernetes version for Amazon EKS in tfvars files", + "fileMatch": [".+\\.tfvars$"], + "matchStrings": [ + "#\\s*renovate:\\s*datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?\\s.*?_version\\s*=\\s*\"(?.*)\"" + ], + "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{/if}}" + } + ], + "packageRules": [ + { + "matchDatasources": ["endoflife-date"], + "matchPackageNames": ["amazon-eks"], + "extractVersion": "^(?.*)-eks.+$" + } + ] } ``` diff --git a/lib/modules/datasource/galaxy-collection/readme.md b/lib/modules/datasource/galaxy-collection/readme.md index 423a43fe7e754e..4c9e19b13f19d5 100644 --- a/lib/modules/datasource/galaxy-collection/readme.md +++ b/lib/modules/datasource/galaxy-collection/readme.md @@ -3,30 +3,30 @@ But you can override the default if you want. Set your own registries by: -- setting a `source` in your `requirements.yaml` file, _or_ -- writing a `packageRule` to set a new `registryURLs` +- setting a `source` in your `requirements.yaml` file, _or_ +- writing a `packageRule` to set a new `registryURLs` Then you can use Renovate with a private automation hub. ```yaml title="Example config for requirements.yaml" --- collections: - - name: community.general - version: 3.0.0 - source: https://hub.mydomain.com/api/galaxy/content/community/ + - name: community.general + version: 3.0.0 + source: https://hub.mydomain.com/api/galaxy/content/community/ ``` ```json title="Example config for renovate.json" { - "packageRules": [ - { - "matchDatasources": ["galaxy-collection"], - "registryUrls": [ - "https://hub.mydomain.com/api/galaxy/content/community/", - "https://hub.mydomain.com/api/galaxy/content/certified/", - "https://hub.mydomain.com/api/galaxy/content/myprivaterepo/" - ] - } - ] + "packageRules": [ + { + "matchDatasources": ["galaxy-collection"], + "registryUrls": [ + "https://hub.mydomain.com/api/galaxy/content/community/", + "https://hub.mydomain.com/api/galaxy/content/certified/", + "https://hub.mydomain.com/api/galaxy/content/myprivaterepo/" + ] + } + ] } ``` diff --git a/lib/modules/datasource/git-refs/readme.md b/lib/modules/datasource/git-refs/readme.md index dd3db0f5c2562c..42f1e5791307a9 100644 --- a/lib/modules/datasource/git-refs/readme.md +++ b/lib/modules/datasource/git-refs/readme.md @@ -13,16 +13,16 @@ You would configure a custom manager in your Renovate config file for files name ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^versions.ini$"], - "matchStrings": ["GOOGLE_API_VERSION=(?.*?)\\n"], - "currentValueTemplate": "master", - "depNameTemplate": "googleapis", - "packageNameTemplate": "https://github.com/googleapis/googleapis", - "datasourceTemplate": "git-refs" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^versions.ini$"], + "matchStrings": ["GOOGLE_API_VERSION=(?.*?)\\n"], + "currentValueTemplate": "master", + "depNameTemplate": "googleapis", + "packageNameTemplate": "https://github.com/googleapis/googleapis", + "datasourceTemplate": "git-refs" + } + ] } ``` diff --git a/lib/modules/datasource/gitlab-packages/readme.md b/lib/modules/datasource/gitlab-packages/readme.md index 20cb928214fc05..7c7277303a8a58 100644 --- a/lib/modules/datasource/gitlab-packages/readme.md +++ b/lib/modules/datasource/gitlab-packages/readme.md @@ -9,8 +9,8 @@ An example would be `https://gitlab.company.com`. If you are using a self-hosted GitLab instance, please note the following requirements: -- If you are on the `Free` edition, this datasource requires at least GitLab 13.3 -- If you are on the `Premium` or the `Ultimate` edition, this datasource requires at least GitLab 11.8, but GitLab 12.9 or more is recommended if you have a lot of packages with different names in the same project +- If you are on the `Free` edition, this datasource requires at least GitLab 13.3 +- If you are on the `Premium` or the `Ultimate` edition, this datasource requires at least GitLab 11.8, but GitLab 12.9 or more is recommended if you have a lot of packages with different names in the same project **Usage Example** @@ -19,16 +19,16 @@ This can be achieved by configuring a custom manager in `renovate.json` for file ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^versions.ini$"], - "matchStrings": [ - "# renovate: datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?( registryUrl=(?.*?))?\\s.*?_VERSION=(?.*)\\s" - ], - "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^versions.ini$"], + "matchStrings": [ + "# renovate: datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?( registryUrl=(?.*?))?\\s.*?_VERSION=(?.*)\\s" + ], + "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" + } + ] } ``` diff --git a/lib/modules/datasource/gitlab-releases/readme.md b/lib/modules/datasource/gitlab-releases/readme.md index 0b4044d1b239d7..9d4bacf20226ce 100644 --- a/lib/modules/datasource/gitlab-releases/readme.md +++ b/lib/modules/datasource/gitlab-releases/readme.md @@ -9,7 +9,7 @@ An example would be `https://gitlab.company.com`. Please note the following requirements: -- This datasource requires at least GitLab 11.7 +- This datasource requires at least GitLab 11.7 **Usage Example** @@ -18,16 +18,16 @@ This can be achieved by configuring a custom manager in `renovate.json` for file ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^versions.ini$"], - "matchStrings": [ - "# renovate: datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?( registryUrl=(?.*?))?\\s.*?_VERSION=(?.*)\\s" - ], - "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^versions.ini$"], + "matchStrings": [ + "# renovate: datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?( registryUrl=(?.*?))?\\s.*?_VERSION=(?.*)\\s" + ], + "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" + } + ] } ``` diff --git a/lib/modules/datasource/gitlab-tags/readme.md b/lib/modules/datasource/gitlab-tags/readme.md index fdf820fdbfeb68..624896fe9aee7b 100644 --- a/lib/modules/datasource/gitlab-tags/readme.md +++ b/lib/modules/datasource/gitlab-tags/readme.md @@ -13,16 +13,16 @@ This can be achieved by configuring a custom manager in `renovate.json` for file ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^versions.ini$"], - "matchStrings": [ - "# renovate: datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?( registryUrl=(?.*?))?\\s.*?_VERSION=(?.*)\\s" - ], - "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^versions.ini$"], + "matchStrings": [ + "# renovate: datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?( registryUrl=(?.*?))?\\s.*?_VERSION=(?.*)\\s" + ], + "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" + } + ] } ``` diff --git a/lib/modules/datasource/hermit/readme.md b/lib/modules/datasource/hermit/readme.md index 0fdaf4903eb8a8..39bbcf1bfa9851 100644 --- a/lib/modules/datasource/hermit/readme.md +++ b/lib/modules/datasource/hermit/readme.md @@ -8,15 +8,15 @@ To get Renovate to find your private packages, follow these steps: 1. setup a CI pipeline to repeat step 1 & 2 on new commits to the private packages repository. 1. Add a package rule for the Hermit manager, so that Renovate knows where to find your private packages: - ```json - { - "packageRules": [ - { - "matchManagers": ["hermit"], - "defaultRegistryUrls": [ - "https://github.com/your/private-hermit-packages" - ] - } - ] - } - ``` + ```json + { + "packageRules": [ + { + "matchManagers": ["hermit"], + "defaultRegistryUrls": [ + "https://github.com/your/private-hermit-packages" + ] + } + ] + } + ``` diff --git a/lib/modules/datasource/hexpm-bob/readme.md b/lib/modules/datasource/hexpm-bob/readme.md index 8b02802c10ed0f..308c309d6e51a2 100644 --- a/lib/modules/datasource/hexpm-bob/readme.md +++ b/lib/modules/datasource/hexpm-bob/readme.md @@ -2,7 +2,7 @@ This datasource returns releases from [Bob the builder](https://github.com/hexpm Supported values for `packageName`: -- `elixir`, [Elixir homepage](https://elixir-lang.org/) -- `otp/[OS/Version]`, [Erlang/OTP homepage](https://www.erlang.org/) +- `elixir`, [Elixir homepage](https://elixir-lang.org/) +- `otp/[OS/Version]`, [Erlang/OTP homepage](https://www.erlang.org/) Read the [Bob the builder docs, Erlang builds](https://github.com/hexpm/bob#erlang-builds) for a list of supported operating systems and versions. diff --git a/lib/modules/datasource/java-version/readme.md b/lib/modules/datasource/java-version/readme.md index fea9f9660501e9..3d6767ee02f7c7 100644 --- a/lib/modules/datasource/java-version/readme.md +++ b/lib/modules/datasource/java-version/readme.md @@ -3,9 +3,9 @@ This datasource returns releases from the [Adoptium](https://adoptium.net/) API. It uses `image_type=&project=jdk&release_type=ga&sort_method=DATE&sort_order=DESC` as filter parameters. This means that the datasource finds: -- JRE or JDK images -- with a JDK project -- which have the General Availability status +- JRE or JDK images +- with a JDK project +- which have the General Availability status And finally, the results are sorted in descending order. diff --git a/lib/modules/datasource/python-version/readme.md b/lib/modules/datasource/python-version/readme.md index f904048f539810..66d7a7d3fa694a 100644 --- a/lib/modules/datasource/python-version/readme.md +++ b/lib/modules/datasource/python-version/readme.md @@ -17,20 +17,20 @@ FROM image-python${PYTHON_VERSION}-builder:1.0.0 ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^Dockerfile$"], - "matchStringsStrategy": "any", - "matchStrings": [ - "ARG PYTHON_VERSION=\"?(?3(?\\d+))\"?\\s" - ], - "autoReplaceStringTemplate": "ARG PYTHON_VERSION={{{replace '\\.' '' newValue}}}\n", - "currentValueTemplate": "3.{{{minor}}}", - "datasourceTemplate": "python-version", - "versioningTemplate": "python", - "depNameTemplate": "python" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^Dockerfile$"], + "matchStringsStrategy": "any", + "matchStrings": [ + "ARG PYTHON_VERSION=\"?(?3(?\\d+))\"?\\s" + ], + "autoReplaceStringTemplate": "ARG PYTHON_VERSION={{{replace '\\.' '' newValue}}}\n", + "currentValueTemplate": "3.{{{minor}}}", + "datasourceTemplate": "python-version", + "versioningTemplate": "python", + "depNameTemplate": "python" + } + ] } ``` diff --git a/lib/modules/datasource/readme.md b/lib/modules/datasource/readme.md index ba2e625aa71b90..dfa2fbc60d48eb 100644 --- a/lib/modules/datasource/readme.md +++ b/lib/modules/datasource/readme.md @@ -16,17 +16,17 @@ The minimum exported interface for a datasource is a function called `getRelease The config has: -- `packageName`: the package's full name including scope if present (e.g. `@foo/bar`) -- `registryUrls`: an array of registry URLs to try +- `packageName`: the package's full name including scope if present (e.g. `@foo/bar`) +- `registryUrls`: an array of registry URLs to try `getReleases` should return an object having: -- `releases`: an array of strings of matched versions. This is the only mandatory field -- `deprecationMessage`: a string description of the package's deprecation notice, if applicable -- `sourceUrl`: a HTTP URL pointing to the source code (for example on GitHub) -- `homepage`: a HTTP URL for the package's homepage. Ideally should be empty if the homepage and `sourceUrl` are the same -- `changelogUrl`: a URL pointing to the package's changelog (could be a Markdown file, for example). If not present then Renovate will search the `sourceUrl` for a changelog file -- `tags`: an object mapping tag -> version, for example `tags: { latest: '3.0.0' }`. This is only used by the `followTags` function +- `releases`: an array of strings of matched versions. This is the only mandatory field +- `deprecationMessage`: a string description of the package's deprecation notice, if applicable +- `sourceUrl`: a HTTP URL pointing to the source code (for example on GitHub) +- `homepage`: a HTTP URL for the package's homepage. Ideally should be empty if the homepage and `sourceUrl` are the same +- `changelogUrl`: a URL pointing to the package's changelog (could be a Markdown file, for example). If not present then Renovate will search the `sourceUrl` for a changelog file +- `tags`: an object mapping tag -> version, for example `tags: { latest: '3.0.0' }`. This is only used by the `followTags` function ## getDigest @@ -34,8 +34,8 @@ Datasources that support digests (like Docker digests and Git commit hashes) can The `getDigest` function has two inputs: -- `config`: the Renovate config for the package being updated, has the same fields as `getReleases` -- `newValue`: the version or value to retrieve the digest for +- `config`: the Renovate config for the package being updated, has the same fields as `getReleases` +- `newValue`: the version or value to retrieve the digest for The `getDigest` function returns a string output representing the digest value. If no digest is found, the `getDigest` function should return `null`. diff --git a/lib/modules/datasource/repology/readme.md b/lib/modules/datasource/repology/readme.md index 0f04a81c919e0f..2f1bfc928cd71f 100644 --- a/lib/modules/datasource/repology/readme.md +++ b/lib/modules/datasource/repology/readme.md @@ -18,16 +18,16 @@ First you would set a custom manager in your `renovate.json` file for `Dockerfil ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^Dockerfile$"], - "matchStrings": [ - "#\\s*renovate:\\s*datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?\\sENV .*?_VERSION=\"(?.*)\"\\s" - ], - "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^Dockerfile$"], + "matchStrings": [ + "#\\s*renovate:\\s*datasource=(?.*?) depName=(?.*?)( versioning=(?.*?))?\\sENV .*?_VERSION=\"(?.*)\"\\s" + ], + "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}" + } + ] } ``` diff --git a/lib/modules/datasource/rubygems/readme.md b/lib/modules/datasource/rubygems/readme.md index a9078b5563dc05..e60dba136350a3 100644 --- a/lib/modules/datasource/rubygems/readme.md +++ b/lib/modules/datasource/rubygems/readme.md @@ -7,60 +7,60 @@ Datasource query order depends on the registry. Rubygems rate limits are easy to hit, so we need to be careful with the queries. This is implemented with two-level cache: -- First, we query `https://rubygems.org/versions` endpoint for current versions for all packages. +- First, we query `https://rubygems.org/versions` endpoint for current versions for all packages. - Either full or delta sync is performed, depending on the cache state. + Either full or delta sync is performed, depending on the cache state. - All the data of this layer is stored in-memory as the mapping `packageName -> version[]`. + All the data of this layer is stored in-memory as the mapping `packageName -> version[]`. - ```mermaid - stateDiagram-v2 - [*] --> Empty + ```mermaid + stateDiagram-v2 + [*] --> Empty - state "Empty" as Empty - Empty --> FullSync: getPkgReleases() + state "Empty" as Empty + Empty --> FullSync: getPkgReleases() - state "Synced" as Synced - Synced --> DeltaSync + state "Synced" as Synced + Synced --> DeltaSync - state "Unsupported" as Unsupported - Unsupported --> [*] + state "Unsupported" as Unsupported + Unsupported --> [*] - state "Full sync" as FullSync : GET /versions (~20Mb) - state full_sync_result <> - FullSync --> full_sync_result: Response - full_sync_result --> Synced: (1) Status 200 - full_sync_result --> Unsupported: (2) Status 404 - full_sync_result --> Empty: (3) Status other than 200 or 404\n Clear cache and throw ExternalHostError + state "Full sync" as FullSync : GET /versions (~20Mb) + state full_sync_result <> + FullSync --> full_sync_result: Response + full_sync_result --> Synced: (1) Status 200 + full_sync_result --> Unsupported: (2) Status 404 + full_sync_result --> Empty: (3) Status other than 200 or 404\n Clear cache and throw ExternalHostError - state "Delta sync" as DeltaSync: GET /versions with "Range" header - state delta_sync_result <> - DeltaSync --> delta_sync_result: Successful response - delta_sync_result --> Synced: (1) Status other than 206\nFull data is received, extract and replace old cache\n (as if it is the full sync) - delta_sync_result --> FullSync: (2) The head of response doesn't match\n the tail of the previously fetched data - delta_sync_result --> Synced: (3) The head of response matches\n the tail of the previously fetched data + state "Delta sync" as DeltaSync: GET /versions with "Range" header + state delta_sync_result <> + DeltaSync --> delta_sync_result: Successful response + delta_sync_result --> Synced: (1) Status other than 206\nFull data is received, extract and replace old cache\n (as if it is the full sync) + delta_sync_result --> FullSync: (2) The head of response doesn't match\n the tail of the previously fetched data + delta_sync_result --> Synced: (3) The head of response matches\n the tail of the previously fetched data - state delta_sync_error <> - DeltaSync --> delta_sync_error: Error response - delta_sync_error --> FullSync: (1) Status 416 should not happen\nbut moves to full sync - delta_sync_error --> Unsupported: (2) Status 404 - delta_sync_error --> Empty: (3) Status other than 404 or 416 - ``` + state delta_sync_error <> + DeltaSync --> delta_sync_error: Error response + delta_sync_error --> FullSync: (1) Status 416 should not happen\nbut moves to full sync + delta_sync_error --> Unsupported: (2) Status 404 + delta_sync_error --> Empty: (3) Status other than 404 or 416 + ``` -- Then, more data is obtained from `https://rubygems.org/api/v1/versions/.json` and `https://rubygems.org/api/v1/gems/.json`. +- Then, more data is obtained from `https://rubygems.org/api/v1/versions/.json` and `https://rubygems.org/api/v1/gems/.json`. - From the previous layer, the cache key is formed from the `packageName`, and the list of versions is additionally hashed and stored to ensure consistency, so that we reach these API endpoints only when the key has expired or when the list of versions has changed. + From the previous layer, the cache key is formed from the `packageName`, and the list of versions is additionally hashed and stored to ensure consistency, so that we reach these API endpoints only when the key has expired or when the list of versions has changed. - The data for this cache layer is being persisted in the longer-term package cache. + The data for this cache layer is being persisted in the longer-term package cache. ## Querying `rubygems.pkg.github.com` or `gitlab.com` These particular registries are queried using obsolete API -- `/api/v1/dependencies` +- `/api/v1/dependencies` ## Other registries -- Fetch from `/api/v1/versions/.json` -- Fallback to `/info/`, if above fails -- Fallback to the obsolete `/api/v1/dependencies`, if above fails +- Fetch from `/api/v1/versions/.json` +- Fallback to `/info/`, if above fails +- Fallback to the obsolete `/api/v1/dependencies`, if above fails diff --git a/lib/modules/datasource/sbt-package/readme.md b/lib/modules/datasource/sbt-package/readme.md index ff2e3d3a152b82..a4238b6b679324 100644 --- a/lib/modules/datasource/sbt-package/readme.md +++ b/lib/modules/datasource/sbt-package/readme.md @@ -6,10 +6,10 @@ For example: ```json { - "matchDatasources": ["sbt-package"], - "registryUrls": [ - "https://repo.maven.apache.org/maven2", - "https://oss.sonatype.org/content/repositories/snapshots" - ] + "matchDatasources": ["sbt-package"], + "registryUrls": [ + "https://repo.maven.apache.org/maven2", + "https://oss.sonatype.org/content/repositories/snapshots" + ] } ``` diff --git a/lib/modules/datasource/sbt-plugin/readme.md b/lib/modules/datasource/sbt-plugin/readme.md index 01f5302616dcae..5ca65236de39b4 100644 --- a/lib/modules/datasource/sbt-plugin/readme.md +++ b/lib/modules/datasource/sbt-plugin/readme.md @@ -10,11 +10,11 @@ For example: ```json { - "matchDatasources": ["sbt-plugin"], - "registryUrls": [ - "https://repo1.maven.org/maven2/", - "https://oss.sonatype.org/content/repositories/snapshots", - "https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases" - ] + "matchDatasources": ["sbt-plugin"], + "registryUrls": [ + "https://repo1.maven.org/maven2/", + "https://oss.sonatype.org/content/repositories/snapshots", + "https://repo.scala-sbt.org/scalasbt/sbt-plugin-releases" + ] } ``` diff --git a/lib/modules/manager/ansible-galaxy/readme.md b/lib/modules/manager/ansible-galaxy/readme.md index 40eb23a76df03e..02db4997a9d382 100644 --- a/lib/modules/manager/ansible-galaxy/readme.md +++ b/lib/modules/manager/ansible-galaxy/readme.md @@ -2,5 +2,5 @@ Extracts Ansible Galaxy dependencies from configuration files used by the `ansib This manager uses two `depType`s to allow a fine-grained control of which dependencies are upgraded: -- collection -- role +- collection +- role diff --git a/lib/modules/manager/argocd/readme.md b/lib/modules/manager/argocd/readme.md index 2b86d4cdac6b10..fe4769578ba03a 100644 --- a/lib/modules/manager/argocd/readme.md +++ b/lib/modules/manager/argocd/readme.md @@ -8,24 +8,24 @@ Some configuration examples: ```json title="If most .yaml files in your repository are for Argo CD" { - "argocd": { - "fileMatch": ["\\.yaml$"] - } + "argocd": { + "fileMatch": ["\\.yaml$"] + } } ``` ```json title="Argo CD YAML files are in a argocd/ directory" { - "argocd": { - "fileMatch": ["argocd/.+\\.yaml$"] - } + "argocd": { + "fileMatch": ["argocd/.+\\.yaml$"] + } } ``` ```json title="One Argo CD file in a directory" { - "argocd": { - "fileMatch": ["^config/applications\\.yaml$"] - } + "argocd": { + "fileMatch": ["^config/applications\\.yaml$"] + } } ``` diff --git a/lib/modules/manager/azure-pipelines/readme.md b/lib/modules/manager/azure-pipelines/readme.md index 3536e8181f2527..d109bf1725989a 100644 --- a/lib/modules/manager/azure-pipelines/readme.md +++ b/lib/modules/manager/azure-pipelines/readme.md @@ -5,9 +5,9 @@ To opt into running it, set the following: ```json { - "azure-pipelines": { - "enabled": true - } + "azure-pipelines": { + "enabled": true + } } ``` @@ -18,12 +18,12 @@ To use the standard convention for Azure Pipelines, add: ```json { - "packageRules": [ - { - "matchDatasources": ["azure-pipelines-tasks"], - "extractVersion": "^(?\\d+)" - } - ] + "packageRules": [ + { + "matchDatasources": ["azure-pipelines-tasks"], + "extractVersion": "^(?\\d+)" + } + ] } ``` @@ -33,42 +33,42 @@ For example: ```yaml resources: - repositories: - - type: github - name: renovate/renovate - ref: refs/heads/main - - type: github - name: user/repo - ref: refs/tags/v0.5.1 - containers: - - container: linux - image: ubuntu:24.04 - - container: python - image: python:3.7@sha256:3870d35b962a943df72d948580fc66ceaaee1c4fbd205930f32e0f0760eb1077 + repositories: + - type: github + name: renovate/renovate + ref: refs/heads/main + - type: github + name: user/repo + ref: refs/tags/v0.5.1 + containers: + - container: linux + image: ubuntu:24.04 + - container: python + image: python:3.7@sha256:3870d35b962a943df72d948580fc66ceaaee1c4fbd205930f32e0f0760eb1077 stages: - - stage: StageOne - jobs: - - job: JobOne - steps: - - task: Bash@3 - inputs: - script: 'echo Hello World' + - stage: StageOne + jobs: + - job: JobOne + steps: + - task: Bash@3 + inputs: + script: 'echo Hello World' ``` Read the [resources block][resources-docs] and the [tasks block][tasks-docs] Azure Pipelines documentation for more information. The `azure-pipelines` manager can process these files: -- `.azure-pipelines/**/*.yaml` -- `.azure-pipelines.yaml` -- `.azure-pipelines.yml` -- `azure-pipelines/**/*.yaml` -- `azure-pipelines.yaml` -- `azure-pipelines.yml` -- `azure-pipeline/**/*.yaml` -- `azure-pipeline.yaml` -- `azure-pipeline.yml` +- `.azure-pipelines/**/*.yaml` +- `.azure-pipelines.yaml` +- `.azure-pipelines.yml` +- `azure-pipelines/**/*.yaml` +- `azure-pipelines.yaml` +- `azure-pipelines.yml` +- `azure-pipeline/**/*.yaml` +- `azure-pipeline.yaml` +- `azure-pipeline.yml` !!! warning diff --git a/lib/modules/manager/batect/readme.md b/lib/modules/manager/batect/readme.md index 5ba4e364834c6b..cd6482e173d13f 100644 --- a/lib/modules/manager/batect/readme.md +++ b/lib/modules/manager/batect/readme.md @@ -16,13 +16,13 @@ For example: ```json { - "batect": { - "fileMatch": [ - "(^|/)batect(-bundle)?\\.yml$", - "(^|/)my-other-batect-file\\.yml$", - "^a-directory/[^/]*\\.yml$" - ] - } + "batect": { + "fileMatch": [ + "(^|/)batect(-bundle)?\\.yml$", + "(^|/)my-other-batect-file\\.yml$", + "^a-directory/[^/]*\\.yml$" + ] + } } ``` diff --git a/lib/modules/manager/bundler/readme.md b/lib/modules/manager/bundler/readme.md index a374b7b3f67101..60fdf163348a5e 100644 --- a/lib/modules/manager/bundler/readme.md +++ b/lib/modules/manager/bundler/readme.md @@ -6,13 +6,13 @@ If you need Bundler to authenticate with a private registry - and it's not the s ```json { - "hostRules": [ - { - "matchHost": "private-registry.company.com", - "hostType": "rubygems", - "token": "abc123" - } - ] + "hostRules": [ + { + "matchHost": "private-registry.company.com", + "hostType": "rubygems", + "token": "abc123" + } + ] } ``` @@ -28,5 +28,5 @@ Instead of `token`, you may also supply `username` and `password` instead. If you don't want to commit raw secrets to your repository, either: -- If self hosting, add the `hostRules` to your bot's configuration file rather than the repository's configuration file, or -- If using the Mend Renovate App, make use of the [`encrypted`](../../../configuration-options.md#encrypted) capability +- If self hosting, add the `hostRules` to your bot's configuration file rather than the repository's configuration file, or +- If using the Mend Renovate App, make use of the [`encrypted`](../../../configuration-options.md#encrypted) capability diff --git a/lib/modules/manager/cargo/readme.md b/lib/modules/manager/cargo/readme.md index 94baa4638720b7..89cb3fdee0bcd0 100644 --- a/lib/modules/manager/cargo/readme.md +++ b/lib/modules/manager/cargo/readme.md @@ -2,8 +2,8 @@ Extracts dependencies from `Cargo.toml` files, and also updates `Cargo.lock` fil When using the default rangeStrategy=auto: -- If a "less than" instruction is found (e.g. `<2`) then `rangeStrategy=widen` will be selected, -- Otherwise, `rangeStrategy=update-lockfile` will be selected. +- If a "less than" instruction is found (e.g. `<2`) then `rangeStrategy=widen` will be selected, +- Otherwise, `rangeStrategy=update-lockfile` will be selected. The `update-lockfile` default means that most upgrades will update `Cargo.lock` files without the need to change the value in `Cargo.toml`. @@ -20,6 +20,6 @@ Next, all `hostRules` with both a token or username/password and `matchHost` wil Rules from this list are converted to environment variable directives if they match _any_ of these characteristics: -- No `hostType` is defined, or -- `hostType` is `cargo`, or -- `hostType` is a platform (`github`, `gitlab`, `azure`, etc.) +- No `hostType` is defined, or +- `hostType` is `cargo`, or +- `hostType` is a platform (`github`, `gitlab`, `azure`, etc.) diff --git a/lib/modules/manager/cdnurl/readme.md b/lib/modules/manager/cdnurl/readme.md index 1f91341c411d2a..e06f115e6a1e25 100644 --- a/lib/modules/manager/cdnurl/readme.md +++ b/lib/modules/manager/cdnurl/readme.md @@ -3,9 +3,9 @@ For example: ```json { - "cdnurl": { - "fileMatch": ["\\.html?$"] - } + "cdnurl": { + "fileMatch": ["\\.html?$"] + } } ``` diff --git a/lib/modules/manager/circleci/readme.md b/lib/modules/manager/circleci/readme.md index 2380045fd9daba..aaba5a99b66e42 100644 --- a/lib/modules/manager/circleci/readme.md +++ b/lib/modules/manager/circleci/readme.md @@ -14,15 +14,15 @@ The end-result should look like this: ```json { - "hostRules": [ - { - "matchHost": "circleci.com", - "authType": "Token-Only", - "encrypted": { - "token": "****" - } - } - ] + "hostRules": [ + { + "matchHost": "circleci.com", + "authType": "Token-Only", + "encrypted": { + "token": "****" + } + } + ] } ``` diff --git a/lib/modules/manager/composer/readme.md b/lib/modules/manager/composer/readme.md index 310a292d28e25b..b0fb5918cb6f94 100644 --- a/lib/modules/manager/composer/readme.md +++ b/lib/modules/manager/composer/readme.md @@ -5,8 +5,8 @@ For example, the package `acme/foo` would need an entry in [repositories](https: ```json { - "name": "acme/foo", - "type": "vcs", - "url": "http://vcs-of-acme.org/acme/foo.git" + "name": "acme/foo", + "type": "vcs", + "url": "http://vcs-of-acme.org/acme/foo.git" } ``` diff --git a/lib/modules/manager/conan/readme.md b/lib/modules/manager/conan/readme.md index 83f426db1aa95f..5786e0aa8bb133 100644 --- a/lib/modules/manager/conan/readme.md +++ b/lib/modules/manager/conan/readme.md @@ -9,9 +9,9 @@ How it works: 1. Renovate searches in each repository for any `conanfile.txt` or `conanfile.py` file 1. Renovate extracts existing dependencies from: - - the `[requires]` and `[build_requires]` sections in the `conanfile.txt` format - - the `requirements()` and `build_requirements()` functions in the `conanfile.py` format - - and the `python_requires`, `requires` and `build_requires` variables in the `conanfile.py` format + - the `[requires]` and `[build_requires]` sections in the `conanfile.txt` format + - the `requirements()` and `build_requirements()` functions in the `conanfile.py` format + - and the `python_requires`, `requires` and `build_requires` variables in the `conanfile.py` format 1. Renovate resolves the dependency's version using the Conan v2 API 1. If Renovate finds an update, Renovate will update `conanfile.txt` or `conanfile.py` diff --git a/lib/modules/manager/crossplane/readme.md b/lib/modules/manager/crossplane/readme.md index f8b983a20a4f96..09b7e43ccc0572 100644 --- a/lib/modules/manager/crossplane/readme.md +++ b/lib/modules/manager/crossplane/readme.md @@ -4,9 +4,9 @@ By setting your own `fileMatch` Renovate avoids having to check each `*.yaml` fi The `crossplane` manager supports these `depType`s: -- `configuration` -- `function` -- `provider` +- `configuration` +- `function` +- `provider` You can use these `depType`'s to control which dependencies Renovate will upgrade. @@ -16,24 +16,24 @@ Some configuration examples: ```json title="If most .yaml files are for Crossplane" { - "crossplane": { - "fileMatch": ["\\.yaml$"] - } + "crossplane": { + "fileMatch": ["\\.yaml$"] + } } ``` ```json title="For Crossplane files in a packages/ directory" { - "crossplane": { - "fileMatch": ["packages/.+\\.yaml$"] - } + "crossplane": { + "fileMatch": ["packages/.+\\.yaml$"] + } } ``` ```json title="For a single Crossplane file" { - "crossplane": { - "fileMatch": ["^config/provider\\.yaml$"] - } + "crossplane": { + "fileMatch": ["^config/provider\\.yaml$"] + } } ``` diff --git a/lib/modules/manager/custom/regex/readme.md b/lib/modules/manager/custom/regex/readme.md index c612cce62ec108..5d99f9a301e203 100644 --- a/lib/modules/manager/custom/regex/readme.md +++ b/lib/modules/manager/custom/regex/readme.md @@ -6,9 +6,9 @@ Renovate uses the `uhop/node-re2` package that provides bindings for [`google/re Read about [`uhop/node-re2`'s limitations in their readme](https://github.com/uhop/node-re2#limitations-things-re2-does-not-support). The `regex` manager is unique in Renovate because: -- It is configurable via regex named capture groups -- It can extract any `datasource` -- By using the `customManagers` config, you can create multiple "regex managers" for the same repository +- It is configurable via regex named capture groups +- It can extract any `datasource` +- By using the `customManagers` config, you can create multiple "regex managers" for the same repository We have [additional Handlebars helpers](../../../templates.md#additional-handlebars-helpers) to help you perform common transformations on the regex manager's template fields. Also read the documentation for the [`customManagers` config option](../../../configuration-options.md#custommanagers). @@ -17,26 +17,26 @@ Also read the documentation for the [`customManagers` config option](../../../co The first two required fields are `fileMatch` and `matchStrings`: -- `fileMatch` works the same as any manager -- `matchStrings` is a `regex` custom manager concept and is used for configuring a regular expression with named capture groups +- `fileMatch` works the same as any manager +- `matchStrings` is a `regex` custom manager concept and is used for configuring a regular expression with named capture groups Before Renovate can look up a dependency and decide about updates, it needs this information about each dependency: -- The dependency's name -- Which `datasource` to use: npm, Docker, GitHub tags, and so on. For how to format this references see [datasource overview](../../datasource/index.md#supported-datasources) -- Which version scheme to use: defaults to `semver-coerced`, but you may set another value like `pep440`. Supported versioning schemes can be found in the [versioning overview](../../versioning/index.md#supported-versioning) +- The dependency's name +- Which `datasource` to use: npm, Docker, GitHub tags, and so on. For how to format this references see [datasource overview](../../datasource/index.md#supported-datasources) +- Which version scheme to use: defaults to `semver-coerced`, but you may set another value like `pep440`. Supported versioning schemes can be found in the [versioning overview](../../versioning/index.md#supported-versioning) Configuration-wise, it works like this: -- You must capture the `currentValue` of the dependency in a named capture group -- You must have either a `depName` or `packageName` capture group, or use on of the respective template fields ( `depNameTemplate` and `packageNameTemplate` ) -- You must have either a `datasource` capture group or a `datasourceTemplate` config field -- You can optionally have a `depType` capture group or a `depTypeTemplate` config field -- You can optionally have a `versioning` capture group or a `versioningTemplate` config field. If neither are present, Renovate will use `semver-coerced` as the default -- You can optionally have an `extractVersion` capture group or an `extractVersionTemplate` config field -- You can optionally have a `currentDigest` capture group -- You can optionally have a `registryUrl` capture group or a `registryUrlTemplate` config field. If it's a valid URL, it will be converted to the `registryUrls` field as a single-length array -- You can optionally have an `indentation` capture group. It must be either empty or whitespace only, otherwise it will be reset to an empty string +- You must capture the `currentValue` of the dependency in a named capture group +- You must have either a `depName` or `packageName` capture group, or use on of the respective template fields ( `depNameTemplate` and `packageNameTemplate` ) +- You must have either a `datasource` capture group or a `datasourceTemplate` config field +- You can optionally have a `depType` capture group or a `depTypeTemplate` config field +- You can optionally have a `versioning` capture group or a `versioningTemplate` config field. If neither are present, Renovate will use `semver-coerced` as the default +- You can optionally have an `extractVersion` capture group or an `extractVersionTemplate` config field +- You can optionally have a `currentDigest` capture group +- You can optionally have a `registryUrl` capture group or a `registryUrlTemplate` config field. If it's a valid URL, it will be converted to the `registryUrls` field as a single-length array +- You can optionally have an `indentation` capture group. It must be either empty or whitespace only, otherwise it will be reset to an empty string ### Regular Expression Capture Groups @@ -68,15 +68,15 @@ Continuing the above example with Yarn, here is the full Renovate config: ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": ["^Dockerfile$"], - "matchStrings": ["ENV YARN_VERSION=(?.*?)\\n"], - "depNameTemplate": "yarn", - "datasourceTemplate": "npm" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": ["^Dockerfile$"], + "matchStrings": ["ENV YARN_VERSION=(?.*?)\\n"], + "depNameTemplate": "yarn", + "datasourceTemplate": "npm" + } + ] } ``` @@ -103,16 +103,16 @@ You could configure Renovate to update the `Dockerfile` like this: ```json { - "customManagers": [ - { - "customType": "regex", - "description": "Update _VERSION variables in Dockerfiles", - "fileMatch": ["(^|/|\\.)Dockerfile$", "(^|/)Dockerfile\\.[^/]*$"], - "matchStrings": [ - "# renovate: datasource=(?[a-z-]+?)(?: depName=(?.+?))? packageName=(?.+?)(?: versioning=(?[a-z-]+?))?\\s(?:ENV|ARG) .+?_VERSION=(?.+?)\\s" - ] - } - ] + "customManagers": [ + { + "customType": "regex", + "description": "Update _VERSION variables in Dockerfiles", + "fileMatch": ["(^|/|\\.)Dockerfile$", "(^|/)Dockerfile\\.[^/]*$"], + "matchStrings": [ + "# renovate: datasource=(?[a-z-]+?)(?: depName=(?.+?))? packageName=(?.+?)(?: versioning=(?[a-z-]+?))?\\s(?:ENV|ARG) .+?_VERSION=(?.+?)\\s" + ] + } + ] } ``` @@ -146,16 +146,16 @@ Using the `customManagers` below, Renovate looks for available Docker tags of th ```json { - "customManagers": [ - { - "customType": "regex", - "datasourceTemplate": "docker", - "fileMatch": ["(^|/)Chart\\.yaml$"], - "matchStrings": [ - "#\\s?renovate: image=(?.*?)\\s?appVersion:\\s?\\\"?(?[\\w+\\.\\-]*)\"" - ] - } - ] + "customManagers": [ + { + "customType": "regex", + "datasourceTemplate": "docker", + "fileMatch": ["(^|/)Chart\\.yaml$"], + "matchStrings": [ + "#\\s?renovate: image=(?.*?)\\s?appVersion:\\s?\\\"?(?[\\w+\\.\\-]*)\"" + ] + } + ] } ``` @@ -171,21 +171,21 @@ For example: ```json { - "customManagers": [ - { - "customType": "regex", - "fileMatch": [".*y[a]?ml$"], - "matchStringsStrategy": "combination", - "matchStrings": [ - "['\"]?(?/pipeline-fragments/fragment-version-check)['\"]?\\s*ref:\\s['\"]?(?[\\d-]*)['\"]?", - "['\"]?(?pipeline-solutions/gitlab/fragments/fragment-version-check)['\"]?\\s*ref:\\s['\"]?(?[\\d-]*)['\"]?" - ], - "depNameTemplate": "pipeline-solutions/gitlab/fragments/fragment-version-check", - "autoReplaceStringTemplate": "'{{{depName}}}'\n ref: {{{newValue}}}", - "datasourceTemplate": "gitlab-tags", - "versioningTemplate": "gitlab-tags" - } - ] + "customManagers": [ + { + "customType": "regex", + "fileMatch": [".*y[a]?ml$"], + "matchStringsStrategy": "combination", + "matchStrings": [ + "['\"]?(?/pipeline-fragments/fragment-version-check)['\"]?\\s*ref:\\s['\"]?(?[\\d-]*)['\"]?", + "['\"]?(?pipeline-solutions/gitlab/fragments/fragment-version-check)['\"]?\\s*ref:\\s['\"]?(?[\\d-]*)['\"]?" + ], + "depNameTemplate": "pipeline-solutions/gitlab/fragments/fragment-version-check", + "autoReplaceStringTemplate": "'{{{depName}}}'\n ref: {{{newValue}}}", + "datasourceTemplate": "gitlab-tags", + "versioningTemplate": "gitlab-tags" + } + ] } ``` diff --git a/lib/modules/manager/devcontainer/readme.md b/lib/modules/manager/devcontainer/readme.md index 2e709d7e747241..d3353a645e2a11 100644 --- a/lib/modules/manager/devcontainer/readme.md +++ b/lib/modules/manager/devcontainer/readme.md @@ -1,6 +1,6 @@ Extracts all Docker images from the `image` and `features` properties in these files: -- `.devcontainer.json` -- `.devcontainer/devcontainer.json` +- `.devcontainer.json` +- `.devcontainer/devcontainer.json` The `devcontainer` manager does _not_ support `build.dockerFile` or `dockerComposeFile` values as these are covered by the [`dockerfile`](../dockerfile/index.md) and [`docker-compose`](../docker-compose/index.md) managers respectively. diff --git a/lib/modules/manager/dockerfile/readme.md b/lib/modules/manager/dockerfile/readme.md index c9f1ba919a5fb9..7dbdffa637bded 100644 --- a/lib/modules/manager/dockerfile/readme.md +++ b/lib/modules/manager/dockerfile/readme.md @@ -9,13 +9,13 @@ For example, if you know that an image follows SemVer, you can tell Renovate to ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNames": ["whitesource/renovate"], - "versioning": "semver" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNames": ["whitesource/renovate"], + "versioning": "semver" + } + ] } ``` diff --git a/lib/modules/manager/fleet/readme.md b/lib/modules/manager/fleet/readme.md index 2d198829bc135a..27d84abc7542d8 100644 --- a/lib/modules/manager/fleet/readme.md +++ b/lib/modules/manager/fleet/readme.md @@ -5,6 +5,6 @@ To enable GitRepo updates you have to extend your [`fileMatch`](../../../configu ```json { - "fileMatch": ["'(^|/)fleet.ya?ml", "myGitRepoManifests\\.yaml"] + "fileMatch": ["'(^|/)fleet.ya?ml", "myGitRepoManifests\\.yaml"] } ``` diff --git a/lib/modules/manager/flux/readme.md b/lib/modules/manager/flux/readme.md index f13c99c7ebf4af..421a8210450a39 100644 --- a/lib/modules/manager/flux/readme.md +++ b/lib/modules/manager/flux/readme.md @@ -66,9 +66,9 @@ If most `.yaml` files in your repository are Flux manifests, then you could add ```json { - "flux": { - "fileMatch": ["\\.yaml$"] - } + "flux": { + "fileMatch": ["\\.yaml$"] + } } ``` @@ -76,9 +76,9 @@ If instead you have all your Flux manifests inside a `flux/` directory, you woul ```json { - "flux": { - "fileMatch": ["flux/.+\\.yaml$"] - } + "flux": { + "fileMatch": ["flux/.+\\.yaml$"] + } } ``` diff --git a/lib/modules/manager/git-submodules/readme.md b/lib/modules/manager/git-submodules/readme.md index 4c728fa1da0731..46d42a9b18a497 100644 --- a/lib/modules/manager/git-submodules/readme.md +++ b/lib/modules/manager/git-submodules/readme.md @@ -4,10 +4,10 @@ You can customize the per-submodule checks of the git-submodules manager like th ```json { - "ignoreDeps": ["path/to/submodule", "path/to/submodule2"], - "git-submodules": { - "enabled": true - } + "ignoreDeps": ["path/to/submodule", "path/to/submodule2"], + "git-submodules": { + "enabled": true + } } ``` @@ -39,6 +39,6 @@ Next, all `hostRules` with both a token or username/password and `matchHost` wil Rules from this list are converted to environment variable directives if they match _any_ of the following characteristics: -- No `hostType` is defined, or -- `hostType` is `git-tags` or `git-refs`, or -- `hostType` is a platform (`github`, `gitlab`, `azure`, etc.) +- No `hostType` is defined, or +- `hostType` is `git-tags` or `git-refs`, or +- `hostType` is a platform (`github`, `gitlab`, `azure`, etc.) diff --git a/lib/modules/manager/github-actions/readme.md b/lib/modules/manager/github-actions/readme.md index 67857a0ab4fb74..4e9f5b305cfc4a 100644 --- a/lib/modules/manager/github-actions/readme.md +++ b/lib/modules/manager/github-actions/readme.md @@ -9,10 +9,10 @@ name: build on: [push] jobs: - build: - runs-on: ubuntu-latest - steps: - - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0 + build: + runs-on: ubuntu-latest + steps: + - uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4.0.0 ``` Renovate will update the commit SHA according to the GitHub tag you specified. @@ -28,7 +28,7 @@ If you want to automatically pin action digests add the `helpers:pinGitHubAction ```json { - "extends": ["helpers:pinGitHubActionDigests"] + "extends": ["helpers:pinGitHubActionDigests"] } ``` @@ -40,16 +40,16 @@ name: build on: [push] env: - RUNNER: ubuntu-22.04 + RUNNER: ubuntu-22.04 jobs: - build: - runs-on: ${{ env.RUNNER }} + build: + runs-on: ${{ env.RUNNER }} ``` The `github-action` manager understands `ratchet` comments, like `# ratchet:actions/checkout@v2.1.0`. This means that Renovate will: -- update the version of a _pinned_ Ratchet version if needed -- not delete Ratchet comments after parsing them -- keep `# ratchet:exclude` comments +- update the version of a _pinned_ Ratchet version if needed +- not delete Ratchet comments after parsing them +- keep `# ratchet:exclude` comments diff --git a/lib/modules/manager/gitlabci/readme.md b/lib/modules/manager/gitlabci/readme.md index 121cecf3e14cab..d029076efbc4e5 100644 --- a/lib/modules/manager/gitlabci/readme.md +++ b/lib/modules/manager/gitlabci/readme.md @@ -4,15 +4,15 @@ If you need to change the versioning format, read the [versioning](../../version If you use Gitlab Dependency Proxy then you can use these predefined variables as prefixes for your image: -- `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX` -- `CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX` +- `CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX` +- `CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX` If you use the predefined `CI_REGISTRY` variable make sure to configure its value via `registryAliases`: ```json { - "registryAliases": { - "$CI_REGISTRY": "registry.example.com" - } + "registryAliases": { + "$CI_REGISTRY": "registry.example.com" + } } ``` diff --git a/lib/modules/manager/gleam/readme.md b/lib/modules/manager/gleam/readme.md index 183a8db811913e..cf7b261ad5c152 100644 --- a/lib/modules/manager/gleam/readme.md +++ b/lib/modules/manager/gleam/readme.md @@ -2,8 +2,8 @@ Updates `gleam.toml` and/or `manifest.toml` with latest and greatest dependencie The following `depTypes` are currently supported by the `gleam` manager: -- `dependencies` -- `dev-dependencies` +- `dependencies` +- `dev-dependencies` The `gleam` manager extracts dependencies for the `hex` datasource and uses Renovate's implementation of Hex SemVer to evaluate `gleam.toml` updates. The `gleam` manager, however, uses `gleam` itself to keep `manifest.toml` up-to-date. @@ -16,11 +16,11 @@ The `gleam` manager, however, uses `gleam` itself to keep `manifest.toml` up-to- Renovate's `"auto"` strategy defaults to `"widen"` and works like this for `gleam`: 1. If an existing range is a complex range (contains multiple range specifications), Renovate widens it to include the new version. - - Example: `>= 0.14.0 and < 0.15.0` becomes `>= 0.14.0 and < 0.16.1` for a new `0.16.0` version. + - Example: `>= 0.14.0 and < 0.15.0` becomes `>= 0.14.0 and < 0.16.1` for a new `0.16.0` version. 1. For simple ranges, if the update is outside the existing range, Renovate widens the range to include the new version. - - Example: `<= 0.38.0` becomes `<= 0.39.0` for a new `0.39.0` version. + - Example: `<= 0.38.0` becomes `<= 0.39.0` for a new `0.39.0` version. 1. For exact version constraints, Renovate replaces the version with the new one. - - Example: `== 0.12.0` becomes `== 0.13.0` for a new `0.13.0` version. + - Example: `== 0.12.0` becomes `== 0.13.0` for a new `0.13.0` version. !!! warning diff --git a/lib/modules/manager/gomod/readme.md b/lib/modules/manager/gomod/readme.md index c1500021a9bb2a..8a3ee0ceeebcda 100644 --- a/lib/modules/manager/gomod/readme.md +++ b/lib/modules/manager/gomod/readme.md @@ -3,7 +3,7 @@ You might be interested in the following `postUpdateOptions`: 1. `gomodTidy` - if you'd like Renovate to run `go mod tidy` after every update before raising the PR - 1. This is implicitly enabled for major updates if the user has enabled the option `gomodUpdateImportPaths` + 1. This is implicitly enabled for major updates if the user has enabled the option `gomodUpdateImportPaths` 1. `gomodTidy1.17` - if you'd like Renovate to run `go mod tidy -compat=1.17` after every update before raising the PR 1. `gomodTidyE` - if you'd like Renovate to run `go mod tidy -e` after every update before raising the PR 1. `gomodUpdateImportPaths` - if you'd like Renovate to update your source import paths on major updates before raising the PR @@ -16,13 +16,13 @@ Indirect updates are disabled by default. To enable them, add a package rule suc ```json { - "packageRules": [ - { - "matchManagers": ["gomod"], - "matchDepTypes": ["indirect"], - "enabled": true - } - ] + "packageRules": [ + { + "matchManagers": ["gomod"], + "matchDepTypes": ["indirect"], + "enabled": true + } + ] } ``` @@ -39,6 +39,6 @@ Next, all `hostRules` with both a token or username/password and `matchHost` wil Rules from this list are converted to environment variable directives if they match _any_ of the following characteristics: -- No `hostType` is defined, or -- `hostType` is `go`, or -- `hostType` is a platform (`github`, `gitlab`, `azure`, etc.) +- No `hostType` is defined, or +- `hostType` is `go`, or +- `hostType` is a platform (`github`, `gitlab`, `azure`, etc.) diff --git a/lib/modules/manager/helm-requirements/readme.md b/lib/modules/manager/helm-requirements/readme.md index 54cbc289ea6eb6..724d58ae4a42a3 100644 --- a/lib/modules/manager/helm-requirements/readme.md +++ b/lib/modules/manager/helm-requirements/readme.md @@ -4,9 +4,9 @@ The `helm-requirements` manager defines this default registryAlias: ```json { - "registryAliases": { - "stable": "https://charts.helm.sh/stable" - } + "registryAliases": { + "stable": "https://charts.helm.sh/stable" + } } ``` diff --git a/lib/modules/manager/helmfile/readme.md b/lib/modules/manager/helmfile/readme.md index 692f768d15b47e..6b2ffe9dc56bed 100644 --- a/lib/modules/manager/helmfile/readme.md +++ b/lib/modules/manager/helmfile/readme.md @@ -4,9 +4,9 @@ The `helmfile` manager defines this default registryAlias: ```json { - "registryAliases": { - "stable": "https://charts.helm.sh/stable" - } + "registryAliases": { + "stable": "https://charts.helm.sh/stable" + } } ``` @@ -23,23 +23,23 @@ For this you use a custom `hostRules` array. ```json5 { - hostRules: [ - { - // global login - matchHost: 'ghcr.io', - hostType: 'docker', - username: '', - password: '', - }, - { - // login with encrypted password - matchHost: 'https://ghci.io', - hostType: 'docker', - username: '', - encrypted: { - password: 'some-encrypted-password', - }, - }, - ], + hostRules: [ + { + // global login + matchHost: 'ghcr.io', + hostType: 'docker', + username: '', + password: '', + }, + { + // login with encrypted password + matchHost: 'https://ghci.io', + hostType: 'docker', + username: '', + encrypted: { + password: 'some-encrypted-password', + }, + }, + ], } ``` diff --git a/lib/modules/manager/helmsman/readme.md b/lib/modules/manager/helmsman/readme.md index cd1a853a0345b9..37a800e611375c 100644 --- a/lib/modules/manager/helmsman/readme.md +++ b/lib/modules/manager/helmsman/readme.md @@ -9,9 +9,9 @@ To enable the `helmsman` manager, provide a valid `fileMatch` yourself, for exam ```json { - "helmsman": { - "fileMatch": ["(^|/)desired_state\\.yaml$"] - } + "helmsman": { + "fileMatch": ["(^|/)desired_state\\.yaml$"] + } } ``` diff --git a/lib/modules/manager/helmv3/readme.md b/lib/modules/manager/helmv3/readme.md index af2f5017dd9b8f..0664e7809abdc2 100644 --- a/lib/modules/manager/helmv3/readme.md +++ b/lib/modules/manager/helmv3/readme.md @@ -1,15 +1,15 @@ Renovate supports updating Helm Chart references in: -- `requirements.yaml` files, for Helm v2 -- `Chart.yaml` files, for Helm v3 +- `requirements.yaml` files, for Helm v2 +- `Chart.yaml` files, for Helm v3 The `helmv3` manager defines this default registryAlias: ```json { - "registryAliases": { - "stable": "https://charts.helm.sh/stable" - } + "registryAliases": { + "stable": "https://charts.helm.sh/stable" + } } ``` @@ -27,22 +27,22 @@ For this you use a custom `hostRules` array. ```json5 { - hostRules: [ - { - // Global login - matchHost: 'registry.gitlab.com', - hostType: 'docker', - username: '', - password: '', - }, - { - // For repository string oci://registry.gitlab.com/user/oci-helm-test - matchHost: 'https://registry.gitlab.com/user/oci-helm-test', - hostType: 'docker', - username: '', - password: '', - }, - ], + hostRules: [ + { + // Global login + matchHost: 'registry.gitlab.com', + hostType: 'docker', + username: '', + password: '', + }, + { + // For repository string oci://registry.gitlab.com/user/oci-helm-test + matchHost: 'https://registry.gitlab.com/user/oci-helm-test', + hostType: 'docker', + username: '', + password: '', + }, + ], } ``` @@ -50,22 +50,22 @@ For this you use a custom `hostRules` array. ```json5 { - hostRules: [ - { - // Global login for 'gitlab.com' if using Helm - matchHost: 'gitlab.com', - hostType: 'helm', // this is optional, but else the credentials will be used for all requests matching `matchHost` - username: '', - password: '', - }, - { - // Specific repository - matchHost: 'https://gitlab.com/api/v4/projects/xxxxxxx/packages/helm/stable', - hostType: 'helm', // this is optional - username: '', - password: '', - }, - ], + hostRules: [ + { + // Global login for 'gitlab.com' if using Helm + matchHost: 'gitlab.com', + hostType: 'helm', // this is optional, but else the credentials will be used for all requests matching `matchHost` + username: '', + password: '', + }, + { + // Specific repository + matchHost: 'https://gitlab.com/api/v4/projects/xxxxxxx/packages/helm/stable', + hostType: 'helm', // this is optional + username: '', + password: '', + }, + ], } ``` @@ -76,6 +76,6 @@ Renovate now updates archives in the `/charts` folder. ```json { - "postUpdateOptions": ["helmUpdateSubChartArchives"] + "postUpdateOptions": ["helmUpdateSubChartArchives"] } ``` diff --git a/lib/modules/manager/html/readme.md b/lib/modules/manager/html/readme.md index a238a1cf242fd4..feb8189daf317e 100644 --- a/lib/modules/manager/html/readme.md +++ b/lib/modules/manager/html/readme.md @@ -3,5 +3,5 @@ It also updates Subresource Integrity (SRI) hashes in `integrity` attributes. Key differences between the `cdnurl` manager and the `html` manager: -- The `html` manager updates SRI hashes, the `cndurl` manager does not -- The `html` manager automatically finds some files to update, the `cndurl` manager must be given a `fileMatch` +- The `html` manager updates SRI hashes, the `cndurl` manager does not +- The `html` manager automatically finds some files to update, the `cndurl` manager must be given a `fileMatch` diff --git a/lib/modules/manager/kotlin-script/readme.md b/lib/modules/manager/kotlin-script/readme.md index e422ed4ba3436c..fae42034593be6 100644 --- a/lib/modules/manager/kotlin-script/readme.md +++ b/lib/modules/manager/kotlin-script/readme.md @@ -21,8 +21,8 @@ If you want to manage other Kotlin Script files, you may use the `fileMatch` con ```json { - "kotlin-script": { - "fileMatch": ["^.*\\.kts$"] - } + "kotlin-script": { + "fileMatch": ["^.*\\.kts$"] + } } ``` diff --git a/lib/modules/manager/kubernetes/readme.md b/lib/modules/manager/kubernetes/readme.md index 02269933407cc6..af6fdf939f6ace 100644 --- a/lib/modules/manager/kubernetes/readme.md +++ b/lib/modules/manager/kubernetes/readme.md @@ -5,9 +5,9 @@ If most `.yaml` files in your repository are Kubernetes ones, then you could add ```json { - "kubernetes": { - "fileMatch": ["\\.yaml$"] - } + "kubernetes": { + "fileMatch": ["\\.yaml$"] + } } ``` @@ -15,9 +15,9 @@ If instead you have them all inside a `k8s/` directory, you would add this: ```json { - "kubernetes": { - "fileMatch": ["k8s/.+\\.yaml$"] - } + "kubernetes": { + "fileMatch": ["k8s/.+\\.yaml$"] + } } ``` @@ -25,9 +25,9 @@ Or if it's only a single file then something like this: ```json { - "kubernetes": { - "fileMatch": ["^config/k8s\\.yaml$"] - } + "kubernetes": { + "fileMatch": ["^config/k8s\\.yaml$"] + } } ``` diff --git a/lib/modules/manager/kustomize/readme.md b/lib/modules/manager/kustomize/readme.md index a5593b4a7f3a19..0e02db7ca87270 100644 --- a/lib/modules/manager/kustomize/readme.md +++ b/lib/modules/manager/kustomize/readme.md @@ -15,15 +15,15 @@ Renovate can manage these parts of the `kustomization.yaml` file: This manager uses three `depType`s to allow fine-grained control of which dependencies are upgraded: -- Component -- Kustomization -- HelmChart -- OCIChart +- Component +- Kustomization +- HelmChart +- OCIChart **Limitations** -- Using HTTPS to fetch the repositories is not tested -- The keys for the image tags can be in any order +- Using HTTPS to fetch the repositories is not tested +- The keys for the image tags can be in any order ```yaml - name: image/name @@ -33,7 +33,7 @@ This manager uses three `depType`s to allow fine-grained control of which depend name: image/name ``` -- Digests can be pinned in `newTag` or `digest`: +- Digests can be pinned in `newTag` or `digest`: ```yaml - name: image/name @@ -43,7 +43,7 @@ This manager uses three `depType`s to allow fine-grained control of which depend digest: sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f ``` -- The image's repository can be changed with `newName`: +- The image's repository can be changed with `newName`: ```yaml - name: image/name @@ -60,7 +60,7 @@ This manager uses three `depType`s to allow fine-grained control of which depend digest: sha256:3eeba3e2caa30d2aba0fd78a34c1bbeebaa1b96c7aa3c95ec9bac44163c5ca4f ``` -- Images with values ignored by Kustomize will be skipped to avoid ambiguity: +- Images with values ignored by Kustomize will be skipped to avoid ambiguity: ```yaml # bad: skipped because newTag: is ignored when digest: is set diff --git a/lib/modules/manager/mise/readme.md b/lib/modules/manager/mise/readme.md index 4def797b88ad3f..47e7a91a1bf370 100644 --- a/lib/modules/manager/mise/readme.md +++ b/lib/modules/manager/mise/readme.md @@ -26,7 +26,7 @@ Renovate will update `"23.3"` (the primary version) but will not touch `"22.0"` To maintain consistency and reliability, Renovate opts to only manage the _first_ listed version. -- Fallback versions can often be older versions of a tool that are known to work and are there as a backup. +- Fallback versions can often be older versions of a tool that are known to work and are there as a backup. This follows the same workflow that Renovate's `asdf` manager uses. @@ -34,8 +34,8 @@ This follows the same workflow that Renovate's `asdf` manager uses. Renovate uses: -- [mise's plugins](https://github.com/jdx/mise/tree/main/src/plugins/core) -- [asdf's plugins](https://mise.jdx.dev/registry.html) +- [mise's plugins](https://github.com/jdx/mise/tree/main/src/plugins/core) +- [asdf's plugins](https://mise.jdx.dev/registry.html) to understand and manage tool versioning. @@ -45,8 +45,8 @@ Support for new tools/plugins needs to be _manually_ added to Renovate's logic. There are 2 ways to integrate versioning for a new tool: -- Renovate's `mise` manager: ensure upstream `mise` supports the tool, then add support to the `mise` manager in Renovate -- Renovate's `asdf` manager: improve the `asdf` manager in Renovate, which automatically extends support to `mise` +- Renovate's `mise` manager: ensure upstream `mise` supports the tool, then add support to the `mise` manager in Renovate +- Renovate's `asdf` manager: improve the `asdf` manager in Renovate, which automatically extends support to `mise` If `mise` adds support for more tools via its own [core plugins](https://mise.jdx.dev/plugins.html#core-plugins), you can create a PR to extend Renovate's `mise` manager to add support for the new tooling. diff --git a/lib/modules/manager/nix/readme.md b/lib/modules/manager/nix/readme.md index 3a196a34445c0e..7c9cea012e2fd3 100644 --- a/lib/modules/manager/nix/readme.md +++ b/lib/modules/manager/nix/readme.md @@ -1,4 +1,4 @@ The [`nix`](https://github.com/NixOS/nix) manager supports: -- [`lockFileMaintenance`](../../../configuration-options.md#lockfilemaintenance) updates for `flake.lock` -- [nixpkgs](https://github.com/NixOS/nixpkgs) updates +- [`lockFileMaintenance`](../../../configuration-options.md#lockfilemaintenance) updates for `flake.lock` +- [nixpkgs](https://github.com/NixOS/nixpkgs) updates diff --git a/lib/modules/manager/npm/readme.md b/lib/modules/manager/npm/readme.md index a5d8549e57ab5f..97ae85e2a1d575 100644 --- a/lib/modules/manager/npm/readme.md +++ b/lib/modules/manager/npm/readme.md @@ -1,12 +1,12 @@ The following `depTypes` are currently supported by the npm manager : -- `dependencies` -- `devDependencies` -- `optionalDependencies` -- `peerDependencies` -- `engines` : Renovate will update any `node`, `npm` and `yarn` version specified under `engines`. -- `volta` : Renovate will update any `node`, `npm`, `pnpm` and `yarn` version specified under `volta`. -- `packageManager` +- `dependencies` +- `devDependencies` +- `optionalDependencies` +- `peerDependencies` +- `engines` : Renovate will update any `node`, `npm` and `yarn` version specified under `engines`. +- `volta` : Renovate will update any `node`, `npm`, `pnpm` and `yarn` version specified under `volta`. +- `packageManager` ### Yarn diff --git a/lib/modules/manager/nuget/readme.md b/lib/modules/manager/nuget/readme.md index e3608effb8b00a..53f91528c8c2ac 100644 --- a/lib/modules/manager/nuget/readme.md +++ b/lib/modules/manager/nuget/readme.md @@ -2,20 +2,20 @@ Use [`packageRules`](../../../configuration-options.md#packagerules) to control The NuGet package manager supports these SDK-style files and formats: -- `.csproj` -- `.fsproj` -- `.vbproj` -- `.props` -- `.targets` -- `global.json` -- `dotnet-tools.json` +- `.csproj` +- `.fsproj` +- `.vbproj` +- `.props` +- `.targets` +- `global.json` +- `dotnet-tools.json` .NET Core projects are supported by default. For Renovate to work with .NET Framework projects, you need to update these files so they match the new SDK-style format: -- `.csproj` -- `.fsproj` -- `.vbproj` -- `.props` -- `.targets` +- `.csproj` +- `.fsproj` +- `.vbproj` +- `.props` +- `.targets` diff --git a/lib/modules/manager/ocb/readme.md b/lib/modules/manager/ocb/readme.md index 2ca2119d6aedd0..a313f64c46343e 100644 --- a/lib/modules/manager/ocb/readme.md +++ b/lib/modules/manager/ocb/readme.md @@ -6,9 +6,9 @@ Here's a configuration example: ```json title="If your builder files are named like foo-builder.yml or builder.yaml" { - "ocb": { - "fileMatch": ["builder.ya?ml$"] - } + "ocb": { + "fileMatch": ["builder.ya?ml$"] + } } ``` diff --git a/lib/modules/manager/osgi/readme.md b/lib/modules/manager/osgi/readme.md index a3044df8287157..ab844017ddaec6 100644 --- a/lib/modules/manager/osgi/readme.md +++ b/lib/modules/manager/osgi/readme.md @@ -6,5 +6,5 @@ For the definition of artifact list extensions, read [section 159.7.3 of the OSG References: -- [OSGi compendium release 8, Feature Service Specification](https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.feature.html) -- [The Sling implementation of the feature model](https://sling.apache.org/documentation/development/feature-model.html) +- [OSGi compendium release 8, Feature Service Specification](https://docs.osgi.org/specification/osgi.cmpn/8.0.0/service.feature.html) +- [The Sling implementation of the feature model](https://sling.apache.org/documentation/development/feature-model.html) diff --git a/lib/modules/manager/pep621/readme.md b/lib/modules/manager/pep621/readme.md index 3d3009e5b55856..9134a6f6fe1231 100644 --- a/lib/modules/manager/pep621/readme.md +++ b/lib/modules/manager/pep621/readme.md @@ -2,13 +2,13 @@ This manager supports updating dependencies inside `pyproject.toml` files. In addition to standard dependencies, these toolsets are also supported: -- `pdm` (including `pdm.lock` files) -- `hatch` +- `pdm` (including `pdm.lock` files) +- `hatch` Available `depType`s: -- `project.dependencies` -- `project.optional-dependencies` -- `build-system.requires` -- `tool.pdm.dev-dependencies` -- `tool.hatch.envs.` +- `project.dependencies` +- `project.optional-dependencies` +- `build-system.requires` +- `tool.pdm.dev-dependencies` +- `tool.hatch.envs.` diff --git a/lib/modules/manager/pip-compile/readme.md b/lib/modules/manager/pip-compile/readme.md index cb846fb0a78d42..3f6eeab5f371d0 100644 --- a/lib/modules/manager/pip-compile/readme.md +++ b/lib/modules/manager/pip-compile/readme.md @@ -11,9 +11,9 @@ You can "activate" the manager by specifying a `fileMatch` pattern such as: ```json { - "pip-compile": { - "fileMatch": ["(^|/)requirements\\.txt$"] - } + "pip-compile": { + "fileMatch": ["(^|/)requirements\\.txt$"] + } } ``` @@ -24,8 +24,8 @@ You can "activate" the manager by specifying a `fileMatch` pattern such as: As Renovate matches a `pip-compile` output file it will extract original command that was used to create it from header in this file. Because of that `pip-compile` manager poses restrictions on how this file is generated: -- Use default header generation, don't use `--no-header` option. -- Pass all source files explicitly. +- Use default header generation, don't use `--no-header` option. +- Pass all source files explicitly. In turn `pip-compile` manager will find all source files and parse them as package files using their respective managers. @@ -53,12 +53,12 @@ Because `pip-compile` will update source files with their associated manager you ```json { - "pip_requirements": { - "enabled": false - }, - "pip_setup": { - "enabled": false - } + "pip_requirements": { + "enabled": false + }, + "pip_setup": { + "enabled": false + } } ``` @@ -69,9 +69,9 @@ To get Renovate to use another version of Python, add a constraints` rule to the ```json { - "constraints": { - "python": "==3.7" - } + "constraints": { + "python": "==3.7" + } } ``` @@ -79,8 +79,8 @@ To get Renovate to use another version of Python, add a constraints` rule to the Renovate reads the `requirements.txt` file and extracts these `pip-compile` arguments: -- source files as positional arguments -- `--output-file` +- source files as positional arguments +- `--output-file` All other allowed `pip-compile` arguments will be passed over without modification. diff --git a/lib/modules/manager/pipenv/readme.md b/lib/modules/manager/pipenv/readme.md index 1f93b6f8db4a31..d434c22db653e8 100644 --- a/lib/modules/manager/pipenv/readme.md +++ b/lib/modules/manager/pipenv/readme.md @@ -2,7 +2,7 @@ The Pipenv manager supports the default `depTypes`: -- `packages` -- `dev-packages` +- `packages` +- `dev-packages` and also extracts dependencies from other package category groups, using the group name as the `depType`. diff --git a/lib/modules/manager/poetry/readme.md b/lib/modules/manager/poetry/readme.md index 05a8add01d4abe..c72ad85117e5d6 100644 --- a/lib/modules/manager/poetry/readme.md +++ b/lib/modules/manager/poetry/readme.md @@ -4,10 +4,10 @@ Whenever the `pyproject.toml` file is updated, the Poetry lock file will be chec The following `depTypes` are supported by the Poetry manager: -- `dependencies` -- `dev-dependencies` -- `extras` -- `` (dynamic, based on the group name, per [dependency groups documentation](https://python-poetry.org/docs/managing-dependencies/#dependency-groups)) +- `dependencies` +- `dev-dependencies` +- `extras` +- `` (dynamic, based on the group name, per [dependency groups documentation](https://python-poetry.org/docs/managing-dependencies/#dependency-groups)) !!! warning diff --git a/lib/modules/manager/pre-commit/readme.md b/lib/modules/manager/pre-commit/readme.md index 9e91c6cf95cc7b..91557667a5a6e2 100644 --- a/lib/modules/manager/pre-commit/readme.md +++ b/lib/modules/manager/pre-commit/readme.md @@ -9,19 +9,19 @@ Updates are performed if the files follow the conventional format used in typica ```yaml repos: - - repo: https://github.com/pre-commit/pre-commit-hooks - rev: v1.0.0 - hooks: - - id: some-hook-id + - repo: https://github.com/pre-commit/pre-commit-hooks + rev: v1.0.0 + hooks: + - id: some-hook-id ``` To enable the `pre-commit` manager, add the following config: ```json { - "pre-commit": { - "enabled": true - } + "pre-commit": { + "enabled": true + } } ``` diff --git a/lib/modules/manager/puppet/readme.md b/lib/modules/manager/puppet/readme.md index 1aa0a511ca85d4..de0cc0baef1ecd 100644 --- a/lib/modules/manager/puppet/readme.md +++ b/lib/modules/manager/puppet/readme.md @@ -16,11 +16,11 @@ Finally, if the source repository has a "changelog" file _or_ uses GitHub releas The `puppet` manager extracts the dependencies from one Puppetfile. You can define a forge in your `puppetfile` in these ways: -- No forge -- One forge -- Multiple forges -- GitHub-based forge -- Git-based forge +- No forge +- One forge +- Multiple forges +- GitHub-based forge +- Git-based forge For example: diff --git a/lib/modules/manager/runtime-version/readme.md b/lib/modules/manager/runtime-version/readme.md index 0325f307832d0b..d5e0aff27eaabb 100644 --- a/lib/modules/manager/runtime-version/readme.md +++ b/lib/modules/manager/runtime-version/readme.md @@ -2,7 +2,7 @@ Keep `runtime.txt` files updated. Currently supports `Python` runtime updates, commonly used by platforms such as -- [Heroku](https://devcenter.heroku.com/articles/python-runtimes) -- [CloudFoundry](https://docs.cloudfoundry.org/buildpacks/python/index.html) -- [Koyeb](https://www.koyeb.com/docs/build-and-deploy/build-from-git/python) -- and more +- [Heroku](https://devcenter.heroku.com/articles/python-runtimes) +- [CloudFoundry](https://docs.cloudfoundry.org/buildpacks/python/index.html) +- [Koyeb](https://www.koyeb.com/docs/build-and-deploy/build-from-git/python) +- and more diff --git a/lib/modules/manager/tekton/readme.md b/lib/modules/manager/tekton/readme.md index d68eb423d3cf95..3748e8fc6ca652 100644 --- a/lib/modules/manager/tekton/readme.md +++ b/lib/modules/manager/tekton/readme.md @@ -23,10 +23,10 @@ By specifying the annotation with a remote task or a remote pipeline based on th apiVersion: tekton.dev/v1 kind: PipelineRun metadata: - name: main - annotations: - pipelinesascode.tekton.dev/task: 'https://github.com/foo/bar/raw/v0.0.1/task/my-task/my-task.yaml' - pipelinesascode.tekton.dev/pipeline: 'https://github.com/foo/bar/raw/v0.0.1/pipeline/my-pipeline/my-pipeline.yaml' + name: main + annotations: + pipelinesascode.tekton.dev/task: 'https://github.com/foo/bar/raw/v0.0.1/task/my-task/my-task.yaml' + pipelinesascode.tekton.dev/pipeline: 'https://github.com/foo/bar/raw/v0.0.1/pipeline/my-pipeline/my-pipeline.yaml' ``` Supported URLs: @@ -72,9 +72,9 @@ As an example, the following config matches all the YAML files in a repository: ```json { - "tekton": { - "fileMatch": ["\\.yaml$", "\\.yml$"] - } + "tekton": { + "fileMatch": ["\\.yaml$", "\\.yml$"] + } } ``` diff --git a/lib/modules/manager/terraform/readme.md b/lib/modules/manager/terraform/readme.md index b950ca1c9a672f..717185e51187e7 100644 --- a/lib/modules/manager/terraform/readme.md +++ b/lib/modules/manager/terraform/readme.md @@ -7,12 +7,12 @@ You can override this default with your own `packageRules`, for example: ```json title="Prefer releases from OpenTofu" { - "packageRules": [ - { - "matchDatasources": ["terraform-provider"], - "registryUrls": ["https://registry.opentofu.org"] - } - ] + "packageRules": [ + { + "matchDatasources": ["terraform-provider"], + "registryUrls": ["https://registry.opentofu.org"] + } + ] } ``` diff --git a/lib/modules/manager/terragrunt/readme.md b/lib/modules/manager/terragrunt/readme.md index 9467626ad96777..beb946674ee1dc 100644 --- a/lib/modules/manager/terragrunt/readme.md +++ b/lib/modules/manager/terragrunt/readme.md @@ -5,9 +5,9 @@ For example, if you want to reference a tag like `module-v1.2.5`, a block like t ```json { - "terragrunt": { - "versioning": "regex:^((?.*)-v|v*)(?\\d+)\\.(?\\d+)\\.(?\\d+)$" - } + "terragrunt": { + "versioning": "regex:^((?.*)-v|v*)(?\\d+)\\.(?\\d+)\\.(?\\d+)$" + } } ``` diff --git a/lib/modules/manager/travis/readme.md b/lib/modules/manager/travis/readme.md index 6e5cbaed906c63..304e858de682ad 100644 --- a/lib/modules/manager/travis/readme.md +++ b/lib/modules/manager/travis/readme.md @@ -17,10 +17,10 @@ Here's how to enable major updates in your Renovate config: ```json { - "travis": { - "major": { - "enabled": true + "travis": { + "major": { + "enabled": true + } } - } } ``` diff --git a/lib/modules/manager/vendir/readme.md b/lib/modules/manager/vendir/readme.md index e5f69961ccc9a5..4eff8220023feb 100644 --- a/lib/modules/manager/vendir/readme.md +++ b/lib/modules/manager/vendir/readme.md @@ -2,8 +2,8 @@ Renovate can update Helm Chart references and Git references in `vendir.yml` fil For Renovate to work you must: -- let vendir create a [vendir lockfile](https://carvel.dev/vendir/docs/v0.40.x/vendir-lock-spec/) -- put the vendir lockfile in your repository +- let vendir create a [vendir lockfile](https://carvel.dev/vendir/docs/v0.40.x/vendir-lock-spec/) +- put the vendir lockfile in your repository ### Helm Charts @@ -15,23 +15,23 @@ kind: Config # one or more directories to manage with vendir directories: - - # path is relative to the `vendir` CLI working directory - path: config/_ytt_lib - contents: - path: github.com/cloudfoundry/cf-k8s-networking - helmChart: - # chart name (required) - name: stable/redis - # use specific chart version (string; optional) - version: '1.2.1' - # specifies Helm repository to fetch from (optional) - repository: - # repository url; supports experimental OCI Helm fetch via - # oci:// scheme (required) - url: https://... - # specify Helm binary version to use; - # '3' means binary 'helm3' needs to be on the path (optional) - helmVersion: '3' + - # path is relative to the `vendir` CLI working directory + path: config/_ytt_lib + contents: + path: github.com/cloudfoundry/cf-k8s-networking + helmChart: + # chart name (required) + name: stable/redis + # use specific chart version (string; optional) + version: '1.2.1' + # specifies Helm repository to fetch from (optional) + repository: + # repository url; supports experimental OCI Helm fetch via + # oci:// scheme (required) + url: https://... + # specify Helm binary version to use; + # '3' means binary 'helm3' needs to be on the path (optional) + helmVersion: '3' ``` ### Registry Aliases @@ -70,13 +70,13 @@ Renovate can update explicit tags in GitHub releases in `vendir.yml` files. ```yaml title="Example GitHub vendir.yml" directories: - - path: config/_ytt_lib - contents: - path: github.com/cloudfoundry/cf-k8s-networking - githubRelease: - # slug for repository (org/repo) (required) - slug: k14s/kapp-controller - # use release tag (optional) - # optional if tagSelection is specified (available in v0.22.0+) - tag: v0.1.0 + - path: config/_ytt_lib + contents: + path: github.com/cloudfoundry/cf-k8s-networking + githubRelease: + # slug for repository (org/repo) (required) + slug: k14s/kapp-controller + # use release tag (optional) + # optional if tagSelection is specified (available in v0.22.0+) + tag: v0.1.0 ``` diff --git a/lib/modules/manager/woodpecker/readme.md b/lib/modules/manager/woodpecker/readme.md index 62dbe24421952c..a68620e95af6fd 100644 --- a/lib/modules/manager/woodpecker/readme.md +++ b/lib/modules/manager/woodpecker/readme.md @@ -1,7 +1,7 @@ Extracts all Docker images from Woodpecker Pipeline YAML files. -- [Woodpecker homepage](https://woodpecker-ci.org/) -- [Woodpecker Docs: Workflow Syntax](https://woodpecker-ci.org/docs/usage/workflow-syntax) ([section with dependencies](https://woodpecker-ci.org/docs/usage/workflow-syntax#image)) -- [`woodpecker-ci` JSON schema](https://raw.githubusercontent.com/woodpecker-ci/woodpecker/main/pipeline/frontend/yaml/linter/schema/schema.json) +- [Woodpecker homepage](https://woodpecker-ci.org/) +- [Woodpecker Docs: Workflow Syntax](https://woodpecker-ci.org/docs/usage/workflow-syntax) ([section with dependencies](https://woodpecker-ci.org/docs/usage/workflow-syntax#image)) +- [`woodpecker-ci` JSON schema](https://raw.githubusercontent.com/woodpecker-ci/woodpecker/main/pipeline/frontend/yaml/linter/schema/schema.json) If you need to change the versioning format, read the [versioning](../../versioning/index.md) documentation to learn more. diff --git a/lib/modules/platform/azure/readme.md b/lib/modules/platform/azure/readme.md index cb06f4b7a66080..f5791a1fbd6834 100644 --- a/lib/modules/platform/azure/readme.md +++ b/lib/modules/platform/azure/readme.md @@ -5,9 +5,9 @@ First, [create a Personal Access Token](https://docs.microsoft.com/en-us/azure/devops/organizations/accounts/use-personal-access-tokens-to-authenticate?view=azure-devops&tabs=preview-page) for the bot account. Let Renovate use your PAT by doing _one_ of the following: -- Set your PAT as a `token` in your `config.js` file -- Set your PAT as an environment variable `RENOVATE_TOKEN` -- Set your PAT when you run Renovate in the CLI with `--token=` +- Set your PAT as a `token` in your `config.js` file +- Set your PAT as an environment variable `RENOVATE_TOKEN` +- Set your PAT when you run Renovate in the CLI with `--token=` Permissions for your PAT should be at minimum: @@ -34,30 +34,30 @@ Replace _all_ content in the starter pipeline with: ```yaml schedules: - - cron: '0 3 * * *' - displayName: 'Every day at 3am (UTC)' - branches: - include: [main] - always: true + - cron: '0 3 * * *' + displayName: 'Every day at 3am (UTC)' + branches: + include: [main] + always: true trigger: none pool: - vmImage: ubuntu-latest + vmImage: ubuntu-latest steps: - - task: npmAuthenticate@0 - inputs: - workingFile: .npmrc - - - bash: | - git config --global user.email 'bot@renovateapp.com' - git config --global user.name 'Renovate Bot' - npx --userconfig .npmrc renovate - env: - RENOVATE_PLATFORM: azure - RENOVATE_ENDPOINT: $(System.CollectionUri) - RENOVATE_TOKEN: $(System.AccessToken) + - task: npmAuthenticate@0 + inputs: + workingFile: .npmrc + + - bash: | + git config --global user.email 'bot@renovateapp.com' + git config --global user.name 'Renovate Bot' + npx --userconfig .npmrc renovate + env: + RENOVATE_PLATFORM: azure + RENOVATE_ENDPOINT: $(System.CollectionUri) + RENOVATE_TOKEN: $(System.AccessToken) ``` ### Create a .npmrc file @@ -77,15 +77,15 @@ Create a `config.js` file in your repository: ```javascript module.exports = { - hostRules: [ - { - hostType: 'npm', - matchHost: 'pkgs.dev.azure.com', - username: 'apikey', - password: process.env.RENOVATE_TOKEN, - }, - ], - repositories: ['YOUR-PROJECT/YOUR-REPO'], + hostRules: [ + { + hostType: 'npm', + matchHost: 'pkgs.dev.azure.com', + username: 'apikey', + password: process.env.RENOVATE_TOKEN, + }, + ], + repositories: ['YOUR-PROJECT/YOUR-REPO'], }; ``` @@ -98,20 +98,20 @@ Use the `matchHost` config option to specify the full path to the registry. ```javascript module.exports = { - platform: 'azure', - hostRules: [ - { - matchHost: - 'https://myorg.pkgs.visualstudio.com/_packaging/myorg/npm/registry/', - token: process.env.RENOVATE_TOKEN, - hostType: 'npm', - }, - { - matchHost: 'github.com', - token: process.env.GITHUB_COM_TOKEN, - }, - ], - repositories: ['YOUR-PROJECT/YOUR-REPO'], + platform: 'azure', + hostRules: [ + { + matchHost: + 'https://myorg.pkgs.visualstudio.com/_packaging/myorg/npm/registry/', + token: process.env.RENOVATE_TOKEN, + hostType: 'npm', + }, + { + matchHost: 'github.com', + token: process.env.GITHUB_COM_TOKEN, + }, + ], + repositories: ['YOUR-PROJECT/YOUR-REPO'], }; ``` @@ -134,22 +134,22 @@ If you want to use a single Renovate pipeline to update multiple repositories yo Add the names of the repositories to `config.js`. Make sure that the "Project Collection Build Service (YOUR-PROJECT)" user has the following permissions on the repositories: -- Contribute -- Contribute to pull requests -- Create branch -- Read +- Contribute +- Contribute to pull requests +- Create branch +- Read The user must have the following permission at Project-level: -- View project-level information +- View project-level information ### Linking a work item to the Pull Requests If you want Renovate to automatically link an existing work item to the Pull Requests, you can set the `azureWorkItemId` configuration. Make sure the user has the following permissions on the work item's _area path_: -- Edit work items in this node -- View work items in this node +- Edit work items in this node +- View work items in this node If the user does not have these permissions, Renovate still creates a PR but it won't have a link to the work item. @@ -158,6 +158,6 @@ If the user does not have these permissions, Renovate still creates a PR but it Tags can be added to Pull Requests using the `labels` or `addLabels` configurations. If the tag does not exist in the DevOps project, it will be created automatically during creation of the Pull Request as long as the user has the permissions at Project-level: -- Create tag definition +- Create tag definition Otherwise, when a tag does not exist and the user does not have permission to create it, Renovate will output an error during creation of the Pull Request. diff --git a/lib/modules/platform/bitbucket-server/readme.md b/lib/modules/platform/bitbucket-server/readme.md index 722c0f0defe4a5..db53c2301b4cac 100644 --- a/lib/modules/platform/bitbucket-server/readme.md +++ b/lib/modules/platform/bitbucket-server/readme.md @@ -5,9 +5,9 @@ First, create a [HTTP access token](https://confluence.atlassian.com/bitbucketserver/personal-access-tokens-939515499.html) for the bot account. Let Renovate use your HTTP access token by doing _one_ of the following: -- Set your HTTP access token as a `token` in your `config.js` file -- Set your HTTP access token as an environment variable `RENOVATE_TOKEN` -- Set your HTTP access token when you run Renovate in the CLI with `--token=` +- Set your HTTP access token as a `token` in your `config.js` file +- Set your HTTP access token as an environment variable `RENOVATE_TOKEN` +- Set your HTTP access token when you run Renovate in the CLI with `--token=` If you use project or repository based HTTP access tokens, it can only be used as `token`. @@ -19,13 +19,13 @@ If you use MySQL or MariaDB you must set `unicodeEmoji` to `false` in the global ## Unsupported platform features/concepts -- Adding assignees to PRs not supported (does not seem to be a Bitbucket concept) -- Adding/removing labels (Bitbucket limitation) +- Adding assignees to PRs not supported (does not seem to be a Bitbucket concept) +- Adding/removing labels (Bitbucket limitation) ## Features awaiting implementation -- Creating issues not implemented yet, used to alert users when there is a config error -- The `automergeStrategy` configuration option has not been implemented for this platform, and all values behave as if the value `auto` was used. Renovate will implicitly use the merge strategy configured as 'default' in the Bitbucket Server repository itself, and this cannot be overridden yet +- Creating issues not implemented yet, used to alert users when there is a config error +- The `automergeStrategy` configuration option has not been implemented for this platform, and all values behave as if the value `auto` was used. Renovate will implicitly use the merge strategy configured as 'default' in the Bitbucket Server repository itself, and this cannot be overridden yet ## Testing diff --git a/lib/modules/platform/bitbucket/readme.md b/lib/modules/platform/bitbucket/readme.md index 7053ae2c31b5f5..88a5b616db8191 100644 --- a/lib/modules/platform/bitbucket/readme.md +++ b/lib/modules/platform/bitbucket/readme.md @@ -7,9 +7,9 @@ Most of the information on this page is meant for users who want to self-host Re For most users, the easiest way to get started is to install [the Mend app for Bitbucket](https://marketplace.atlassian.com/apps/1232072/mend?tab=overview&hosting=cloud) and use the free Renovate plan. When you use the app, Mend will: -- authenticate the app to Bitbucket Cloud -- keep the tokens safe -- maintain and update the Renovate version used +- authenticate the app to Bitbucket Cloud +- keep the tokens safe +- maintain and update the Renovate version used If you self-host Renovate you must do the things listed above yourself. Self-hosting is meant for users with advanced use cases, or who want to be in full control of the bot and the environment it runs in. @@ -35,16 +35,16 @@ The bot also needs to validate the workspace membership status of pull-request r Let Renovate use your app password by doing _one_ of the following: -- Set your app password as a `password` in your `config.js` file -- Set your app password as an environment variable `RENOVATE_PASSWORD` -- Set your app password when you run Renovate in the CLI with `--password=` +- Set your app password as a `password` in your `config.js` file +- Set your app password as an environment variable `RENOVATE_PASSWORD` +- Set your app password when you run Renovate in the CLI with `--password=` Remember to: -- Set the `username` for the bot account (which is _not_ your email address). You can find your username through "Personal Bitbucket settings" on the "Account settings" page for your account -- Set `platform=bitbucket` somewhere in your Renovate config file +- Set the `username` for the bot account (which is _not_ your email address). You can find your username through "Personal Bitbucket settings" on the "Account settings" page for your account +- Set `platform=bitbucket` somewhere in your Renovate config file ## Unsupported platform features/concepts -- Adding assignees to PRs not supported (does not seem to be a Bitbucket concept) -- `automergeStrategy=rebase` not supported by Bitbucket Cloud, see [Jira issue BCLOUD-16610](https://jira.atlassian.com/browse/BCLOUD-16610) +- Adding assignees to PRs not supported (does not seem to be a Bitbucket concept) +- `automergeStrategy=rebase` not supported by Bitbucket Cloud, see [Jira issue BCLOUD-16610](https://jira.atlassian.com/browse/BCLOUD-16610) diff --git a/lib/modules/platform/codecommit/readme.md b/lib/modules/platform/codecommit/readme.md index dc13d743bb41de..465057101c1151 100644 --- a/lib/modules/platform/codecommit/readme.md +++ b/lib/modules/platform/codecommit/readme.md @@ -19,8 +19,8 @@ 1. Install the `aws-cli` program on the machine. 2. Set up the environment with the `git-credentials-helper`: - - For EC2 or Linux: [EC2 codecommit git integration](https://aws.amazon.com/premiumsupport/knowledge-center/codecommit-git-repositories-ec2/). - - For Windows: [windows codecommit git integration](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-windows.html). + - For EC2 or Linux: [EC2 codecommit git integration](https://aws.amazon.com/premiumsupport/knowledge-center/codecommit-git-repositories-ec2/). + - For Windows: [windows codecommit git integration](https://docs.aws.amazon.com/codecommit/latest/userguide/setting-up-https-windows.html). 3. Set the environment variable `AWS_REGION`. @@ -35,9 +35,9 @@ env: git-credential-helper:yes First, you must get an AWS [IAM Access Key id and a Secret access key id](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_access-keys.html). After that, let Renovate use the AWS CodeCommit authentication keys, by picking _one_ of these methods: -- Create a Renovate config file (`config.js`) -- Set the environment with all required AWS environment variables -- Set AWS credentials with CLI parameters +- Create a Renovate config file (`config.js`) +- Set the environment with all required AWS environment variables +- Set AWS credentials with CLI parameters #### Method 1: Create a Renovate config file (`config.js`) @@ -74,31 +74,31 @@ Change the `Resource` value to the resources you want to use: ```json title="Example policy JSON file" { - "Version": "2012-10-17", - "Statement": [ - { - "Sid": "RenovatePolicy", - "Effect": "Allow", - "Action": [ - "codecommit:DeleteCommentContent", - "codecommit:UpdatePullRequestDescription", - "codecommit:GitPull", - "codecommit:ListPullRequests", - "codecommit:GetCommentsForPullRequest", - "codecommit:ListRepositories", - "codecommit:UpdatePullRequestTitle", - "codecommit:GetFile", - "codecommit:UpdateComment", - "codecommit:GetRepository", - "codecommit:CreatePullRequest", - "codecommit:CreatePullRequestApprovalRule", - "codecommit:GitPush", - "codecommit:UpdatePullRequestStatus", - "codecommit:GetPullRequest" - ], - "Resource": "*" - } - ] + "Version": "2012-10-17", + "Statement": [ + { + "Sid": "RenovatePolicy", + "Effect": "Allow", + "Action": [ + "codecommit:DeleteCommentContent", + "codecommit:UpdatePullRequestDescription", + "codecommit:GitPull", + "codecommit:ListPullRequests", + "codecommit:GetCommentsForPullRequest", + "codecommit:ListRepositories", + "codecommit:UpdatePullRequestTitle", + "codecommit:GetFile", + "codecommit:UpdateComment", + "codecommit:GetRepository", + "codecommit:CreatePullRequest", + "codecommit:CreatePullRequestApprovalRule", + "codecommit:GitPush", + "codecommit:UpdatePullRequestStatus", + "codecommit:GetPullRequest" + ], + "Resource": "*" + } + ] } ``` @@ -106,8 +106,8 @@ Change the `Resource` value to the resources you want to use: Once you have followed method 1, 2 or 3, _and_ have set up the permissions, you're ready to configure Renovate: -- Set `platform: 'codecommit'` -- Set `repositories: ['{repository, names, separated, by, comma}']`, or use [Renovate’s `autodiscover` feature](../../../self-hosted-configuration.md#autodiscover) +- Set `platform: 'codecommit'` +- Set `repositories: ['{repository, names, separated, by, comma}']`, or use [Renovate’s `autodiscover` feature](../../../self-hosted-configuration.md#autodiscover) You're ready to run Renovate now, and it will process your repositories. @@ -115,9 +115,9 @@ You're ready to run Renovate now, and it will process your repositories. These Renovate features are not supported on Codecommit: -- Adding assignees to PRs -- Automerge -- [`rebaseLabel`](../../../configuration-options.md#rebaselabel) (request a rebase for Renovate) +- Adding assignees to PRs +- Automerge +- [`rebaseLabel`](../../../configuration-options.md#rebaselabel) (request a rebase for Renovate) ## Recommendations @@ -130,19 +130,19 @@ This workaround is needed due to platform limitations. ```js title="Example config.js file" module.exports = { - endpoint: 'https://git-codecommit.us-east-1.amazonaws.com/', - platform: 'codecommit', - repositories: ['abc/def', 'abc/ghi'], - username: 'ACCESS_KEY_ID_GOES_HERE', - password: 'SECRET_ACCESS_KEY_GOES_HERE', - token: 'AWS_SESSION_TOKEN_GOES_HERE', - gitAuthor: 'your_email@domain', - packageRules: [ - { - matchPackageNames: ['package_name', 'package_name2'], - enabled: false, - }, - ], + endpoint: 'https://git-codecommit.us-east-1.amazonaws.com/', + platform: 'codecommit', + repositories: ['abc/def', 'abc/ghi'], + username: 'ACCESS_KEY_ID_GOES_HERE', + password: 'SECRET_ACCESS_KEY_GOES_HERE', + token: 'AWS_SESSION_TOKEN_GOES_HERE', + gitAuthor: 'your_email@domain', + packageRules: [ + { + matchPackageNames: ['package_name', 'package_name2'], + enabled: false, + }, + ], }; ``` @@ -156,19 +156,19 @@ This repository will be your BuildProject job repository to run Renovate on your ```yml title="Example buildspec.yml file" version: 0.2 env: - shell: bash - git-credential-helper: yes - variables: - RENOVATE_PLATFORM: 'codecommit' - RENOVATE_REPOSITORIES: '["repoName1", "repoName2"]' - RENOVATE_CONFIG: '{"extends":["config:recommended"]}' - LOG_LEVEL: 'debug' - AWS_REGION: 'us-east-1' + shell: bash + git-credential-helper: yes + variables: + RENOVATE_PLATFORM: 'codecommit' + RENOVATE_REPOSITORIES: '["repoName1", "repoName2"]' + RENOVATE_CONFIG: '{"extends":["config:recommended"]}' + LOG_LEVEL: 'debug' + AWS_REGION: 'us-east-1' phases: - build: - on-failure: CONTINUE - commands: - - docker run --rm -e AWS_REGION -e RENOVATE_CONFIG -e RENOVATE_PLATFORM -e RENOVATE_REPOSITORIES -e LOG_LEVEL renovate/renovate + build: + on-failure: CONTINUE + commands: + - docker run --rm -e AWS_REGION -e RENOVATE_CONFIG -e RENOVATE_PLATFORM -e RENOVATE_REPOSITORIES -e LOG_LEVEL renovate/renovate ``` ### Renovate CLI `buildspec.yml` @@ -176,20 +176,20 @@ phases: ```yml title="Example buildspec.yml file" version: 0.2 env: - shell: bash - git-credential-helper: yes - variables: - RENOVATE_PLATFORM: 'codecommit' - RENOVATE_REPOSITORIES: '["repoName1", "repoName2"]' - RENOVATE_CONFIG: '{"extends":["config:recommended"]}' - LOG_LEVEL: 'debug' - AWS_REGION: 'us-east-1' + shell: bash + git-credential-helper: yes + variables: + RENOVATE_PLATFORM: 'codecommit' + RENOVATE_REPOSITORIES: '["repoName1", "repoName2"]' + RENOVATE_CONFIG: '{"extends":["config:recommended"]}' + LOG_LEVEL: 'debug' + AWS_REGION: 'us-east-1' phases: - build: - on-failure: CONTINUE - commands: - - npm install -g renovate - - renovate + build: + on-failure: CONTINUE + commands: + - npm install -g renovate + - renovate ``` ### Notes diff --git a/lib/modules/platform/gerrit/readme.md b/lib/modules/platform/gerrit/readme.md index 7246f3f946dc78..41aa1bdb07a74c 100644 --- a/lib/modules/platform/gerrit/readme.md +++ b/lib/modules/platform/gerrit/readme.md @@ -23,9 +23,9 @@ This means changes without metadata in the commit message footer will be "forgot Let Renovate use your HTTP access token by doing _one_ of the following: -- Set your HTTP access token as a `password` in your `config.js` file, or -- Set your HTTP access token as an environment variable `RENOVATE_PASSWORD`, or -- Set your HTTP access token when you run Renovate in the CLI with `--password=` +- Set your HTTP access token as a `password` in your `config.js` file, or +- Set your HTTP access token as an environment variable `RENOVATE_PASSWORD`, or +- Set your HTTP access token when you run Renovate in the CLI with `--password=` The Gerrit user account must be allowed to assign the Code-Review label with "+2" to their own changes for "automerge" to work. @@ -51,16 +51,16 @@ For example, if you want to use the [Merge Confidence](../../../merge-confidence ```json { - "statusCheckNames": { - "mergeConfidence": "Renovate-Merge-Confidence" - } + "statusCheckNames": { + "mergeConfidence": "Renovate-Merge-Confidence" + } } ``` ## Unsupported platform features/concepts -- Creating issues (not a Gerrit concept) -- Dependency Dashboard (needs issues first) +- Creating issues (not a Gerrit concept) +- Dependency Dashboard (needs issues first) ## Known problems @@ -69,7 +69,7 @@ For example, if you want to use the [Merge Confidence](../../../merge-confidence Sometimes the PR title passed to the Gerrit platform code is different from the first line of the commit message. For example: -- Commit-Message=`Update keycloak.version to v21` -- Pull-Request-Title=`Update keycloak.version to v21 (major)` +- Commit-Message=`Update keycloak.version to v21` +- Pull-Request-Title=`Update keycloak.version to v21 (major)` In this case the Gerrit-Platform implementation tries to detect this and change the commit-message in a second patch-set. diff --git a/lib/modules/platform/gitea/readme.md b/lib/modules/platform/gitea/readme.md index 8159630fc61343..93b8f11db4ef24 100644 --- a/lib/modules/platform/gitea/readme.md +++ b/lib/modules/platform/gitea/readme.md @@ -9,9 +9,9 @@ First, [create a Personal Access Token (PAT)](https://docs.gitea.io/en-us/api-us The bot account should have full name and email address configured. Then let Renovate use your PAT by doing _one_ of the following: -- Set your PAT as a `token` in your `config.js` file -- Set your PAT as an environment variable `RENOVATE_TOKEN` -- Set your PAT when you run Renovate in the CLI with `--token=` +- Set your PAT as a `token` in your `config.js` file +- Set your PAT as an environment variable `RENOVATE_TOKEN` +- Set your PAT when you run Renovate in the CLI with `--token=` You must set `platform=gitea` in your Renovate config file. @@ -30,22 +30,22 @@ If you use Gitea packages, add the `read:packages` scope. ## Unsupported platform features/concepts -- **Adding reviewers to PRs not supported**: Gitea versions older than `v1.14.0` do not have the required API. -- **`platformAutomerge` (`true` by default) for platform-native automerge not supported**: Gitea versions older than v1.17.0 do not have the required API. -- **Git upload filters**: If you're using a Gitea version older than `v1.16.0` then you must enable [clone filters](https://docs.gitea.io/en-us/clone-filters/). +- **Adding reviewers to PRs not supported**: Gitea versions older than `v1.14.0` do not have the required API. +- **`platformAutomerge` (`true` by default) for platform-native automerge not supported**: Gitea versions older than v1.17.0 do not have the required API. +- **Git upload filters**: If you're using a Gitea version older than `v1.16.0` then you must enable [clone filters](https://docs.gitea.io/en-us/clone-filters/). ## Features awaiting implementation -- none +- none ## Repo autodiscover Renovate can discover repositories on Gitea using the `autodiscover` feature. Repositories are ignored when one of the following conditions is met: -- The repository is a `mirror` -- We do not have push or pull permissions to that repository -- Pull requests are disabled for that repository +- The repository is a `mirror` +- We do not have push or pull permissions to that repository +- Pull requests are disabled for that repository You can change the default server-side sort method and order for autodiscover API. Set those via [`autodiscoverRepoSort`](../../../self-hosted-configuration.md#autodiscoverreposort) and [`autodiscoverRepoOrder`](../../../self-hosted-configuration.md#autodiscoverrepoorder). diff --git a/lib/modules/platform/github/readme.md b/lib/modules/platform/github/readme.md index 9e0dd06b1f9dae..6313406702cfb1 100644 --- a/lib/modules/platform/github/readme.md +++ b/lib/modules/platform/github/readme.md @@ -7,9 +7,9 @@ Most of the information on this page is meant for users who want to self-host Re For users on GitHub Cloud (`github.com`), the easiest way to get started is to install [the Mend Renovate app](https://github.com/marketplace/renovate) from the GitHub marketplace. When you use the app, Mend will: -- authenticate the Renovate app to GitHub -- keep the tokens safe -- maintain and update the Renovate version used +- authenticate the Renovate app to GitHub +- keep the tokens safe +- maintain and update the Renovate version used If you self-host Renovate you must do the things listed above yourself. Self-hosting is meant for users with advanced use cases, or who want to be in full control of the bot and the environment it runs in. @@ -29,18 +29,18 @@ Read the [GitHub Docs, about Personal Access Tokens](https://docs.github.com/en/ Let Renovate use your PAT by doing _one_ of the following: -- Set your PAT as a `token` in your `config.js` file -- Set your PAT as an environment variable `RENOVATE_TOKEN` -- Set your PAT when you run Renovate in the CLI with `--token=` +- Set your PAT as a `token` in your `config.js` file +- Set your PAT as an environment variable `RENOVATE_TOKEN` +- Set your PAT when you run Renovate in the CLI with `--token=` Remember to set `platform=github` somewhere in your Renovate config file. If you use GitHub Enterprise Server then `endpoint` must point to `https://github-enterprise.example.com/api/v3/`. You can choose where you want to set `endpoint`: -- In your `config.js` file -- In a environment variable -- In a CLI parameter +- In your `config.js` file +- In a environment variable +- In a CLI parameter !!! tip "Labels and forking mode" @@ -131,11 +131,11 @@ A way to get the user id of a GitHub app is to [query the user API](https://docs When Renovate runs against repositories on `github.com`, and the environment variable `RENOVATE_X_GITHUB_HOST_RULES` is set, then Renovate automatically provisions `hostRules` for these GitHub Packages registries using the platform token: -- `ghcr.io` -- `maven.pkg.github.com` -- `npm.pkg.github.com` -- `nuget.pkg.github.com` -- `rubygems.pkg.github.com` +- `ghcr.io` +- `maven.pkg.github.com` +- `npm.pkg.github.com` +- `nuget.pkg.github.com` +- `rubygems.pkg.github.com` !!! warning @@ -143,4 +143,4 @@ When Renovate runs against repositories on `github.com`, and the environment var ## Features awaiting implementation -- The `automergeStrategy` configuration option has not been implemented for this platform, and all values behave as if the value `auto` was used. Renovate will use the merge strategy configured in the GitHub repository itself, and this cannot be overridden yet +- The `automergeStrategy` configuration option has not been implemented for this platform, and all values behave as if the value `auto` was used. Renovate will use the merge strategy configured in the GitHub repository itself, and this cannot be overridden yet diff --git a/lib/modules/platform/gitlab/readme.md b/lib/modules/platform/gitlab/readme.md index c9293f90d26b38..4af87ebaa9afa6 100644 --- a/lib/modules/platform/gitlab/readme.md +++ b/lib/modules/platform/gitlab/readme.md @@ -6,9 +6,9 @@ You can authenticate Renovate to GitLab, with a Personal Access Token, or Group To start, create either: -- a [Personal Access Token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) for the bot account -- or a [Group Access Token](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#bot-users-for-groups) for the bot account -- or a [Deploy Token](https://docs.gitlab.com/ee/user/project/deploy_tokens/index.html) for the bot account +- a [Personal Access Token](https://docs.gitlab.com/ee/user/profile/personal_access_tokens.html) for the bot account +- or a [Group Access Token](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html#bot-users-for-groups) for the bot account +- or a [Deploy Token](https://docs.gitlab.com/ee/user/project/deploy_tokens/index.html) for the bot account The bot account must have at least the Developer role in order to [create issues and merge requests](https://docs.gitlab.com/ee/user/permissions.html#project-members-permissions). If you are using automerge, the bot account must have the appropriate ["Allowed to merge" permission on the protected branch](https://docs.gitlab.com/ee/user/project/protected_branches.html#require-everyone-to-submit-merge-requests-for-a-protected-branch) of your projects. @@ -20,36 +20,36 @@ We refer to personal access tokens and group access tokens as _access tokens_ in For real runs, give the access token these scopes: -- `api` -- `write_repository` -- `read_registry` (only if Renovate needs to access the [GitLab Container registry](https://docs.gitlab.com/ee/user/packages/container_registry/)) +- `api` +- `write_repository` +- `read_registry` (only if Renovate needs to access the [GitLab Container registry](https://docs.gitlab.com/ee/user/packages/container_registry/)) For dry runs, give the access token these scopes: -- `read_api` -- `read_repository` -- `read_registry` (only if Renovate needs to access the [GitLab Container registry](https://docs.gitlab.com/ee/user/packages/container_registry/)) +- `read_api` +- `read_repository` +- `read_registry` (only if Renovate needs to access the [GitLab Container registry](https://docs.gitlab.com/ee/user/packages/container_registry/)) Let Renovate use your access token by doing _one_ of the following: -- Set your access token as a `token` in your `config.js` file -- Set your access token as an environment variable `RENOVATE_TOKEN` -- Set your access token when you run Renovate in the CLI with `--token=` +- Set your access token as a `token` in your `config.js` file +- Set your access token as an environment variable `RENOVATE_TOKEN` +- Set your access token when you run Renovate in the CLI with `--token=` Remember to set `platform=gitlab` somewhere in your Renovate config file. If you're using a private [GitLab container registry](https://docs.gitlab.com/ee/user/packages/container_registry/), you must: -- Set the `RENOVATE_HOST_RULES` CI variable to `[{"matchHost": "${CI_REGISTRY}","username": "${GITLAB_USER_NAME}","password": "${RENOVATE_TOKEN}", "hostType": "docker"}]`. -- Make sure the user that owns the access token is a member of the corresponding GitLab projects/groups with the right permissions. -- Make sure the access token has the `read_registry` scope. +- Set the `RENOVATE_HOST_RULES` CI variable to `[{"matchHost": "${CI_REGISTRY}","username": "${GITLAB_USER_NAME}","password": "${RENOVATE_TOKEN}", "hostType": "docker"}]`. +- Make sure the user that owns the access token is a member of the corresponding GitLab projects/groups with the right permissions. +- Make sure the access token has the `read_registry` scope. You may want to set `FORCE_COLOR: 3` or `TERM: ansi` to the job, in order to get colored output. [GitLab Runner runs the container’s shell in non-interactive mode, so the shell’s `TERM` environment variable is set to `dumb`.](https://docs.gitlab.com/ee/ci/yaml/script.html#job-log-output-is-not-formatted-as-expected-or-contains-unexpected-characters) ## Features awaiting implementation -- The `automergeStrategy` configuration option has not been implemented for this platform, and all values behave as if the value `auto` was used. Renovate will accept the Merge Request without further configuration, and respect the strategy defined in the Merge Request, and this cannot be overridden yet +- The `automergeStrategy` configuration option has not been implemented for this platform, and all values behave as if the value `auto` was used. Renovate will accept the Merge Request without further configuration, and respect the strategy defined in the Merge Request, and this cannot be overridden yet ## Server version dependent features @@ -57,9 +57,9 @@ We use the GitLab [version API](https://docs.gitlab.com/ee/api/version.html) to You can use the experimental feature flag [`RENOVATE_X_PLATFORM_VERSION`](../../../self-hosted-experimental.md#renovate_x_platform_version) to set a specific server version. By setting the server version yourself, you save a API call that fetches the server version. -- Use `Draft:` MR prefix instead of `WIP:` prefix since `v13.2.0` -- Do not truncate Markdown body to 25K chars since `v13.4.0` -- Allow configure reviewers since `v13.9.0` +- Use `Draft:` MR prefix instead of `WIP:` prefix since `v13.2.0` +- Do not truncate Markdown body to 25K chars since `v13.4.0` +- Allow configure reviewers since `v13.9.0` ## Multiple merge request assignees diff --git a/lib/modules/platform/local/readme.md b/lib/modules/platform/local/readme.md index 15ede0932e21cb..9d95d5228dcd30 100644 --- a/lib/modules/platform/local/readme.md +++ b/lib/modules/platform/local/readme.md @@ -17,6 +17,6 @@ The command doesn't do any "compare" - or before and after analysis - if you wan ## Limitations -- `local>` presets can't be resolved. Normally these would point to the local platform such as GitHub, but in the case of running locally, it does not exist -- `baseBranches` are ignored -- Branch creation is not supported +- `local>` presets can't be resolved. Normally these would point to the local platform such as GitHub, but in the case of running locally, it does not exist +- `baseBranches` are ignored +- Branch creation is not supported diff --git a/lib/modules/versioning/docker/readme.md b/lib/modules/versioning/docker/readme.md index 8f68eab33ac416..2e664b6e2b84a2 100644 --- a/lib/modules/versioning/docker/readme.md +++ b/lib/modules/versioning/docker/readme.md @@ -22,13 +22,13 @@ For example: ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNames": ["badly-versioned-docker-image"], - "versioning": "loose" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNames": ["badly-versioned-docker-image"], + "versioning": "loose" + } + ] } ``` diff --git a/lib/modules/versioning/go-mod-directive/readme.md b/lib/modules/versioning/go-mod-directive/readme.md index b78971a20b8463..e6aaf88ba84339 100644 --- a/lib/modules/versioning/go-mod-directive/readme.md +++ b/lib/modules/versioning/go-mod-directive/readme.md @@ -7,11 +7,11 @@ If you wish to upgrade this value every time there's a new minor Go release, con ```json { - "packageRules": [ - { - "matchDatasources": ["golang-version"], - "rangeStrategy": "bump" - } - ] + "packageRules": [ + { + "matchDatasources": ["golang-version"], + "rangeStrategy": "bump" + } + ] } ``` diff --git a/lib/modules/versioning/nixpkgs/readme.md b/lib/modules/versioning/nixpkgs/readme.md index 5ab8950324b868..4d5bd49d4cbf12 100644 --- a/lib/modules/versioning/nixpkgs/readme.md +++ b/lib/modules/versioning/nixpkgs/readme.md @@ -4,14 +4,14 @@ NixOS releases follow the `YY.MM` pattern. There are also some prefixes and suffixes allowed. Using `22.05` as an example the allowed combination of prefixes and suffixes are: -- `release-22.05` -- `nixos-22.05` -- `nixos-22.05-small` -- `nixos-22.05-aarch64` -- `nixpkgs-22.05-darwin` +- `release-22.05` +- `nixos-22.05` +- `nixos-22.05-small` +- `nixos-22.05-aarch64` +- `nixpkgs-22.05-darwin` Additionally, there are some floating versions: -- `nixos-unstable` -- `nixos-unstable-small` -- `nixpkgs-unstable` +- `nixos-unstable` +- `nixos-unstable-small` +- `nixpkgs-unstable` diff --git a/lib/modules/versioning/node/readme.md b/lib/modules/versioning/node/readme.md index 678c9d36f68f8a..88eaefb5d0e122 100644 --- a/lib/modules/versioning/node/readme.md +++ b/lib/modules/versioning/node/readme.md @@ -3,8 +3,8 @@ But Renovate removes any `v` prefixes from semantic versions when replacing. Its primary purpose is to add Node.js LTS awareness, e.g.: -- Odd releases are unstable -- Even releases do not reach stability (LTS) immediately +- Odd releases are unstable +- Even releases do not reach stability (LTS) immediately You can _not_ use `node` versioning to replace `docker` versioning if you are using node tags with suffixes like `-alpine`. This is because npm versioning treats these suffixes as implying pre-releases/instability. diff --git a/lib/modules/versioning/redhat/readme.md b/lib/modules/versioning/redhat/readme.md index feb19d36bc2e4c..ad3f9ea968013b 100644 --- a/lib/modules/versioning/redhat/readme.md +++ b/lib/modules/versioning/redhat/readme.md @@ -2,15 +2,15 @@ Red Hat versioning is used with container images that are maintained by Red Hat. Red Hat version definitions follow this pattern: -- the version of the main component, where major is required, but minor and patch are optional -- optionally a hyphen followed by release information -- the version of Red Hat's release as an integer, optionally followed by a timestamp like: `1645808164` +- the version of the main component, where major is required, but minor and patch are optional +- optionally a hyphen followed by release information +- the version of Red Hat's release as an integer, optionally followed by a timestamp like: `1645808164` Examples of valid Red Hat versions: -- `1` -- `8.5` -- `7.9-628` -- `9.0.0-19.1655192132` +- `1` +- `8.5` +- `7.9-628` +- `9.0.0-19.1655192132` Ranges are not supported by this versioning. diff --git a/lib/modules/versioning/regex/readme.md b/lib/modules/versioning/regex/readme.md index b8512e5c95ef55..aeb3d4af223412 100644 --- a/lib/modules/versioning/regex/readme.md +++ b/lib/modules/versioning/regex/readme.md @@ -3,11 +3,11 @@ Regular Expression Versioning is designed to be a flexible fallback versioning a The `regex` scheme makes use of Regular Express capture groups. The valid capture groups for `regex` versioning are: -- `major`, `minor`, and `patch`: at least one of these must be provided. When determining whether a package has updates, these values will be compared in the standard semantic versioning fashion. If any of these fields are omitted, they will be treated as if they were `0` -- in this way, you can describe versioning schemes with up to three incrementing values. -- `build`: this capture group can be used after you've already used the `major`, `minor` and `patch` capture groups and need a fourth version part. `build` updates are handled like `patch` updates. -- `revision`: this capture group can be used after you've already used the `build` capture groups and need a fifth version part. `revision` updates are handled like `patch` updates. -- `prerelease`: this value, if captured, will mark a given release as a prerelease (e.g. unstable). If this value is captured and you have configured `"ignoreUnstable": true`, the given release will be skipped. -- `compatibility`: this value defines the "build compatibility" of a given dependency. A proposed Renovate update will never change the specified compatibility value. For example, if you are pinning to `1.2.3-linux` (and `linux` is captured as the compatibility value), Renovate will not update you to `1.2.4-osx`. +- `major`, `minor`, and `patch`: at least one of these must be provided. When determining whether a package has updates, these values will be compared in the standard semantic versioning fashion. If any of these fields are omitted, they will be treated as if they were `0` -- in this way, you can describe versioning schemes with up to three incrementing values. +- `build`: this capture group can be used after you've already used the `major`, `minor` and `patch` capture groups and need a fourth version part. `build` updates are handled like `patch` updates. +- `revision`: this capture group can be used after you've already used the `build` capture groups and need a fifth version part. `revision` updates are handled like `patch` updates. +- `prerelease`: this value, if captured, will mark a given release as a prerelease (e.g. unstable). If this value is captured and you have configured `"ignoreUnstable": true`, the given release will be skipped. +- `compatibility`: this value defines the "build compatibility" of a given dependency. A proposed Renovate update will never change the specified compatibility value. For example, if you are pinning to `1.2.3-linux` (and `linux` is captured as the compatibility value), Renovate will not update you to `1.2.4-osx`. The compatibility concept was originally introduced for Docker versioning but sometimes package authors may use/misuse suffixes to mean compatibility in other versioning schemes. @@ -15,12 +15,12 @@ Here is an example of using `regex` versioning to correct behavior of the `guava ```json { - "packageRules": [ - { - "matchPackageNames": ["com.google.guava:guava"], - "versioning": "regex:^(?\\d+)(\\.(?\\d+))?(\\.(?\\d+))?(-(?.*))?$" - } - ] + "packageRules": [ + { + "matchPackageNames": ["com.google.guava:guava"], + "versioning": "regex:^(?\\d+)(\\.(?\\d+))?(\\.(?\\d+))?(-(?.*))?$" + } + ] } ``` @@ -28,13 +28,13 @@ Here is another example, this time for handling `python` Docker images, which us ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNames": ["python"], - "versioning": "regex:^(?\\d+)\\.(?\\d+)\\.(?\\d+)(?[^.-]+)?(-(?.*))?$" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNames": ["python"], + "versioning": "regex:^(?\\d+)\\.(?\\d+)\\.(?\\d+)(?[^.-]+)?(-(?.*))?$" + } + ] } ``` @@ -42,12 +42,12 @@ Here is another example, this time for handling Bitnami Docker images, which use ```json { - "packageRules": [ - { - "matchDatasources": ["docker"], - "matchPackageNamees": ["bitnami/**", "docker.io/bitnami/**"], - "versioning": "regex:^(?\\d+)\\.(?\\d+)\\.(?\\d+)(?:-(?.+)(?\\d+)-r(?\\d+))?$" - } - ] + "packageRules": [ + { + "matchDatasources": ["docker"], + "matchPackageNamees": ["bitnami/**", "docker.io/bitnami/**"], + "versioning": "regex:^(?\\d+)\\.(?\\d+)\\.(?\\d+)(?:-(?.+)(?\\d+)-r(?\\d+))?$" + } + ] } ``` diff --git a/lib/modules/versioning/same-major/readme.md b/lib/modules/versioning/same-major/readme.md index 5a95fe4634d917..dcce820183a3ee 100644 --- a/lib/modules/versioning/same-major/readme.md +++ b/lib/modules/versioning/same-major/readme.md @@ -11,10 +11,10 @@ For example: ```json { - "sdk": { - "version": "6.0.300", - "rollForward": "major" - } + "sdk": { + "version": "6.0.300", + "rollForward": "major" + } } ``` diff --git a/lib/modules/versioning/unity3d/readme.md b/lib/modules/versioning/unity3d/readme.md index 537f80fc6123ed..c4cc99f2fb3c89 100644 --- a/lib/modules/versioning/unity3d/readme.md +++ b/lib/modules/versioning/unity3d/readme.md @@ -1,13 +1,13 @@ Unity versioning follow semantic versioning, followed by a letter, number and an optional hash: -- Major version is the year of release -- Minor and patch version are incremental, starting at 0 -- The letter denotes a stream (**a**lpha, **b**eta, **f**inal release, etc.) -- The number is a growing index -- The hash is calculated by Unity internally and irrelevant for comparision +- Major version is the year of release +- Minor and patch version are incremental, starting at 0 +- The letter denotes a stream (**a**lpha, **b**eta, **f**inal release, etc.) +- The number is a growing index +- The hash is calculated by Unity internally and irrelevant for comparision Examples: -- `2023.2.10f1 (316c1fd686f6)` -- `2023.3.0a17` -- `2023.3.0b4 (2cd31b2a2ee2)` +- `2023.2.10f1 (316c1fd686f6)` +- `2023.3.0a17` +- `2023.3.0b4 (2cd31b2a2ee2)` diff --git a/lib/util/cache/repository/impl/readme.md b/lib/util/cache/repository/impl/readme.md index ec968323a3e24d..8384e1bda7d769 100644 --- a/lib/util/cache/repository/impl/readme.md +++ b/lib/util/cache/repository/impl/readme.md @@ -6,11 +6,11 @@ Suppose you have data: ```json { - "fingerprint": "0123456789abcdef", - "hash": "756a22cbd28854a64687fa5e458eb1da5b51958d7b329094f4a152dc4dc533dd26213f97fdc10f2480784aa667382ef671d820c1625bb694542a99f8a709be45", - "payload": "Gx0A8EVPlvpLVKVkJggn0ExJYlEsqcMErTZdm8wdCOAB", - "repository": "some/repo", - "revision": 13 + "fingerprint": "0123456789abcdef", + "hash": "756a22cbd28854a64687fa5e458eb1da5b51958d7b329094f4a152dc4dc533dd26213f97fdc10f2480784aa667382ef671d820c1625bb694542a99f8a709be45", + "payload": "Gx0A8EVPlvpLVKVkJggn0ExJYlEsqcMErTZdm8wdCOAB", + "repository": "some/repo", + "revision": 13 } ``` diff --git a/lib/util/github/graphql/readme.md b/lib/util/github/graphql/readme.md index c775afd6bb941d..95f0f27709dfa9 100644 --- a/lib/util/github/graphql/readme.md +++ b/lib/util/github/graphql/readme.md @@ -32,12 +32,12 @@ The datasource-fetcher.ts file contains the core component that implements the l This class is meant to be instantiated every time we need to paginate over GraphQL results. It is responsible for handling several aspects of the fetch process, including: -- Making HTTP requests to the `/graphql` endpoint -- Handling and aggregating errors that may occur during the fetch process -- Dynamically adjusting the page size and retrying in the event of server errors -- Enforcing a maximum limit on the number of queries that can be made -- Detecting whether a package is private or public, and selecting the right cache strategy (in-memory or long-term) accordingly -- Ensuring proper concurrency when querying the same package simultaneously. +- Making HTTP requests to the `/graphql` endpoint +- Handling and aggregating errors that may occur during the fetch process +- Dynamically adjusting the page size and retrying in the event of server errors +- Enforcing a maximum limit on the number of queries that can be made +- Detecting whether a package is private or public, and selecting the right cache strategy (in-memory or long-term) accordingly +- Ensuring proper concurrency when querying the same package simultaneously. The `cache-strategies/` directory is responsible for caching implementation. The core function is `reconcile()` which updates the cache data structure with pages of items one-by-one. diff --git a/readme.md b/readme.md index e4449bf34b0b70..ccd596f6583eff 100644 --- a/readme.md +++ b/readme.md @@ -14,32 +14,32 @@ Multi-platform and multi-language. ## Why Use Renovate? -- Get automated Pull Requests to update your dependencies -- Reduce noise by running Renovate on a schedule, for example: - - on weekends - - outside of working hours - - each week - - each month -- Relevant package files are discovered automatically -- Supports monorepo architectures with workspaces with no extra configuration -- Bot behavior is customizable via configuration files (config as code) -- Use ESLint-like shared config presets for ease of use and simplifying configuration (JSON format only) -- Lock files are supported and updated in the same commit, including immediately resolving conflicts whenever PRs are merged -- Get replacement PRs to migrate from a deprecated dependency to the community suggested replacement, works with _most_ managers, see [issue 14149](https://github.com/renovatebot/renovate/issues/14149) for exceptions -- Open source (installable via npm/Yarn or Docker Hub) so can be self-hosted or used via the Mend Renovate App +- Get automated Pull Requests to update your dependencies +- Reduce noise by running Renovate on a schedule, for example: + - on weekends + - outside of working hours + - each week + - each month +- Relevant package files are discovered automatically +- Supports monorepo architectures with workspaces with no extra configuration +- Bot behavior is customizable via configuration files (config as code) +- Use ESLint-like shared config presets for ease of use and simplifying configuration (JSON format only) +- Lock files are supported and updated in the same commit, including immediately resolving conflicts whenever PRs are merged +- Get replacement PRs to migrate from a deprecated dependency to the community suggested replacement, works with _most_ managers, see [issue 14149](https://github.com/renovatebot/renovate/issues/14149) for exceptions +- Open source (installable via npm/Yarn or Docker Hub) so can be self-hosted or used via the Mend Renovate App ## Supported Platforms Renovate works on these platforms: -- [GitHub (.com and Enterprise Server)](https://docs.renovatebot.com/modules/platform/github/) -- [GitLab (.com and CE/EE)](https://docs.renovatebot.com/modules/platform/gitlab/) -- [Bitbucket Cloud](https://docs.renovatebot.com/modules/platform/bitbucket/) -- [Bitbucket Server](https://docs.renovatebot.com/modules/platform/bitbucket-server/) -- [Azure DevOps](https://docs.renovatebot.com/modules/platform/azure/) -- [AWS CodeCommit](https://docs.renovatebot.com/modules/platform/codecommit/) -- [Gitea and Forgejo](https://docs.renovatebot.com/modules/platform/gitea/) -- [Gerrit (experimental)](https://docs.renovatebot.com/modules/platform/gerrit/) +- [GitHub (.com and Enterprise Server)](https://docs.renovatebot.com/modules/platform/github/) +- [GitLab (.com and CE/EE)](https://docs.renovatebot.com/modules/platform/gitlab/) +- [Bitbucket Cloud](https://docs.renovatebot.com/modules/platform/bitbucket/) +- [Bitbucket Server](https://docs.renovatebot.com/modules/platform/bitbucket-server/) +- [Azure DevOps](https://docs.renovatebot.com/modules/platform/azure/) +- [AWS CodeCommit](https://docs.renovatebot.com/modules/platform/codecommit/) +- [Gitea and Forgejo](https://docs.renovatebot.com/modules/platform/gitea/) +- [Gerrit (experimental)](https://docs.renovatebot.com/modules/platform/gerrit/) ## Who Uses Renovate? @@ -50,26 +50,26 @@ Renovate is widely used in the developer community:
List of companies and projects that use Renovate -- Prisma -- Netlify -- Envoy -- Condé Nast -- Microsoft -- Atlassian -- Sourcegraph -- Mozilla -- Deloitte -- Telus -- Yarn -- HashiCorp -- Automattic -- Algolia -- eBay -- Cypress -- Red Hat -- Financial Times -- Uber -- Buildkite +- Prisma +- Netlify +- Envoy +- Condé Nast +- Microsoft +- Atlassian +- Sourcegraph +- Mozilla +- Deloitte +- Telus +- Yarn +- HashiCorp +- Automattic +- Algolia +- eBay +- Cypress +- Red Hat +- Financial Times +- Uber +- Buildkite
@@ -87,9 +87,9 @@ Information about our contributors and community can be found on [OSS Insight](h We believe everyone benefits from automation, whether it's a little or a lot. This means that Renovate: -- Adapts to your workflow -- Allows you to configure its behavior -- Will autodetect settings where possible +- Adapts to your workflow +- Allows you to configure its behavior +- Will autodetect settings where possible ## Using Renovate @@ -105,8 +105,8 @@ Install [the Mend Renovate App](https://github.com/apps/renovate) now. There are two ways to run Renovate on Azure DevOps: -- Renovate Me extension -- Custom pipeline +- Renovate Me extension +- Custom pipeline #### Renovate Me extension @@ -136,9 +136,9 @@ To get help with your configuration, go to the [discussions tab in the Renovate To run your own instance of Renovate you have several options: -- Install the `renovate` CLI tool from npmjs, run it on a schedule (e.g. using `cron`) -- Run the `renovate/renovate:full` Docker Hub image (same content/versions as the CLI tool), run it on a schedule -- Run the `renovate/renovate:latest` Docker Hub image if you only use package managers that don't need third-party binaries (e.g. JavaScript, Docker, NuGet, pip) +- Install the `renovate` CLI tool from npmjs, run it on a schedule (e.g. using `cron`) +- Run the `renovate/renovate:full` Docker Hub image (same content/versions as the CLI tool), run it on a schedule +- Run the `renovate/renovate:latest` Docker Hub image if you only use package managers that don't need third-party binaries (e.g. JavaScript, Docker, NuGet, pip) [More details on the self-hosting development](https://github.com/renovatebot/renovate/blob/main/docs/usage/getting-started/running.md).