This repository has been archived by the owner on Jun 28, 2022. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
v1.1.0
->v1.8.2
Release Notes
jetstack/cert-manager
v1.8.2
Compare Source
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
v1.8.2 is in effect a bug fix release which increases some hard-coded timeouts which were preventing the use of certain ACME issuers
which sometimes had slower response times. This is known to include ZeroSSL and Sectigo.
These issues were reported by many different users and We'd like to thank the following for their help, suggestions and feedback on this topic:
Thanks also to the cert-manager maintainers who were involved in reviewing this fix and helping to move things forwards:
Changes since v1.8.1
Bug
Other (Cleanup)
v1.8.1
Compare Source
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
1.8.1 is a patch release rebuilding cert-manager 1.8 using the latest version of Go.
Changelog since cert-manager 1.7.1
Reverts a check for Prometheus APIs before creating cert-manager ServiceMonitors which broke users' GitOps flows (cert-manager#5204)
Bumps the version of Go used to build the cert-manager binaries to 1.17.11 which fixes a few CVEs (we don't think that those were likely to be exploited in cert-manager) (cert-manager#5203, @irbekrm )
v1.8.0
Compare Source
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
cert-manager 1.8 includes wider support for Kubernetes server-side-apply, a new build and development experience based around
Makefile
s rather than Bazel, and a range of other improvements, tweaks and bug fixes.Version 1.8 also marks our first release in which the Go import path for cert-manager is that of the repo's new home:
github.com/cert-manager/cert-manager
Breaking Changes (You MUST read this before you upgrade!)
Validation of the
rotationPolicy
fieldThe field
spec.privateKey.rotationPolicy
on Certificate resources is now validated. Valid options are Never and Always. If you are using a GitOps flow and one of your YAML manifests contains a Certificate with an invalid value, you will need to update it with a valid value to prevent your GitOps tool from failing on the new validation. Please follow the instructions listed on the page Upgrading from v1.7 to v1.8. (#4913, @jahrlin)What happens if I upgrade to 1.8.0 without doing the above steps?
After upgrading to 1.8.0, when updating existing Certificate objects that have an incorrect value for
rotationPolicy
, Kubernetes clients such as kubectl, Helm, or ArgoCD will start showing the following message:Why was this change necessary?
Previously, when the value of the
rotationPolicy
field was set to an incorrect value, you would not know since no event or condition would be visible on the Certificate itself. The only way to know that something was wrong was to dig into the cert-manager-controller logs and see the message "Certificate with unknowncertificate.spec.privateKey.rotationPolicy
value":This change was implemented in #4913.
Changed Container Layouts
This only affects you if you're modifying cert-manager containers in some way, such as adding init scripts or otherwise
changing how the binaries inside the containers are called.
Bazel has a unique way of creating containers, which places the actual binary at a long unusual path. For the v1.7.0 cert-manager-webhook
container for example, the binary is placed at
/app/cmd/webhook/webhook.runfiles/com_github_jetstack_cert_manager/cmd/webhook/webhook_/webhook
and
/app/cmd/webhook/webhook
is provided as a symlink to the binary.This is simplified in our new build system; we only place a single binary at
/app/cmd/webhook/webhook
and the old path disappears.This applies to all cert-manager containers.
We also removed the "LICENSES" file from the containers and replaced it with a link to the cert-manager repo.
.exe
Extension on WindowsWe package
cmctl
andkubectl_cert-manager
for Windows onamd64
platforms, but previously the binaries had thesame names as the binaries on other platforms, e.g.
cmctl
with no file extension.In 1.8.0 and later, the binaries now have a
.exe
extension since this is standard practice on Windows. This could affect youif you're calling the binary in a Powershell script, for example.
We've also now added zip-compressed versions of the
cmctl
andkubectl_cert-manager
binaries on Windows, since.tar.gz
is lesscommon on Windows.
Changed Import Path
This will only affect you if you're writing code in Go which imports cert-manager as a module, which we generally recommend against
doing in most cases.
All versions of cert-manager prior to v1.8.0 used a Go import path corresponding to the old cert-manager repository,
github.com/jetstack/cert-manager
.v1.8.0 marks the first release in which the import path changes to the new location,
github.com/cert-manager/cert-manager
.We have a guide for Importing cert-manager in Go on cert-manager.io with all the details, including
details on why we don't recommend importing cert-manager as a module if that's avoidable.
Major Themes
Server-Side Apply
cert-manager v1.8.0 adds initial support for Kubernetes Server-Side Apply, which became stable
in Kubernetes 1.22. This support is behind a feature gate for now, and is only supported by cert-manager on Kubernetes 1.22 and later.
Server-Side Apply helps to ensure that changes to resources are made in a managed way, and aims to prevent certain classes of bugs. Notably, it should
eliminate conflicts when multiple controllers try to apply status changes to a single resource. You'll likely have seen messages relating to this kind of
conflict in logs before, e.g.:
These conflicts aren't usually actually a problem which will block the issuance of a certificate, but they can delay things as they cause extra
reconcile loops. Server-side apply cleans things up, which should mean less noise in logs and fewer pointless reconcile loops.
If you want to test it out, you can enable alpha-level cert-manager Server-Side Apply support through the
--feature-gates
controller flag.From Bazel to Make
A common theme when someone tries to make a change to cert-manager for the first time is that they ask for help with navigating Bazel, which cert-manager
used as its build tool. Helping people with Bazel isn't easy; it's an incredibly powerful tool, but that power also brings a lot of complications
which can seriously get in the way of being able to make even simple changes to the code base. Even developers who are familiar with contributing
to open source projects in Go can find it daunting to make changes thanks to Bazel.
The problem isn't limited to open-source contributors; many of cert-manager's maintainers also struggle with configuring and changing Bazel, too.
cert-manager 1.8 is the first release which is built and tested using a newly written
make
-based build system. We believe that this new build system shouldmake it much simpler to understand and change the commands which are being run behind the scenes to build and test cert-manager. In time, we'll fully
document the new build system, ensure it's at full feature-parity with Bazel and then remove all references to Bazel across the codebase.
A neat side effect of this change is that our build times have significantly improved. Bazel took around 14 minutes to build every cert-manager
artifact for every platform during a release, while the new
make
build system can do the same (and more) in under 5 minutes.Exponential backoff after a failed issuance
cert-manager v1.8.0 introduces exponential backoff after failed certificate issuance.
Previously, a failed issuance was retried every hour which — especially in larger cert-manager installations — could cause rate limits to be hit as well as overwhelm external services. Failed attempts
are now retried with a binary exponential backoff starting with
1h
then2h
,4h
up to a maximum of32h
. As part of the new backoff behavior, a newfailedIssuanceAttempts
field was added to theCertificate
spec to track the number of currently failed issuances.The
cmctl renew
command command can still be used to forceCertificate
renewal immediately.We're also considering reducing the initial backoff from 1 hour. If you have a use case where this would be useful please do comment on our tracking issue.
Community
cert-manager thrives thanks to the community and we're always grateful for receiving open-source contributions!
Thanks to the following community members who landed a commit in this release:
Thanks also to the cert-manager maintainer team involved with this release
Changelog since v1.7.0
Feature
spec.privateKey.rotationPolicy
on Certificate resources is now validated. Valid options are Never and Always. If you are using a GitOps flow and one of your YAML manifests contains a Certificate with an invalid value, you will need to update it with a valid value to prevent your GitOps tool from failing on the new validation. (#4913, @jahrlin)spec.expirationSeconds
on Kubernetes CertificateSigningRequest resources. Using this field requires Kubernetes 1.22. You can still use the annotationexperimental.cert-manager.io/request-duration
to request a duration. (#4957, @enj)tls-combined.pem
andkey.der
on Secret resources that are associated to Certificate resources that use the fieldadditionalOutputFormats
. The fieldadditionalOutputFormat
is an alpha feature and can be enabled by passing the flag--feature-gates=AdditionalCertificateOutputFormats=true
to the cert-manager controller. (#4813, @JoshVanL)ServerSideApply=true
now configures theingress-shim
andgateway-shim
controllers to use Kubernetes Server-Side Apply on Certificate resources. When upgrading to cert-manger 1.8 withServerSideApply=true
, do make sure there are no Challenge resources currently in the cluster. If there are some, you will need to manually delete them once they are in 'valid' state as cert-manager post-1.8 with the Server-Side Apply feature is not able to clean up Challenge resources created pre-1.8. (#4811, @JoshVanL)ServerSideApply=true
configures thecertificaterequests-*
controllers to use Kubernetes Server-Side Apply on CertificateRequest resources. (#4792, @JoshVanL)ServerSideApply=true
configures thecertificates-*
controllers to use Kubernetes Server-Side Apply on Certificate resources. (#4777, @JoshVanL)ServerSideApply=true
configures the CertificateSigningRequest controllers to use Kubernetes Server-Side Apply on CertificateSigningRequest resources. (#4798, @JoshVanL)ServerSideApply=true
configures theissuers
andclusterissuers
controllers to use Kubernetes Server-Side Apply on Issuer and ClusterIssuer resources. (#4794, @JoshVanL)ServerSideApply=true
configures theorders
controller to use Kubernetes Server-Side Apply on Order resources. (#4799, @JoshVanL)experimental.cert-manager.io/request-duration
now has a minimum value of 600 seconds. This annotation This change ensures compatibility with the Kubernetes resource CertificateSigningRequest, which requires a minimum of 600 seconds on the fieldspec.expirationSeconds
. (#4973, @irbekrm)ingress.kubernetes.io/whitelist-source-range
used by the Ingress shim when creating Ingress resources can now be overridden by setting the fieldingressTemplate
on the Issuer and ClusterIssuer. (#4789, @tasharnvb)cert-manager-<component name>/<version> (<os>/<arch>) cert-manager/<git commit>
. Another change is the addition of specific field managers strings; previously, all the controllers had the same field managercert-manager
. Now, each controller has its own field manager string of the formcert-manager-<controller name>
. (#4773, @JoshVanL)cmctl experimental uninstall
. (#4897, @jahrlin)--default-issuer-group
,--default-issuer-kind
, and--default-issuer-name
. (#4833, @jakexks)Design
github.com/cert-manager/cert-manager
. If you import cert-manager as a go module (which isn't currently recommended), you'll need to update the module import path in your code to import cert-manager 1.8 or later. (#4587, @SgtCoDFish)Bug or Regression
additionalOutputFormats
, which is available as an alpha feature on Certificate resources, is now correctly validated. Previously, it would only get validated when theprivateKey
field was set on the Certificate. If you are using theadditionalOutputFormats
field, you will want to add the feature gateAdditionalCertificateOutputFormats
to both the webhook and the controller. Previously, you only needed to setAdditionalCertificateOutputFormats
on the controller. If the feature gate is missing on either the controller or the webhook, you won't be able to use theadditionalOutputFormat
field. (#4814, @JoshVanL)kubernetes.io/os: linux
. If this label isn't present on any nodes in the cluster, thenodeSelector
will need to be overwritten, or that label added to some nodes. (#3605, @mikebryant)Other (Cleanup or Flake)
cmctl renew
command in their namespaces. (#4955, @andreadecorte)1h
,2h
,4h
,8h
,16h
,32h
. A new fieldfailedIssuanceAttempts
is now set by cert-manager on the Certificate status. This field keeps track of consecutive failed issuances. The backoff period gets reset after a successful issuance. Like before, updating a field on a failed Certificate (such asspec.dnsNames
) or running the commandcmctl renew
continues to trigger a re-issuance. (#4772, @irbekrm)serviceAccount.labels
,cainjector.serviceAccount.labels
,webhook.serviceAccount.labels
, andstartupapicheck.serviceAccount.labels
. (#4932, @4molybdenum2)Uncategorized
controller_sync_error_count
counting the number of errors during sync() of a controller. (#4987, @jayme-github)allowPrivilegeEscalation
tofalse
by default. The Helm chart now also setssecurityContext.allowPrivilegeEscalation
tofalse
by default for the controller, cainjector, and webhook pods as well as for the startupapicheck job. (#4953, @ajvn)v1.7.3
Compare Source
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
v1.7.3 is in effect a bug fix release which increases some hard-coded timeouts which were preventing the use of certain ACME issuers
which sometimes had slower response times. This is known to include ZeroSSL and Sectigo.
These issues were reported by many users. We'd like to thank the following for their help and feedback on this topic:
Thanks also to the cert-manager maintainers who were involved in reviewing this fix and helping to move things forwards:
Changes since v1.7.2
Bug
Other (Cleanup)
v1.7.2
Compare Source
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
1.7.2 is a minor release rebuilding cert-manager 1.7 using the latest version of Go. This eliminates a few security vulnerabilities which have accumulated in Go since the last release.
We don't believe any of those vulnerabilities were practically exploitable or relevant to cert-manager, but we decided to rebuild to keep up to date anyway.
Changelog since cert-manager 1.7.1
Bug or Regression
v1.7.1
Compare Source
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.7.1 fixes a bug which was discovered in 1.7.0 relating to the new
additionalOutputFormat
feature.Changelog since v1.7.0
Bug or Regression
additionalOutputFormats
is now correctly validated at admission time, and no longer only validated if theprivateKey
field of the Certificate is set. The Webhook component now contains a separate feature set.AdditionalCertificateOutputFormats
feature gate (disabled by default) has been added to the webhook. This gate is required to be enabled on both the controller and webhook components in order to make use of the Certificate'sadditionalOutputFormat
feature. (#4816, @JoshVanL)v1.7.0
Compare Source
cert-manager is the easiest way to automatically manage certificates in Kubernetes and OpenShift clusters.
Version 1.7 brings new private key output formats, configuration improvements for the webhook, some long-awaited code cleanup, a fix for ingress class semantics and a bunch of other changes.
Breaking Changes (You MUST read this before you upgrade!)
Removal of Deprecated APIs
⚠ Following their deprecation in version 1.4, the cert-manager API versions v1alpha2, v1alpha3, and v1beta1 have been removed. You must ensure that all cert-manager custom resources are stored in etcd at version v1 and that all cert-manager
CustomResourceDefinition
s have only v1 as the stored version before upgrading.Since release 1.7,
cmctl
can automatically migrate any deprecated API resources. Please [downloadcmctl-v1.7.0
][download cmctl-v1.7.0] and read Migrating Deprecated API Resources for full instructions.Ingress Class Semantics
In 1.7, we have reverted a change that caused a regression in the ACME Issuer. Before 1.5.4, the Ingress created by cert-manager while solving an HTTP-01 challenge contained the
kubernetes.io/ingress.class
annotation:After 1.5.4, the Ingress does not contain the annotation anymore. Instead, cert-manager uses the
ingressClassName
field:This broke many users that either don't use an Ingress controller that supports the field (such as ingress-gce and Azure AGIC), as well as people who did not need to create an IngressClass previously (such as with Istio and Traefik).
The regression is present in cert-manager 1.5.4, 1.6.0, 1.6.1. It is only present on Kubernetes 1.19+ and only appears when using an Issuer or ClusterIssuer with an ACME HTTP-01 solver configured.
In 1.7, we have restored the original behavior which is to use the annotation. We will also backport this fix to 1.5.5 and 1.6.2, allowing people to upgrade safely.
Most people won't have any trouble upgrading from a version that contains the regression to 1.7.0, 1.6.2 or 1.5.5. If you are using Gloo, Contour, Skipper, or kube-ingress-aws-controller, you shouldn't have any issues. If you use the default "class" (e.g.,
istio
for Istio) for Traefik, Istio, Ambassador, or ingress-nginx, then these should also continue to work without issue.If you are using Traefik, Istio, Ambassador, or ingress-nginx and you are using a non-default value for the class (e.g.,
istio-internal
), or if you experience any issues with your HTTP-01 challenges please read the notes on Ingress v1 compatibility.Upgrading with Server Side Apply
As part of the work to remove deprecated APIs cert-manager
CustomResourceDefinition
s no longer require a conversion webhook. The related change in cert-managerCustomResourceDefinition
specs results in invalidCustomResourceDefinition
configurations for users who are upgrading to cert-manager 1.7 usingkubectl apply --server-side=true -f <manifests>
. This can be solved either by performing the upgrade with client side apply or by manually patching the managed fields of cert-managerCustomResourceDefinitions
:(Thanks to @stevehipwell for the above patch commands!)
See the original GitHub issue
cert-manager#​4831
Major Themes
Removal of Deprecated APIs
In 1.7 the cert-manager API versions v1alpha2, v1alpha3, and v1beta1, that were deprecated in 1.4, have been removed from the custom resource definitions (CRDs). As a result, you will notice that the YAML manifest files are much smaller.
In this release we have added a new sub-command to the cert-manager CLI (
cmctl upgrade migrate-api-version
), which you SHOULD run BEFORE upgrading cert-manager to 1.7. Please read [Removing Deprecated API Resources] for full instructions.Additional Certificate Output Formats
additionalOutputFormats
is a field on the Certificatespec
that allows specifying additional supplementary formats of issued certificates and their private key. There are currently two supported additional output formats:CombinedPEM
(the PEM-encoded private key followed by the certificate chain) andDER
(the DER-encoded private key only). Any combination of output formats can be requested for the same certificate. Read Additional Certificate Output Formats for more details and thanks to @seuf for getting this across the line!Server-Side Apply
This is the first version of cert-manager which relies on Server-Side Apply. We use it to properly manage the annotations and labels on TLS secrets. For this reason cert-manager 1.7 requires at least Kubernetes 1.18 (see Supported Releases for further compatibility details).
Configuration Files
In this release we introduce a new configuration file for the cert-manager-webhook. Instead of configuring the webhook using command line flags, you can now modify the webhook Deployment to mount a ConfigMap containing a configuration file. Read the WebhookConfiguration Schema for more information.
In future releases we will introduce configuration files for the other cert-manager components: the controller and the cainjector.
Developing cert-manager Without Bazel
In a future release, we'll remove the use of
bazel
for building and testing cert-manager, with the aim of making it as easy as possible for anyone to contribute and to get involved with the cert-manager project.The work is ongoing, but for now we've ensured that cert-manager 1.7 can be built with
go build
, and that all unit tests can be run withgo test ./cmd/... ./internal/... ./pkg/...
.Community
Thanks again to all open-source contributors with commits in this release, including:
Thanks as usual to @coderanger for helping people out on the [
#cert-manager
Slack channel][#cert-manager Slack channel]; it's a huge help and much appreciated.In addition, the following cert-manager maintainers were involved in this release:
Changelog since v1.6.0
Feature
--acme-http01-solver-nameservers
flag to enable custom nameservers usage for ACME HTT01 challenges propagation checks. (#4287, @Adphi)cmctl upgrade migrate-api-version
to ensure all CRD resources are stored at 'v1' prior to upgrading to v1.7 onwards (#4711, @munnerz)additionalOutputFormats
parameter to allowDER
(binary) andCombinedPEM
(key + cert bundle) formats. (#4598, @seuf)prometheus.servicemonitor.honorLabels
, which sets thehonor_labels
field of the Prometheus scrape config. (#4608, @thirdeyenick)--enable-profiling
,--profiler-address
CLI flags to configure profiling. Thanks to @bitscuit for help with this! (#4550, @irbekrm)Bug or Regression
RunWebhookServer
(#4702, @devholic)cmctl version
to erroneously display the wrong webhook pod versions when older failed pods are present. (#4615, @johnwchadwick)cmctl
that prevented displaying the Order resource with cert-manager 1.6 when runningcmctl status certificate
. (#4569, @maelvls)kubernetes.io/ingress.class
annotation instead of thespec.ingressClassName
in created Ingress resources. (#4762, @jakexks)cmctl experimental install
command now uses the cert-manager namespace. This fixes a bug which was introduced in release 1.6 that caused cert-manager to be installed in the default namespace. (#4763, @wallrj)Other (Cleanup or Flake)
clock_time_seconds_gauge
metric which returns the current clock time, based on seconds since 1970/01/01 UTC (#4640, @JoshVanL)dns01-self-check-nameservers
flag. Use--dns01-recursive-nameservers
instead. (#4551, @irbekrm)v1beta1
form the webhook'sadmissionReviewVersions
as cert-manager no longer supports v1.16 (#4639, @JoshVanL)v1.6.3
Compare Source
v1.6.3 Release Notes
1.6.3 is a minor release rebuilding cert-manager 1.6 using the latest version of Go. This eliminates a few security vulnerabilities which have accumulated in Go since the last release.
We don't believe any of those vulnerabilities were practically exploitable or relevant to cert-manager, but we decided to rebuild to keep up to date anyway.
Changelog since cert-manager 1.6.2
Bug or Regression
v1.6.2
Compare Source
In 1.6.2, we have reverted a change present in 1.6.0 and 1.6.1 that caused a regression in the ACME Issuer. In 1.6.0 and 1.6.1, the Ingress created by cert-manager while solving an HTTP-01 challenge contained the
kubernetes.io/ingress.class
annotation:After 1.5, the Ingress does not contain the annotation anymore. Instead, cert-manager uses the
ingressClassName
field:This broke many users that either don't use an Ingress controller that supports the field (such as ingress-gce and Azure AGIC), as well as people who did not need to create an IngressClass previously (such as with Istio and Traefik).
The regression is present in cert-manager 1.5.4, 1.6.0, and 1.6.1. It is only present on Kubernetes 1.19+ and only appears when using an Issuer or ClusterIssuer with an ACME HTTP-01 solver configured.
In 1.6.2, we have restored the original behavior which is to use the annotation. This patch is also available in 1.5.5 and in 1.7.0.
Most people won't have any trouble upgrading from 1.6.0 or 1.6.1 to 1.6.2. If you are using Gloo, Contour, Skipper, or kube-ingress-aws-controller, you shouldn't have any issues. If you use the default "class" (e.g.,
istio
for Istio) for Traefik, Istio, Ambassador, or ingress-nginx, then these should also continue to work without issue.If you are using Traefik, Istio, Ambassador, or ingress-nginx and you are using a non-default value for the class (e.g.,
istio-internal
), or if you experience any issues with your HTTP-01 challenges please read the notes on Ingress v1 compatibility.Changelog since v1.6.1
Bug or Regression
kubernetes.io/ingress.class
annotation instead of thespec.ingressClassName
in created Ingress resources. (#4785, @jetstack-bot)Other (Cleanup or Flake)
Dependencies
Added
Nothing has changed.
Changed
Nothing has changed.
Removed
Nothing has changed.
v1.6.1
Compare Source
Changelog since v1.6.0
Changes by Kind
Bug or Regression
cmctl
that prevented displaying the Order resource with cert-manager 1.6 when runningcmctl status certificate
. (#4572, @maelvls)Dependencies
Added
Nothing has changed.
Changed
Removed
Nothing has changed.
v1.6.0
Compare Source
Changelog since v1.5.0
Breaking Changes (You MUST read this before you upgrade!)
v1alpha2, v1alpha3, and v1beta1
are no longer served.This means if your deployment manifests contain any of these API versions, you will not be able to deploy them after upgrading. Our new
cmctl
utility or oldkubectl cert-manager
plugin can convert old manifests tov1
for you.Changes by Kind
Feature
cmctl
as well askubectl-cert_manager
(#4523, @JoshVanL)cmctl completion
command for generating shell completion scripts for bash, zsh, fish, and powershell (#4408, @JoshVanL)Bug or Regression
startupapicheck
post-install hook in the Helm chart now deletes any post-install hook resources left after a previous failed install allowing helm install to be re-run after a previous failure. (#4433, @wallrj)Other (Cleanup or Flake)
CertificateRequest
s owningOrder
s. (#4369, @irbekrm)v1.5.5
[Compare Source](https://togithub.com/jetstack/cert-
Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.