Merge branch 'main' into fix-postUpdateOptions

.devcontainer/Dockerfile

@@ -1,4 +1,4 @@
-FROM containerbase/node:14.17.5@sha256:fe63fe8dd0663fce4ae987697854f7514af1711f7717539cc0b43d33feef795b
+FROM containerbase/node:14.17.5@sha256:3fce5dfc917107aca3cf3823a42ffae92a4bb433a55aa1f5be5f7caeb0019b20
 
 
 # renovate: datasource=npm

.github/workflows/build.yml

@@ -57,7 +57,7 @@ jobs:
 
       - name: Set up Java  ${{ env.JAVA_VERSION }}
         if: env.NODE_VERSION == '14'
-        uses: actions/setup-java@4b1b3d4a82f726de9ba1945f8c6967b67caf5dcd # renovate: tag=v2.2.0
+        uses: actions/setup-java@3bc31aaf88e8fc94dc1e632d48af61be5ca8721c # renovate: tag=v2.3.0
         with:
           java-version: ${{ env.JAVA_VERSION }}
           distribution: 'adopt'

.vscode/launch.json

@@ -6,7 +6,9 @@
       "request": "launch",
       "name": "debug",
       "program": "${workspaceFolder}/lib/renovate.ts",
-      "env": { "LOG_LEVEL": "debug" },
+      "env": {
+        "LOG_LEVEL": "debug"
+      },
       "console": "integratedTerminal",
       "runtimeArgs": ["-r", "ts-node/register/transpile-only"],
       "protocol": "inspector",
@@ -23,7 +25,10 @@
         "--runTestsByPath",
         "${relativeFile}"
       ],
-      "env": { "NODE_ENV": "test", "LOG_LEVEL": "debug" },
+      "env": {
+        "NODE_ENV": "test",
+        "LOG_LEVEL": "debug"
+      },
       "console": "integratedTerminal",
       "windows": {
         "program": "${workspaceFolder}/node_modules/jest/bin/jest"
@@ -38,14 +43,28 @@
       "name": "Jest All",
       "program": "${workspaceFolder}/node_modules/.bin/jest",
       "args": ["--runInBand", "--collectCoverage=false"],
-      "env": { "NODE_ENV": "test", "LOG_LEVEL": "debug" },
+      "env": {
+        "NODE_ENV": "test",
+        "LOG_LEVEL": "debug"
+      },
       "console": "integratedTerminal",
       "windows": {
         "program": "${workspaceFolder}/node_modules/jest/bin/jest"
       },
       "runtimeArgs": ["--preserve-symlinks"],
       "protocol": "inspector",
       "skipFiles": ["<node_internals>/**/*.js"]
+    },
+    {
+      "type": "node",
+      "name": "vscode-jest-tests",
+      "request": "launch",
+      "console": "integratedTerminal",
+      "internalConsoleOptions": "neverOpen",
+      "disableOptimisticBPs": true,
+      "cwd": "${workspaceFolder}",
+      "runtimeExecutable": "yarn",
+      "args": ["jest", "--runInBand", "--watchAll=false"]
     }
   ]
 }

.vscode/settings.json

@@ -12,5 +12,7 @@
     "Dockerfile.*": "dockerfile",
     ".releaserc": "json"
   },
-  "omnisharp.autoStart": false
+  "omnisharp.autoStart": false,
+  "jest.autoRun": "off",
+  "jest.jestCommandLine": "yarn jest"
 }

docs/development/triage-guide.md

@@ -32,7 +32,7 @@ In general try to make a good-faith effort to label things correctly.
 
 ### Closing issues
 
-You can close a issue yourself if it's:
+You can close an issue yourself if it's:
 
 - Spam
 - Obviously fixed
@@ -45,15 +45,15 @@ It's not very often that you'll need to close a PR, but you can certainly do it
 
 ### Reopen issues
 
-Sometimes a bug is fixed with a PR that links to a issue.
+Sometimes a bug is fixed with a PR that links to an issue.
 When the PR is merged, the issue is automatically closed.
 Sometimes the bug was not really fixed, and someone says: "Hey this is still broken for me."
 In that case, re-open the issue only if it's definitely the same problem (users often associate different problems together incorrectly).
 Otherwise, ask the user to open a new issue if it seems like it is different.
 
 ### Assign issues
 
