As noted in #41214, it would be convenient to not have to manually
update this list.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* refactor(docs): don't use an `end` for autogenerated docs
As part of #42910, we wanted to avoid needing a "begin" and "end" to
each of our autogenerated docs replacements.
While looking into it, we're not actually using the "end" for anything,
so we can instead refactor this to be a single-line replacement.
To simplify the code and docs, we can remove this. At the point we need
this again, we can re-add the functionality.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! Merge remote-tracking branch 'origin/HEAD' into chore/no-replaceStop
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
docs(onboarding): Fix grammar issue with phrase
Update grammatical issue with the following phrase.
[From]
This is action reversible
[To]
This action is reversible
* supportsTemplating field
* fix ci issue
* fix ci issue
* move tip below table
* apply suggestions
* docs: show list of options that support templating
* jsodc explanations for internal fields
* add test to ensure no option that applies template.compile() missed supportsTemplating=true
* apply review suggestions
* fix bad merge
* add filePatterns and commands to the list
When a GitLab project has merge trains enabled, automerged MRs are now added to the merge train via POST /projects/:id/merge_trains/merge_requests/:iid with auto_merge:true (GitLab 17.11+). Non-merge-train projects keep using the existing /merge endpoint, preserving Renovate's pipeline-success guarantee for free-tier users.
* docs(merge-confidence): add note about Workflows
* docs(merge-confidence): point feedback to megathread
* docs(mend-hosted): use superscript for note
* docs(mend-hosted): rewrite the plans + resources table
* docs(mend-hosted): move IP addresses to FAQs
* feat(managers): rename `renovate-config-presets` to `renovate-config`
As part of future changes, we'll extend this support to cover other
functionality. Instead of having multiple managers for this
functionality, we'll use a single, shared, manager for all Renovate
config management.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* fixup! feat(managers): rename `renovate-config-presets` to `renovate-config`
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs: add a deep dive for how the container gets built
As per #42590, it would be useful to have this explicitly documented for
our users.
* fixup! docs: add a deep dive for how the container gets built
* fixup! docs: add a deep dive for how the container gets built
* fixup! docs: add a deep dive for how the container gets built
* feat(datasource/go): conditionally expose `constraints`
As noted in #42567, some Go modules are constrained by their
compatibility with the source compatibility with the Go language as per
the `go` directive.
Bumping the `go` directive will result in all of a library's consumers
also needing to bump their own `go`, which can be something library
authors will attempt to avoid.
Previously, Renovate users would receive an update from any modules that
have a new release, regardless of whether they will bump the `go`
directive.
With this change, users who use `constraintsFiltering=strict` will have
the filtering applied, so they only receive updates for Go modules in
their current minor version.
Due to the additional API calls needed, this is an opt-in feature, and
only includes the API calls when the using
`constraintsFiltering=strict`.
We can also add an integration test to build our confidence in the
end-to-end flow.
* fix(datasource/go): correctly check Go directive for major version bumps
As we weren't passing around the `pkg` (which included the Semantic
Module Import Path), we were incorrectly lacking major version upgrades.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* chore: remove `fallback`
As it's unnecessary.
* docs(gomod): rephrase
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat: allow separate versioning for constraints
As noted in #31831, there are times where it can be useful to override
the version that a given datasource uses, when performing
`constraintsFiltering=strict.`
This should only be applicable to the "additional" constraints, so we
make sure to validate this.
As this is new functionality, any misconfiguration should be marked as
an error.
We can make sure to provide a real-world usecase for this (taking
inspiration from `rails`' versioning of the `rubygems` constraint).
This will be used in the future by the extraction of the `go` directive,
which requires a different versioning to the default `semver`.
* fixup! feat: allow separate versioning for constraints
* fixup! feat: allow separate versioning for constraints
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* extra-log-context
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* feat(terraform-provider): add zod schemas for v2 API response
* feat(terraform-provider): use registry v2 API for release timestamps
* feat(terraform-provider): add zod schema for OpenTofu API response
* feat(terraform-provider): add OpenTofu registry docs API support
* feat(terraform-provider): update v2 API response handling and schema validation
* feat(terraform-provider): use schema transform for OpenTofu response
* fix(terraform-provider): address PR review feedback for OpenTofu support
* fix(terraform-provider): resolve sourceUrl from OpenTofu version details
* fix(terraform-provider): derive OpenTofu sourceUrl from registry naming policy
* docs(constraints): list the possible `constraints` and `installTools`
Now we have a stronger type for what a valid tool constraint is, and
what additional constraints are, we should be very explicit with what
each option is, and specify them in the `constraints` as well as our
`installTools` docs.
* test: add coverage
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
---------
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As we do with the other modules, we should include Managers too.
Although there are many, it can be a little jarring not seeing the list
of Managers when viewing a specific one.
This requires we also show the "display name" (`Ansible`) in the
sidebar, and then use the more verbose `Automated Dependency Updates for
Ansible` as the header.
To do this, we can utilise the `sidebar_label` (which was previously
used in Docusarus, but unused by Material for MkDocs) via a custom hook
to inject the label for the sidebar.
Unfortunately this requires a custom hook, which will make moving away
from Material for MkDocs (to Zensical) a little less straightforward.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As they are configuration options and can be quite code-y we should
render them like this.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* chore: move from volta.sh to mise
* !fixup chore: move from volta.sh to mise
* Update mise.toml
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Felipe Santos