Similar to how we already generate a list of the community actions we
support, we should also generate which first-party Actions from GitHub
are supported, and simplify some of the wording in the docs.
Instead of duplicating this, we can instead move them into a single
section in the documentation.
Co-authored-by: Claude Sonnet 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>
- Convert `param: T | undefined = undefined` to optional `param?: T`.
- Drop dead `= false` defaults on the required cache-provider options.
- Make `GraphqlPaginatedContent.nodes/edges` optional so the `= []`
fallbacks (load-bearing for partial GraphQL connections) are valid.
- Type the unchecked `default_branch` response field as optional so
the `'HEAD'` fallback is retained.
- Drop `tag = undefined` from the Forgejo/Gitea/GitLab preset configs.
Part of #43845
Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
As part of recent work around environment variable handling, it's clear
we should provide more user-facing documentation on how environment
variables are handled, and which are passed to child processes by
default.
We can create a "deep dive" page for this, with an autogenerated list of
the environment variables in `basicEnvVars` that are always passed to
child processes, if they're set.
We can also point self-hosted administrators and users alike to the
options they have to control this, too.
With help from GPT-4.1 for case-insensitive sorting.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
To provide more programmatic means to determine what environment
variables configure Renovate configuration options - and whether they're
Repo, Inherit or Global config options - we can expose these in two
forms:
- `getEnvOptionsMap()`
- a static JSON file, `renovate-env-options.ts`
This will provide programmatic use-cases from a plain JSON file that can
be used more readily - especially as it's distributed in the docs and
built package - as well as a function that can be used by users of
Renovate-as-a-library.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
In shared preset repositories, some users will use a mix of Inherit
Config and Repo Config options with the existing JSON Schema.
As part of Renovate 43, we're removing the ability for any global
options to be usable in Repo Config, which would also mean that it's now
either a case of "ignoring warnings in my editor" and "using Global
Config JSON Schema", which isn't a great option.
We can instead create a third JSON Schema, one which is focussed on
shared presets that can include Inherit Config options.
This makes it clear that the repo config's JSON Schema should not be
used for anything Inherit Config.
As part of future changes to introduce further typings for Commander
(#40546), we need to provide stronger types as the `version` will now be
typed.
We can erase the `SemVer` type, and pass around a `string`, instead as
it's not necessary to keep.
As noted in #38727, it would be convenient to distribute a separate JSON
Schema that is explicitly for "global" / "admin" / "self-hosted"
configuration, separate to the repository configuration in our current
`renovate-schema.json`.
This gets wired in as an additional JSON file, and will have a different
set of configuration options in the future, noted by the `isGlobal`.
Closes#38727.
fix(tools/json-schema): correctly set version in generated JSON Schema
In #38567 we tried to wire in the version of Renovate into the generated
JSON Schema. This unfortunately didn't work, as we don't have the
release number known at the time we're currently calling the JSON Schema
generation.
To fix this, we can make sure that at the point we're generating the
JSON Schema as part of the release process, we can wire in the version
as part of `generateSchema`.
Jamie Tanna