-You can assign a issue to yourself, so that others know you're going to work on the issue.
+You can assign an issue to yourself, so that others know you're 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, so you can also assign in either of those cases if it makes sense.
 
 ### Mark duplicate issues and pull requests
@@ -77,8 +77,8 @@ In those cases you can lock the discussion to prevent further escalation.
 
 ### Individually convert issues to discussions
 
-Sometimes a issue that's raised at the Renovate repository is not really a bug or a feature request.
-This happens most often because a user files a bug for things that are really a misstake in the Renovate configuration.
+Sometimes an issue that's raised at the Renovate repository is not really a bug or a feature request.
+This happens most often because a user files a bug for things that are really a mistake in the Renovate configuration.
 Those "configuration help" issues are then moved to the discussions board for further help.
 
 ### Moving issues from `status:requirements` to `status:ready`

docs/usage/config-presets.md

@@ -149,6 +149,8 @@ You do not need to add it as a devDependency or add any other files to the prese
 It is also possible to host your preset config using just a regular GitLab repository and without needing to publish it to npmjs.
 In such cases Renovate will simply look for a `default.json` file in the default branch.
 
+For a private GitLab repository Renovate requires at least _Reporter_ level access.
+
 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
@@ -182,6 +184,8 @@ But you also probably want the preset to be private too, so how can the other re
 The answer is to host your preset using GitHub or GitLab - not npmjs - and make sure you have added the preset's repo to Renovate too.
 GitHub will then allow Renovate to access the preset repo whenever it is processing any other repos within the same account/org.
 
+For a private GitLab repository Renovate requires at least _Reporter_ level access.
+
 ## Contributing to presets
 
 Have you configured a rule that you think others might benefit from?

docs/usage/configuration-options.md

