Merge branch 'main' into implement-custom-headers-2

.devcontainer/Dockerfile

@@ -1 +1 @@
-FROM ghcr.io/containerbase/devcontainer:9.30.0
+FROM ghcr.io/containerbase/devcontainer:9.30.6

.github/actions/setup-node/action.yml

@@ -52,7 +52,7 @@ runs:
  run: corepack enable
 
  - name: Setup Node
- uses: actions/setup-node@8f152de45cc393bb48ce5d89d36b731f54556e65 # v4.0.0
+ uses: actions/setup-node@b39b52d1213e96004bfcb1c61a8a6fa8ab84f3e8 # v4.0.1
  with:
  node-version: ${{ inputs.node-version }}
  cache: ${{ env.CACHE_HIT != 'true' && 'pnpm' || '' }}

.github/workflows/build.yml

@@ -511,7 +511,7 @@ jobs:
  uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
 
  - name: Setup Node.js
- uses: actions/setup-node@8f152de45cc393bb48ce5d89d36b731f54556e65 # v4.0.0
+ uses: actions/setup-node@b39b52d1213e96004bfcb1c61a8a6fa8ab84f3e8 # v4.0.1
  with:
  node-version: ${{ env.NODE_VERSION }}
 

.github/workflows/codeql-analysis.yml

@@ -39,7 +39,7 @@ jobs:
 
  # Initializes the CodeQL tools for scanning.
  - name: Initialize CodeQL
- uses: github/codeql-action/init@c0d1daa7f7e14667747d73a7dbbe8c074bc8bfe2 # v2.22.9
+ uses: github/codeql-action/init@03e7845b7bfcd5e7fb63d1ae8c61b0e791134fab # v2.22.11
  with:
  languages: javascript
 
@@ -49,7 +49,7 @@ jobs:
  # Autobuild attempts to build any compiled languages (C/C++, C#, or Java).
  # If this step fails, then you should remove it and run the build manually (see below)
  - name: Autobuild
- uses: github/codeql-action/autobuild@c0d1daa7f7e14667747d73a7dbbe8c074bc8bfe2 # v2.22.9
+ uses: github/codeql-action/autobuild@03e7845b7bfcd5e7fb63d1ae8c61b0e791134fab # v2.22.11
 
  # ℹ️ Command-line programs to run using the OS shell.
  # 📚 https://git.io/JvXDl
@@ -63,4 +63,4 @@ jobs:
  # make release
 
  - name: Perform CodeQL Analysis
- uses: github/codeql-action/analyze@c0d1daa7f7e14667747d73a7dbbe8c074bc8bfe2 # v2.22.9
+ uses: github/codeql-action/analyze@03e7845b7bfcd5e7fb63d1ae8c61b0e791134fab # v2.22.11

.github/workflows/devcontainer.yml

@@ -21,6 +21,6 @@ jobs:
  uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1
 
  - name: Build and run dev container task
- uses: devcontainers/ci@c3e31cc561800ac318ed000e22ffc6713c93d009 # v0.3.1900000338
+ uses: devcontainers/ci@3d462823359c481c587cb7426f39775f24257115 # v0.3.1900000339
  with:
  runCmd: pnpm build

.github/workflows/release-npm.yml

@@ -48,7 +48,7 @@ jobs:
  run: corepack enable
 
  - name: Set up Node.js ${{ env.NODE_VERSION }}
- uses: actions/setup-node@8f152de45cc393bb48ce5d89d36b731f54556e65 # v4.0.0
+ uses: actions/setup-node@b39b52d1213e96004bfcb1c61a8a6fa8ab84f3e8 # v4.0.1
  with:
  node-version: ${{ env.NODE_VERSION }}
  cache: pnpm

.github/workflows/scorecard.yml

@@ -50,6 +50,6 @@ jobs:
 
  # Upload the results to GitHub's code scanning dashboard.
  - name: 'Upload to code-scanning'
- uses: github/codeql-action/upload-sarif@c0d1daa7f7e14667747d73a7dbbe8c074bc8bfe2 # v2.22.9
+ uses: github/codeql-action/upload-sarif@305f6546310b9203e892c28c1484e82977f4f63d # v2.22.10
  with:
  sarif_file: results.sarif

.github/workflows/update-data.yml

@@ -24,7 +24,7 @@ jobs:
  run: corepack enable
 
  - name: Set up Node.js ${{ env.NODE_VERSION }}
- uses: actions/setup-node@8f152de45cc393bb48ce5d89d36b731f54556e65 # v4.0.0
+ uses: actions/setup-node@b39b52d1213e96004bfcb1c61a8a6fa8ab84f3e8 # v4.0.1
  with:
  node-version: ${{ env.NODE_VERSION }}
  cache: pnpm

