fix(github): attempt direct merge before falling back to the merge queue
PR automerge against a merge-queue-protected base branch could no longer
merge directly when the authenticated actor is allowed to bypass the
queue: mergePr() enqueues the PR unconditionally once the base branch has
a merge queue, and the enqueuePullRequest mutation evaluates queue-entry
requirements (e.g. required code-owner review) without honoring ruleset
bypass, leaving bypass-enabled installs unable to merge at all.
Attempt the direct REST merge first and enqueue only when that merge is
refused, mirroring the try-first design #45724 shipped for branch
automerge. Repositories without a bypass actor pay one refused REST merge
call per automerge attempt before the queue fallback, and up to four when
an unrecognized refusal message triggers method guessing.
Docs: describe the direct-merge-first behavior in the GitHub merge queue
section of the automerge documentation.
* feat(automerge): attempt branch automerge before falling back to a PR on merge queue rejection
* refactor(automerge): ask the platform instead of parsing merge queue rejection messages
* feat(gitlab): merge MRs through merge trains via the platform merge queue API
* feat(gitlab): report MRs waiting on a merge train through isPrInMergeQueue
* test(gitlab): drop targetBranch from mergePr calls
* Apply suggestion from @secustor
* refactor(gitlab): validate the merge train car response with a Zod schema
* feat(github): add experimental support for using merge queues without auto merge
* test(github): use vi.stubEnv for merge queue env flag
* fix(github): do not re-enqueue PRs already waiting in the merge queue
* refactor(github): reuse merge queue detection from #45252 for isBranchMergeQueueEnabled
* refactor(github): read the base branch from the PR instead of extending MergePRConfig
* feat(github): enable merge queue support without the RENOVATE_X_GITHUB_MERGE_QUEUE flag
* Apply suggestion from @secustor
We dropped the "bot" from our terminology long ago, but it looks like
we've got some outdated docs + code that reference it.
We should remove this to keep things consistent.
A `fix`, as we're changing the commit author's name, and log lines.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
* docs: correct `onboardingConfig` example
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: correct `module.exports` syntax
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: completely skip `doc-fence-check` on code blocks only used for synatx highlighting
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: skip schema validation on non-config snippets
As we'll be enforcing this as valid Global config in future commits.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): validate JSONC and Javascript code blocks
To further ensure that our documentation is well-formed, we can validate
that JSONC and Javascript code blocks are well-formed syntactically, and
are valid Renovate configuration.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* chore(tools/doc-fence-check): allow opting out of syntax validation
On top of schema validation wanting to be disabled, we should also
support disabling the syntax validation, in the case that we're using
`json` code blocks for syntax highlighting, but they're not necessarily
well-formed JSON.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: use `json` syntax highlighting
As `jsonc` doesn't seem to exist in Material for MkDocs.
As it's only for syntax highlighting, we need to opt out of validation.
* tsc
---------
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
As these have been out-of-sync with what is and is not currently
supported per our documentation.
Co-authored-by: Claude Opus 4.8 <jamie.tanna+claude-code@mend.io>
As per #44820, `pinDigest` updates currently don't get
`minimumReleaseAge` checks applied to them.
We can extend the recent support for `digest`s being handled by also
introducing support for `pinDigest`s to receive `minimumReleaseAge`
enforcement.
This will:
- enforce `minimumReleaseAge` on all updates that `pinDigest`s has
pending
- consider the newest resolved version's timestamp, ignoring
`rangeStrategy`-related logic
- allow unversioned releases like `latest` to /not/ be bound by
`minimumReleaseAge`, as they'll potentially not have a release
timestamp and will be unpinned forever, which is less safe (and
reduces reproducibility)
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
In some cases, we hadn't correctly wired in the `minimumReleaseAge`
checks for `digest`, due to the `currentValue` not changing.
To handle this, we need to:
- use our helper methods for calculating whether the `minimumReleaseAge`
has passed
- handle a new digest's new `releaseTimestamp`
the current timestamp
- intentionally not gate `minimumConfidence`, as this is only computed
per-release, not at the digest level
- note the fixed behaviour, and clarify when it will/will not work
- add coverage for all generated updates for `digest`s, including when
remapping a Go Modules update as a `digest`
- clarify that `filterInternalChecks` and
`applyMinimumReleaseAgeToDigestUpdate` should stay in sync
Co-authored-by: Claude Fable 5 <jamie.tanna+claude-code@mend.io>
As noted in #30714, and to make the Minimum Release Age page a
"one-stop-shop", we can generate the documentation accordingly.
Using an orange "maybe" for support helps nudge folks to checking which
registry they're using, and noting that it still doesn't necessarily
work, even if the Datasource supports it.
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
* docs: skip validation on JSON files that aren't Renovate config
As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.
Before we do that, we should opt-out JSON snippets that aren't anything
related to Renovate config.
* docs: don't validate invalid Renovate config
As it's intentionally referencing a manager that doesn't exist.
* docs: don't validate partial Renovate config
As part of future changes, we'll enable validation on all JSON code
snippets to run Config Validation.
There are several code snippets we have that are part of a Renovate JSON,
but it doesn't make sense to convert these to a fully passing config, as
it'd reduce clarity on what we're trying to explain.
* docs: convert `baseBranchPatterns` snippets to code blocks
So we can validate them.
* docs: make sure that `datasourceTemplate` is set
So this passes validation.
* docs: clarify that `force` is global config
As it may not be clear, so we can make it extra clear with a `.js` file,
and note that it's global self-hosted config.
* docs: make sure `packageRules` is an array
* docs: `matchBaseBranches` needs `baseBranchPatterns` to be set
* docs: correct typo for `prBodyColumns`
* docs: mark global config snippets as such
As part of future changes, we'll use this to detect whether it's global
self-hosted configuration.
* docs: make sure `packageRules` wraps its children
* docs: add `allowedHeaders`
* docs: ignore deprecation warnings
As part of future changes, we'll use this to note that we don't care
about the validation warnings.
* docs: make sure `customManagers` wraps its children
* docs: make sure `fleet` wraps its children
* docs: validate JSON snippets are valid Renovate config
To make sure that we're always presenting valid JSON configuration to
our users, we can validate them as part of `check-fenced-code`.
As well as configuration errors we can warn for warnings, but allow code
blocks to opt-out, for instance when there's a known deprecation
affecting the code block.
We need to make sure to set `allowedEnv` for various code snippets that
reference environment variables.
* docs(development): document fenced code block checks
* docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
As otherwise we see build failures i.e.
WARNING - Doc file 'modules/platform/gitlab/index.md' contains a link
'../../../self-hosted-configuration.md#autodiscoverrepoorder', but the doc
'self-hosted-configuration.md' does not contain an anchor '#autodiscoverrepoorder'.
This needs to be wrapped alongside all other options like `title`.
* fixup! docs: wrap `configType` and `ignoreConfigWarnings` in `{ ... }`
* ci: add local mkdocs-admonitions plugin for prettier to allow admonition preservation
* docs: remove uses of `prettier-ignore` for admonitions
* test: rather use await expect
* chore: use named group exclusively
As noted in #39090, MkDocs requires 4 spaces for indentation (in
particular, for nested lists) whereas our Prettier/markdownlint
configuration expects 2 spaces.
This means that when trying to use i.e. nested lists, we need to ignore
prettier and markdownlint, otherwise it fails.
To handle this, we can add a Markdown hook to override the indentation
level to 2 spaces.
This also requires we update:
- admonitions
- indented text in `index.md`
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* docs(presets): Define presets as reusable bits of JSON
Mention difference between included and custom presets too
* fix(docs): Use relative link to preset defaults
* Apply suggestions from code review
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
---------
Co-authored-by: Jamie Tanna <github@jamietanna.co.uk>
* 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>
* 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
* feat(manager/npm): pass --before to npm install when minimumReleaseAge is set
* use logger metadata
* Apply suggestion from @viceice
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
---------
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
This also makes sure that our URL fragments should be more consistent
over the years, as duplicate names (across parent and child options)
cannot clash.
This also corrects links from the code to include the new fragment.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
As we've had a few Discussions about it (bugs and feature requests), and
it'd be good to clarify how they work together, as well as future work
planned to integrate better.
As it was renamed in #39406, but looks like there were warnings we
didn't spot, which are now failing when the docs attempt to build with
these new changes.
Since rolling out the v42 Renovate release to the Mend Developer
Platform, we've been watching out for user reports for issues following
the addition of `security:minimumReleaseAgeNpm` in
`config:best-practices`.
In particular, two Discussions #39525 and #39477 are interesting cases
where a change from #39066 around `prCreation` has inadvertently caused
impact to PRs being created, as the CI needs to pass on the branch
before a PR is created (as intended by `prCreation=not-pending`).
However, these branches do not get CI running until there is a PR, which
means PRs will never be raised.
This partially reverts changes from #39066, #39116 and #38873, which
have been re-investigated since the reports.
Slightly surprising is the fact that the changes from #39066 have been
live on the Mend Developer Platform for a few weeks, but it wasn't
noticed until now, after the full rollout of v42.
Ahead of Renovate 42, where `minimumReleaseAge` is enforced by default
for `config:best-practices` users of npm, and an increase in users of
the functionality given recent supply chain attacks, we should add more
in-depth documentation about how it works, how to tune it, and how to
determine which datasources, registries, packages and `updateType`s
support it.
Co-authored-by: gpt-oss:20b <jamie.tanna+ollama@mend.io>
Maxime Brunet