@@ -357,6 +357,22 @@ Usually left empty except for internal use (multiple base branches, and vulnerab
 This is used to alter `commitMessage` and `prTitle` without needing to copy/paste the whole string.
 The "topic" is usually refers to the dependency being updated, e.g. `"dependency react"`.
 
+## composerIgnorePlatformReqs
+
+By default, Renovate will run Composer with `--ignore-platform-reqs` as the PHP platform used by Renovate most probably won't match with the required PHP environment of your project as configured in your `composer.json` file.
+However, this also means that all platform constraints (including PHP version) will be ignored by default, which can result in updated dependencies that are not compatible with your platform.
+
+To solve this, you should configure explicit ignored platform requirements (for example `ext-zip`) by setting them separately in this array.
+Each item will be added to the Composer command with `--ignore-platform-req`, resulting in it being ignored during its invocation.
+Note that this requires your project to use Composer V2, as V1 doesn't support excluding single platform requirements.
+The used PHP version will be guessed automatically from your `composer.json` definition, so `php` should not be added as explicit dependency.
+
+If an empty array is configured, Renovate uses its default behaviour.
+
+Set to `null` (not recommended) to fully omit `--ignore-platform-reqs/--ignore-platform-req` during Composer invocation.
+This requires the Renovate image to be fully compatible with your Composer platform requirements in order for the Composer invocation to succeed, otherwise Renovate will fail to create the updated lock file.
+The Composer output should inform you about the reasons the update failed.
+
 ## configWarningReuseIssue
 
 Renovate's default behavior is to reuse/reopen a single Config Warning issue in each repository so as to keep the "noise" down.
@@ -402,6 +418,16 @@ This option applies only to the `gradle` manager.
 
 ## dependencyDashboard
 
+Starting from version `v26.0.0` the "Dependency Dashboard" is enabled by default as part of the commonly-used `config:base` preset.
+
+To disable the Dependency Dashboard, add the preset `:disableDependencyDashboard` or set `dependencyDashboard` to `false`.
+
+```json
+{
+  "extends": ["config:base", ":disableDependencyDashboard"]
+}
+```
+
 Configuring `dependencyDashboard` to `true` will lead to the creation of a "Dependency Dashboard" issue within the repository.
 This issue contains a list of all PRs pending, open, closed (unmerged) or in error.
 The goal of this issue is to give visibility into all updates that Renovate is managing.
@@ -423,7 +449,7 @@ This feature allows you to use Renovate's Dependency Dashboard to force approval
 By setting `dependencyDashboardApproval` to `true` in config (including within `packageRules`), you can tell Renovate to wait for your approval from the Dependency Dashboard before creating a branch/PR.
 You can approve a pending PR by ticking the checkbox in the Dependency Dashboard issue.
 
-Note: When you set `dependencyDashboardApproval` to `true` the Dependency Dashboard issue will be created automatically, you do not need to turn on `dependencyDashboard` explictly.
+Note: When you set `dependencyDashboardApproval` to `true` the Dependency Dashboard issue will be created automatically, you do not need to turn on `dependencyDashboard` explicitly.
 
 You can configure Renovate to wait for approval for:
 

docs/usage/docker.md

@@ -227,7 +227,7 @@ To get access to the token a custom Renovate Docker image is needed that include
 The Dockerfile to create such an image can look like this:
 
 ```Dockerfile
-FROM renovate/renovate:25.75.0
+FROM renovate/renovate:26.4.2
 # Include the "Docker tip" which you can find here https://cloud.google.com/sdk/docs/install
 # under "Installation" for "Debian/Ubuntu"
 RUN ...

docs/usage/faq.md

@@ -46,7 +46,7 @@ If you're self hosting Renovate, use the latest release if possible.
 | Dependency Dashboard | BitBucket, BitBucket Server, Azure                | [#9592](https://github.com/renovatebot/renovate/issues/9592) |
 | Hosted app           | GitLab, BitBucket, BitBucket Server, Azure, Gitea |                                                              |
 
-## Major platform features not suported by Renovate
+## Major platform features not supported by Renovate
 
 Some major platform features are not supported at all by Renovate.
 

docs/usage/getting-started/installing-onboarding.md

@@ -4,7 +4,7 @@
 
 Renovate administrators can configure Renovate to either "autodiscover" installed repositories, or configure a fixed list of repository names to operate on.
 
-If the adminstrator has configured a fixed list of repositories then the only way to "install" Renovate on an additional repository is for it to be manually added for the next run or restart.
+If the administrator has configured a fixed list of repositories then the only way to "install" Renovate on an additional repository is for it to be manually added for the next run or restart.
 
 Otherwise, the process for adding new repositories to a Renovate installation can vary:
 
@@ -81,7 +81,7 @@ The configuration in your `package.json` will apply to the whole project (this i
 ### Customised defaults
 
 Renovate provides a `renovate.json` file, with default settings that will work for most cases.
-Sometimes Renovate detects that a override to these defaults is needed, and will add this override automatically, such as:
+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)

docs/usage/getting-started/private-packages.md

@@ -96,7 +96,7 @@ 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, it might be better to create a "empty" account just for this purpose.
+- Create a read-only Personal Access Token (PAT) for a `github.com` account. This can be any GitHub account, it might be better to create an "empty" account just for this purpose.
 - Add the PAT to Renovate using the environment variable `GITHUB_COM_TOKEN`
 
 ## Package Manager Credentials for Artifact Updating

docs/usage/getting-started/running.md

@@ -64,7 +64,7 @@ It is built similarly to the "full" Renovate image described above, but with the
 - 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 a end-user license agreement (EULA) and not the Affero General Public License (AGPL)
+- It's licensed using an end-user license agreement (EULA) and not the Affero General Public License (AGPL)
 
 WSOP supports GitHub (both `github.com` and GitHub Enterprise Server) as well as GitLab self-hosted.
 Documentation can be found in its public GitHub repository [`whitesource/renovate-on-prem`](https://github.com/whitesource/renovate-on-prem).
@@ -191,7 +191,7 @@ Don't forget to configure `platform=azure` somewhere in config.
 
 #### Gitea
 
-First, [create a access token](https://docs.gitea.io/en-us/api-usage/#authentication-via-the-api) for your bot account.
+First, [create an access token](https://docs.gitea.io/en-us/api-usage/#authentication-via-the-api) for your bot account.
 Configure it as `token` in your `config.js` file, or in environment variable `RENOVATE_TOKEN`, or via CLI `--token=`.
 Don't forget to configure `platform=gitea` somewhere in config.
 

docs/usage/golang.md

@@ -52,4 +52,4 @@ As an example, say you want Renovate to use the latest patch version of the `1.1
 ```
 
 We do not support patch level versions for the minimum `go` version.
-This means you cannot use `go 1.16.6`, but you can use `go 1.16` as a contraint.
+This means you cannot use `go 1.16.6`, but you can use `go 1.16` as a constraint.

docs/usage/key-concepts/dashboard.md

@@ -5,10 +5,10 @@ description: Learn all about Renovate's Dependency Dashboard
 
 # Introduction
 
-Renovate has a Dependency Dashboard that shows a overview of the state of your repositories' dependencies.
+Renovate has a Dependency Dashboard that shows an overview of the state of your repositories' dependencies.
 
 When the Dependency Dashboard is enabled, Renovate will create a new issue in the repository.
-This issue contains a "dashboard" where you can get a overview of the status of all updates.
+This issue contains a "dashboard" where you can get an overview of the status of all updates.
 
 Having the Dependency Dashboard also enables the concept of an "approval" workflow for new upgrades, either for selected dependencies (recommended) or even for all.
 
@@ -51,14 +51,14 @@ This section explains some common use cases where having the Dependency Dashboar
 
 ### Visibility into rejected/deferred updates
 
-Renovate's Dependency Dashboard shows a overview of all updates that are still "to do".
+Renovate's Dependency Dashboard shows an overview of all updates that are still "to do".
 
 If you close an update PR from Renovate without merging, the Dashboard will list this update in the Closed/Ignored section.
 If you later change your mind about the update, you can get a new PR by clicking the corresponding checkbox on the dashboard.
 
 ### Dependency Dashboard Approval workflow
 
-Sometimes you want Renovate to wait for your approval before creating a update PR.
+Sometimes you want Renovate to wait for your approval before creating an update PR.
 You can customize this "wait for approval" behavior however you like best.
 
 At a high level the options are:

docs/usage/modules/versioning.md

@@ -12,12 +12,12 @@ It's impossible to automatically detect **all** versioning schemes, so sometimes
 You can manually configure/override the `versioning` value for a particular dependency.
 You generally won't need to override the defaults for ecosystems which enforce a strict version scheme like `npm`.
 
-Configuring or overriding the default `versionScheme` can be particularly helpful for ecosystems like Docker/Kubernetes/Helm, where versioning is barely a "convention".
+Configuring or overriding the default `versioning` can be particularly helpful for ecosystems like Docker/Kubernetes/Helm, where versioning is barely a "convention".
 
 ## General concepts behind overriding versioning
 
 - Although you can reconfigure versioning per-manager or per-datasource, it's unlikely that such a broad change would ever be needed
-- More commonly you would need to configure `versionScheme` for individual packages or potentially package patterns
+- 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`, `matchPackageNames` and `matchPackagePatterns`
 
 ## Examples of versioning overrides
@@ -45,7 +45,7 @@ The configuration below overrides Renovate's default `docker` versioning for the
   "packageRules": [
     {
       "matchPackageNames": ["foo/bar"],
-      "versionScheme": "regex:^(?<compatibility>.*)-v?(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)?$"
+      "versioning": "regex:^(?<compatibility>.*)-v?(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)?$"
     }
   ]
 }