.vscode/settings.json

@@ -9,7 +9,7 @@
  "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[md]": {
- "editor.wordBasedSuggestions": false
+ "editor.wordBasedSuggestions": "off"
  },
  "files.associations": {
  "Dockerfile.*": "dockerfile",
@@ -21,6 +21,6 @@
  "npm.packageManager": "pnpm",
  "editor.formatOnSave": true,
  "editor.codeActionsOnSave": {
- "source.fixAll.eslint": true
+ "source.fixAll.eslint": "explicit"
  }
 }

data/debian-distro-info.json

@@ -39,7 +39,7 @@
  "series": "potato",
  "created": "1999-03-09",
  "release": "2000-08-15",
- "eol": "2003-07-30"
+ "eol": "2003-06-30"
  },
  "v3": {
  "codename": "Woody",

data/kubernetes-api.json5

@@ -110,17 +110,52 @@
  // https://kubernetes.io/docs/reference/using-api/deprecation-guide/#v1-27
  // https://kubernetes.io/docs/reference/using-api/deprecation-guide/#csistoragecapacity-v127
  CSIStorageCapacity: ['storage.k8s.io/v1beta1', 'storage.k8s.io/v1'],
- // https://github.com/fluxcd/flux2/releases/tag/v2.0.0
+
+ // https://fluxcd.io
+ Alert: [
+ 'notification.toolkit.fluxcd.io/v1beta2',
+ 'notification.toolkit.fluxcd.io/v1beta3',
+ ],
+ Bucket: [
+ 'source.toolkit.fluxcd.io/v1alpha1',
+ 'source.toolkit.fluxcd.io/v1beta1',
+ 'source.toolkit.fluxcd.io/v1beta2',
+ ],
  GitRepository: [
+ 'source.toolkit.fluxcd.io/v1alpha1',
+ 'source.toolkit.fluxcd.io/v1beta1',
  'source.toolkit.fluxcd.io/v1beta2',
  'source.toolkit.fluxcd.io/v1',
  ],
- Kustomization: [
- 'kustomize.toolkit.fluxcd.io/v1beta2',
- 'kustomize.toolkit.fluxcd.io/v1',
+ HelmChart: [
+ 'source.toolkit.fluxcd.io/v1alpha1',
+ 'source.toolkit.fluxcd.io/v1beta1',
+ ],
+ HelmRelease: [
+ 'helm.toolkit.fluxcd.io/v2beta1',
+ 'helm.toolkit.fluxcd.io/v2beta2',
+ ],
+ HelmRepository: [
+ 'source.toolkit.fluxcd.io/v1alpha1',
+ 'source.toolkit.fluxcd.io/v1beta1',
+ 'source.toolkit.fluxcd.io/v1beta2',
+ ],
+ ImageRepository: ['image.toolkit.fluxcd.io/v1beta2'],
+ OCIRepository: ['source.toolkit.fluxcd.io/v1beta2'],
+ Provider: [
+ 'notification.toolkit.fluxcd.io/v1beta2',
+ 'notification.toolkit.fluxcd.io/v1beta3',
  ],
  Receiver: [
  'notification.toolkit.fluxcd.io/v1beta2',
  'notification.toolkit.fluxcd.io/v1',
  ],
+
+ // https://fluxcd.io/flux/components/kustomize/kustomizations
+ // https://kubectl.docs.kubernetes.io/references/kustomize/kustomization
+ Kustomization: [
+ 'kustomize.toolkit.fluxcd.io/v1beta2',
+ 'kustomize.toolkit.fluxcd.io/v1',
+ 'kustomize.config.k8s.io/v1beta1',
+ ],
 }

docs/usage/config-presets.md

@@ -217,13 +217,12 @@ Create a [discussion](https://github.com/renovatebot/renovate/discussions) to pr
 The maintainers can also help improve the preset, and let you know where to put it in the code.
 If you are proposing a "monorepo" preset addition then it's OK to raise a PR directly as that can be more efficient than a GitHub Discussion.
 
-## Organization level presets
+## Group/Organization level presets
 
-Whenever repository onboarding happens, Renovate checks if the current user/group/org has a default config to extend.
-It looks for:
-
-- A repository called `renovate-config` under the same user/group/org with a `default.json` file or
-- A repository named like `.{{platform}}` (e.g. `.github`) under the same user/group/org with `renovate-config.json`
+Whenever repository onboarding happens, Renovate checks for a a default config to extend.
+Renovate will check for a repository called `renovate-config` with a `default.json` file in the parent user/group/org of the repository.
+On platforms that support nested groups (e.g. GitLab), Renovate will check for this repository at each level of grouping, from nearest to furthest, and use the first one it finds.
+On all platforms, it will then look for a repository named like `.{{platform}}` (e.g. `.github`) with a `renovate-config.json`, under the same top-level user/group/org.
 
 If found, that repository's preset will be suggested as the sole extended preset, and any existing `onboardingConfig` config will be ignored/overridden.
 For example the result may be:

docs/usage/configuration-options.md

@@ -1768,6 +1768,26 @@ Example config:
 }
 ```
 
+### maxRetryAfter
+
+A remote host may return a `4xx` response with a `Retry-After` header value, which indicates that Renovate has been rate-limited.
+Renovate may try to contact the host again after waiting a certain time, that's set by the host.
+By default, Renovate tries again after the `Retry-After` header value has passed, up to a maximum of 60 seconds.
+If the `Retry-After` value is more than 60 seconds, Renovate will abort the request instead of waiting.
+
+You can configure a different maximum value in seconds using `maxRetryAfter`:
+
+```json
+{
+ "hostRules": [
+ {
+ "matchHost": "api.github.com",
+ "maxRetryAfter": 25
+ }
+ ]
+}
+```
+
 ### dnsCache
 
 Enable got [dnsCache](https://github.com/sindresorhus/got/blob/v11.5.2/readme.md#dnsCache) support.
@@ -3564,6 +3584,23 @@ Configure this to `true` if you wish to get one PR for every separate major vers
 e.g. if you are on webpack@v1 currently then default behavior is a PR for upgrading to webpack@v3 and not for webpack@v2.
 If this setting is true then you would get one PR for webpack@v2 and one for webpack@v3.
 
+## statusCheckNames
+
+You can customize the name/context of status checks that Renovate adds to commits/branches/PRs.
+
+This option enables you to modify any existing status checks name/context, but adding new status checks this way is _not_ supported.
+Setting the value to `null` or an empty string, effectively disables or skips that status check.
+This option is mergeable, which means you only have to specify the status checks that you want to modify.
+
+```json title="Example of overriding status check strings"
+{
+ "statusCheckNames": {
+ "minimumReleaseAge": "custom/stability-days",
+ "mergeConfidence": "custom/merge-confidence-level"
+ }
+}
+```
+
 ## stopUpdatingLabel
 
 This feature only works on supported platforms, check the table above.

docs/usage/docker.md

@@ -383,7 +383,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:37.83.4
+FROM renovate/renovate:37.102.0
 # Include the "Docker tip" which you can find here https://cloud.google.com/sdk/docs/install
 # under "Installation" for "Debian/Ubuntu"
 RUN ...

docs/usage/gitlab-bot-security.md

@@ -4,25 +4,33 @@ title: GitLab bot security
 
 # GitLab bot security
 
-You should understand GitLab's security model, before deciding to run a "bot" service like Renovate on GitLab, particularly the pipeline credentials.
+Make sure you understand GitLab's security model, before you run a "bot" service like Renovate on GitLab, particularly the pipeline credentials.
 
-**Important**: If you have any doubts or concerns about this content that could affect other users, please follow our [Security Policy](https://github.com/renovatebot/renovate/security/policy) and report them confidentially.
+<!-- prettier-ignore -->
+!!! warning
+ If you have any doubts or concerns about this content that could affect other users, please follow our [Security Policy](https://github.com/renovatebot/renovate/security/policy) and report them confidentially.
 
 ## `CI_JOB_TOKEN` permissions
 
-The concept of `CI_JOB_TOKEN` permissions was [overhauled in GitLab release 8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/), jobs are now run with the permissions of the user account which _triggered_ the pipeline.
+The concept of `CI_JOB_TOKEN` permissions was [overhauled in GitLab release 8.12](https://about.gitlab.com/releases/2016/09/22/gitlab-8-12-released/), jobs now run with the permissions of the user account which _triggered_ the pipeline.
 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 as well as publish packages to them.
+Any pipeline triggered by a user account thus has permissions to:
 
-With the current GitLab CI permissions model, you should avoid committing to any project which you don’t trust completely, because that project could maliciously steal repository data, publish fake releases, or spam releases.
+- 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.
 
 ## Risks of hosting a Renovate GitLab app/bot/service
 
-The GitLab security model means that the risks of running a _public_ bot service on GitLab are too high, which is why the existing service has been suspended until an alternate security model is ready.
+With GitLab's current security model, we find the risks of running a _public_ bot service like Renovate are too high.
+Therefore we stopped hosting Renovate on GitLab, and are waiting for a better security model.
 
-It's also important to remember that when accounts are invited into projects or groups on GitLab, acceptance happens automatically (which was a useful feature to leverage for a shared service).
+You should remember that when accounts are invited into projects or groups on GitLab, acceptance happens automatically.
+This was a useful feature to leverage for a shared service.
 
-If you are running a self-hosted Renovate service, it is advisable to:
+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
@@ -33,33 +41,34 @@ The following research notes may help you to assess the GitLab bot security risk
 
 ### Public projects only
 
-If a bot service is run on public projects only, then the risk of private project data being accessed by unauthorized users is zero.
-But malicious users can still spoof or spam packages to any other public project they are not a member of, so that rules out this approach for a public hosted service.
+If you only run a bot service on _public_ projects, the risk of unauthorized users accessing private project data is zero.
+But malicious users can still spoof or spam packages to any other public project they are not a member of, this rules out this approach for a public hosted service.
 
 A public-visibility-only bot service should be low risk for most self-hosted GitLab instances.
-There is still a small problem that you can't _prevent_ users from inviting the bot into private projects if they are not aware of the risks of doing so.
+But you _can't stop users_ from inviting the bot into _private_ projects by accident, which is risky.
 
 ### Project Access Tokens
 
-[Project Access Tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) are a recently added feature for GitLab.
-The main downsides to their use for a shared bot service are:
+[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:
 
-- It is not yet possible to [provision them 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
-- Project Access Tokens are a paid-only feature for gitlab.com, which excludes a large percentage of the public service user base
-- At the time of writing, there are still some issues with getting Project Access Tokens to trigger and authenticate CI
-- Any service using such tokens would get MRs from a user like `@project_123_bot` which is less intuitive than `@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 Project Access Tokens is their limited scope, users with write access to one project cannot read/write to other projects.
+The big benefit of PATs is their limited scope: users with write access to one project cannot read/write to other projects.
 
 ### Group Access Tokens
 
 Group Access Tokens are still in the planning stage, but may offer a more scalable way to manage a Renovate service.
-Tokens could be provisioned into Renovate per-group and permissions/visibility would need to be kept uniform throughout the group to ensure escalation of privileges is not possible.
+Tokens could be provisioned into Renovate per-group.
+Permissions and visibility _must_ be kept uniform throughout the group to prevent a privilege escalation.
 
-It should be noted though that many GitLab users _do not_ have uniform permissions/visibility throughout groups today, so this is a risk of Group Access Tokens in general.
-Even [https://gitlab.com/gitlab-org](https://gitlab.com/gitlab-org) is a good example of how common it is to mix project visibility within a same group.
+Many GitLab users _do not_ have uniform permissions and visibility throughout groups today, so this is a risk of Group Access Tokens in general.
+The [`gitlab-org` organization on GitLab](https://gitlab.com/gitlab-org) shows how common it is to mix project visibility within a same group.
 
-Similarly with Project Access Tokens, if they are a paid-only feature then it would exclude free users from using such a service.
+And the same as with PATs, if Group Access Tokens becomes a paid feature then users on a free plan can't use the feature.
 
 ### Skipping CI
 
@@ -77,13 +86,13 @@ Bot services are better if they are provisioned with a "bot identity" so that us
 
 ## Recommended migration
 
-Until the hosted app can be reactivated, we recommend users migrate to use self-hosted pipelines to run Renovate.
-Please see the [renovate-bot/renovate-runner README on GitLab](https://gitlab.com/renovate-bot/renovate-runner/-/blob/HEAD/README.md) for instructions on how to set this up as easily as possible.
+Until we can safely reactivate the hosted app, we recommend users migrate to use self-hosted pipelines to run Renovate.
+Read the [renovate-bot/renovate-runner README on GitLab](https://gitlab.com/renovate-bot/renovate-runner/-/blob/HEAD/README.md) to learn how.
 
 ## Status of the Renovate app for GitLab
 
 We're trying to find a workable design for the GitLab app, so we can enable it safely again.
-If you have any ideas, open a [discussion](https://github.com/renovatebot/renovate/discussions) and let us know!
+If you have any ideas, please open a [discussion](https://github.com/renovatebot/renovate/discussions) and let us know!
 
 GitLab introduced Group Access Tokens & API for paid & self-hosted instances, but a good permission setup/flow is still not possible.
 Check out [GitLab issue #346298](https://gitlab.com/gitlab-org/gitlab/-/issues/346298).