mirror of
https://github.com/renovatebot/renovate.git
synced 2026-10-27 07:50:47 +00:00
4b4d14ec00
* feat(manager): pass extracted constraints to updateArtifacts `extractedConstraints` were collected during extraction but only ever read by `fetch.ts` for the lookup. At artifact time every manager had to derive the same tool constraints a second time, and when the updated package file no longer carried the constraint there was nothing to fall back to. `generateBranchConfig()` now merges the `extractedConstraints` of all upgrades of a branch onto the branch config, which reaches `updateArtifacts()` through `patchConfigForArtifactsUpdate()`. `UpdateArtifactsConfig` declares the field and documents what it contains. The new `resolveToolConstraint()` helper implements the ladder once: user `constraints` > an optional artifact-time derivation > the extracted value. The derivation is ranked above the extracted value on purpose: it reads the package files as the branch changed them, so poetry (python is an updatable dependency there), composer, pipenv (`pipenv` can be a dev package) and pep621 (`requires-python` is an updatable dependency) would otherwise regress to a stale constraint. pipenv, pep621 uv/pdm, poetry and composer are migrated to the helper and keep their derivation. Behaviour change: these managers now use the extract-time constraint as a last resort instead of running unconstrained, for example on lock file maintenance where pipenv deletes `Pipfile.lock` before deriving. `execute-post-upgrade-commands.ts` is unaffected: it reads `upgrade.constraints` per upgrade, and the extracted values are kept in a separate field rather than folded into `constraints`, so post-upgrade task tool constraints still come from user config only. Not migrated, because their constraints are never extracted, so the fallback would be dead code: bundler (`ruby`/`bundler`), pixi (`pixi`), pep621 uv (`required-version`) and npm's node ladder, whose last step already reads `package.json` engines. * refactor(manager): resolve tool constraints through resolveToolConstraint() Every manager now obtains the constraint of a tool it runs through `resolveToolConstraint()` instead of reading `config.constraints` itself, so the precedence "user config, then a value derived from the updated files, then the constraints collected during extraction" applies everywhere. The helper treats an empty string as not set at every step and accepts the `PostUpdateConfig` shape, whose `constraints` may be `null`. Behaviour changes that go beyond the new fallback to extracted constraints: - `mix` applies its hardcoded erlang default only after the extracted constraint, so an erlang version collected at extraction can win over it. - `kustomize` decides `HELM_EXPERIMENTAL_OCI` from the fully resolved helm constraint; `generateHelmEnvs()` takes that value instead of the config. - `npm` (yarn): an upgrade of yarn without a new value now consults the user constraint before deriving one from package.json or the lock file. - The "Using <tool> constraint from config" debug lines in bundler, composer, copier and pip-compile are gone, as the helper is the only reader of the config now. Helpers that read the config synchronously became async: bundler `getBundlerConstraint()`, copier `getPythonVersionConstraint()` and `getCopierVersionConstraint()`, pip-compile `get*VersionConstraint()` and `getToolVersionConstraint()`, gomod `deriveGoToolchainConstraints()` and `getUpdateImportPathCmds()`, mise `getMiseLockToolConstraints()`. composer `getPhpConstraint()` is removed. Each converted manager has a test showing the extracted constraint reaching the executed tool, and, where a derive callback exists, that the derived value still wins over it. * refactor(linters): add prefer-resolve-tool-constraint rule Reports member reads and destructuring of `constraints` and `extractedConstraints` from a manager config in `lib/modules/manager/**`, so that tool constraints are resolved through `resolveToolConstraint()` in `lib/modules/manager/util.ts` only. Writes and the same properties on package files, which extraction has to populate, are not reported. The helper itself and spec files are exempt in `.oxlintrc.json`. * refactor(manager): inline thin resolveToolConstraint wrappers Drop copier/utils.ts and the pip-compile getPipToolsVersionConstraint / getUvVersionConstraint helpers, which only forwarded to resolveToolConstraint(). Callers now call it directly. * docs(development): note lock file maintenance in tool constraints section * refactor(manager): address review on tool constraint resolution composer only runs extractConstraints() when a user constraint is missing, via Lazy. UpdateArtifactsConfig no longer re-declares constraints and extractedConstraints, which ToolConstraintsConfig already provides.
107 lines
3.6 KiB
TypeScript
107 lines
3.6 KiB
TypeScript
import { isNonEmptyString } from '@sindresorhus/is';
|
|
import type { MaybePromise } from '../../types/index.ts';
|
|
import { detectPlatform } from '../../util/common.ts';
|
|
import type { ExecError } from '../../util/exec/exec-error.ts';
|
|
import type { ConstraintName } from '../../util/exec/types.ts';
|
|
import { parseGitUrl } from '../../util/git/url.ts';
|
|
import { GitRefsDatasource } from '../datasource/git-refs/index.ts';
|
|
import { GitTagsDatasource } from '../datasource/git-tags/index.ts';
|
|
import { GithubTagsDatasource } from '../datasource/github-tags/index.ts';
|
|
import { GitlabTagsDatasource } from '../datasource/gitlab-tags/index.ts';
|
|
import type { PackageDependency, ToolConstraintsConfig } from './types.ts';
|
|
|
|
export function applyGitSource(
|
|
dep: PackageDependency,
|
|
git: string,
|
|
rev: string | undefined,
|
|
tag: string | undefined,
|
|
branch: string | undefined,
|
|
): void {
|
|
if (tag) {
|
|
const platform = detectPlatform(git);
|
|
if (platform === 'github' || platform === 'gitlab') {
|
|
dep.datasource =
|
|
platform === 'github'
|
|
? GithubTagsDatasource.id
|
|
: GitlabTagsDatasource.id;
|
|
const { host, full_name } = parseGitUrl(git);
|
|
|
|
// Always use HTTPS for GitHub/GitLab API endpoints, even if the git URL protocol is SSH.
|
|
dep.registryUrls = [`https://${host}`];
|
|
dep.packageName = full_name;
|
|
} else {
|
|
dep.datasource = GitTagsDatasource.id;
|
|
dep.packageName = git;
|
|
}
|
|
dep.currentValue = tag;
|
|
dep.skipReason = undefined;
|
|
} else if (rev) {
|
|
dep.datasource = GitRefsDatasource.id;
|
|
dep.packageName = git;
|
|
dep.currentDigest = rev;
|
|
dep.replaceString = rev;
|
|
dep.skipReason = undefined;
|
|
} else {
|
|
dep.datasource = GitRefsDatasource.id;
|
|
dep.packageName = git;
|
|
dep.currentValue = branch;
|
|
dep.skipReason = branch ? 'git-dependency' : 'unspecified-version';
|
|
}
|
|
}
|
|
|
|
/**
|
|
* Given an {@link ExecError}, retrieve the message which will be used for an {@link ArtifactError}.
|
|
*
|
|
* An `ExecError` always carries a `stderr` property, so nullish coalescing would keep an empty string and render an artifact error with no message at all.
|
|
*
|
|
*/
|
|
export function artifactErrorMessageFromExecError(
|
|
err: Partial<ExecError>,
|
|
message: string,
|
|
): string {
|
|
if (err.stderr?.trim()) {
|
|
return err.stderr;
|
|
}
|
|
|
|
if (err.stdout?.trim()) {
|
|
return err.stdout;
|
|
}
|
|
|
|
return message;
|
|
}
|
|
|
|
/**
|
|
* Resolve the constraint for a tool that `updateArtifacts()` has to run.
|
|
*
|
|
* The precedence is:
|
|
*
|
|
* 1. `constraints`, because the user asked for it explicitly
|
|
* 2. `derive`, because it reads the package files as the branch changed them,
|
|
* so it can be newer than what extraction saw
|
|
* 3. `extractedConstraints`, as collected while extracting the base branch
|
|
*
|
|
* Managers that have no way to derive the constraint at artifact time can omit
|
|
* `derive`. An empty string counts as "not set" at every step, so it never
|
|
* shadows a value further down the list.
|
|
*
|
|
* This is the only place that reads `constraints` and `extractedConstraints`
|
|
* from the config; the `renovate/prefer-resolve-tool-constraint` lint rule
|
|
* keeps managers from reading them directly.
|
|
*/
|
|
export async function resolveToolConstraint(
|
|
config: ToolConstraintsConfig,
|
|
toolName: ConstraintName,
|
|
derive?: () => MaybePromise<string | null | undefined>,
|
|
): Promise<string | undefined> {
|
|
const configured = config.constraints?.[toolName];
|
|
if (isNonEmptyString(configured)) {
|
|
return configured;
|
|
}
|
|
const derived = await derive?.();
|
|
if (isNonEmptyString(derived)) {
|
|
return derived;
|
|
}
|
|
const extracted = config.extractedConstraints?.[toolName];
|
|
return isNonEmptyString(extracted) ? extracted : undefined;
|
|
}
|