docs/usage/noise-reduction.md

@@ -101,6 +101,7 @@ Or perhaps at least weekly:
 If you're wondering what is supported and not, under the hood, the schedule is parsed using [@breejs/later](https://github.com/breejs/later) using the `later.parse.text(scheduleString)` API.
 Read the parser documentation at [breejs.github.io/later/parsers.html#text](https://breejs.github.io/later/parsers.html#text).
 Renovate does not support scheduled minutes or "at an exact time" granularity.
+Granularity must be at least one hour.
 
 ## Automerging
 

docs/usage/self-hosted-configuration.md

@@ -126,10 +126,6 @@ e.g.
 }
 ```
 
-## composerIgnorePlatformReqs
-
-Set to `false` to prevent usage of `--ignore-platform-reqs` in the Composer package manager.s
-
 ## customEnvVariables
 
 This configuration will be applied after all other environment variables so that it can be used to override defaults.
@@ -238,6 +234,17 @@ Before the first commit in a repository, Renovate will:
 The `git` commands are run locally in the cloned repo instead of globally.
 This reduces the chance of unintended consequences with global Git configs on shared systems.
 
+## gitUrl
+
+Override the default resolution for Git remote, e.g. to switch GitLab from HTTPS to SSH-based.
+Currently works for 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
+
 ## logContext
 
 `logContext` is included with each log entry only if `logFormat="json"` - it is not included in the pretty log output.
@@ -407,7 +414,7 @@ It could then be used in a repository config or preset like so:
 }
 ```
 
-Secret names must start with a upper or lower case character and can contain only characters, digits, or underscores.
+Secret names must start with an upper or lower case character and can contain only characters, digits, or underscores.
 
 ## skipInstalls