When using `replacementNameTemplate` with Docker images that have pre-pinned
digests, the auto-replace logic was incorrectly entering the `currentDigestShort`
replacement branch even when the digest didn't need to be changed.
Since `currentDigest === newDigest`, the first digest replacement block was
skipped. But the `else if` checked only `currentDigestShort !== newDigest`,
which was true (e.g., "5fa2edb" !== "sha256:5fa2edb..."), causing it to replace
the short string with the full digest, corrupting the result to
"sha256:sha256:..." format.
The fix adds a guard condition to skip the `currentDigestShort` replacement
when the full `currentDigest` already matches `newDigest`.
Fixes#40169
As part of hardening the configuration around executing
`postUpgradeTasks` with `shell: true`, we can give self-hosted
administrators the opportunity to configure this.
This continues to be on-by-default to be non-breaking, but in the next
major version can be flipped to the safer option.
As part of future changes to ensure that `shell` is disabled by default,
we should first enforce this for our `postUpgradeTasks`, which are
user-controlled and are more likely to contain shell-interpolated
variables.
We need to add a new `shell` type to pass around, as it was previously
not optional.
As part of a future change, we'll add additional arguments, but don't
need to validate them in every test.
To make sure that it's clearer what these tests are validating, we'll
use `expect.objectContaining` to test a subset of the object keys.
* refactor: use unicode right-arrow for changes template
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* refactor: use unicode right-arrow for changes template
Signed-off-by: Adam Setch <adam.setch@outlook.com>
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
This will make sure that we're calling it for each release being
skipped/continued with, so we're reducing the log lines for duplicate
dependencies across the codebase.
* feat(dashboard): open all PR controls for schedule and status checks
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat(dashboard): open all pending schedule PRs
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat(dashboard): open all awaiting schedule PRs
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat(dashboard): open all awaiting schedule PRs
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* fix order
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat(dashboard): open all awaiting schedule PRs
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* Update read-only-issue-body.ts
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
As a way to make it more predictable what the possible states the
`result` in a given `Repository finished` log message can be, we can
wrap these into a type.
This requires a slight refactor where these are used to make sure that
Typescript is happy with the value being returned.
We can capture the common groups of errors (which are then present as a
`RepositoryResult`) and expose that to be used.
As noticed while working on changes in #39793, we were missing a couple
of repository results that will lead to a repository being treated as
disabled.
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* feat: add emojis for repo problem levels
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* incorporate feedback
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* incorporate feedback
Signed-off-by: Adam Setch <adam.setch@outlook.com>
* Update common.ts
* Update common.ts
* Update common.ts
---------
Signed-off-by: Adam Setch <adam.setch@outlook.com>
Now we have instrumented our Git operations with tracing, we can make
sure that users who are not using OpenTelemetry still get insights into
their Git operation usage using a debug log output.
Following how other insights are produced, we can introduce a new type
in `lib/util/stats` for `GitOperationStats`, which will track the
overall execution for each operation type, and output them in the same
style as we use for other timing reports.
At the end of a Renovate run, we'll then make sure that this is logged
into a debug log for further investigation.
To create the report, we can make sure that we introduce a new
OpenTelemetry `SpanProcessor`, which will run when we end our Run, and
store any Git operations in `GitOperationStats`.
This adapts code from GPT-4.1 and code from [0].
Co-authored-by: gpt-4.1 <jamie.tanna+github-copilot@mend.io>
[0]: https://github.com/yurisouza/monitoria-sdk/blob/ca9d751fa7c3a785a04f87b8966bb782b4617021/src/adapters/nestjs/span-duration-tracker.ts#L18-L27
As a means to provide more insight into how long package manager
extractions take when using instrumentation, we can wrap the individual
manager's extractions, as well as the filtering of packageFiles for each
manager.
As a means to provide more insight into how long package manager lookups
take when using instrumentation, we can wrap the fetching of updates in
a trace per manager.
As part of ongoing work to improve OpenTelemetry instrumentation of
Renovate in #38609, we can instrument our branch creation with the
branch name (and relevant Semantic Convention attributes) for
visibility.
When calling `extractDependencies`, we actually perform both `extract`
and `lookup` splits. However, we are instrumenting the whole method call
as the `extract` split, which results in incorrect tracing data.
To correct this, we can wrap the specific code responsible for the
extraction into `extract`, and then the separate code for `lookup`
accordingly.
This also makes sure that `emptyExtract` sets repository splits.
As part of ongoing work to improve OpenTelemetry instrumentation of
Renovate in #38609, we can improve our repository instrumentation by
using Semantic Convention attributes for the platform, repo and owner.
As part of a step towards better OpenTelemetry instrumentation as part
of #38609, we can start by introducing a known span attribute for the
repository "split" we're currently processing.
This requires a slight refactor of the `SpanOptions`, to use our custom
type, which enforces the `RenovateSplit` type when using the span name.
This adds it into each of the splits we currently instrument.
Co-authored-by: secustor <sebastian@poxhofer.at>
* test: add failing test for reading configFileNames from env
* fix: move configFileNames handling to shared config parsing
* feat: allow configFileNames to be set through env
* fix: move unit test from file to index
* test: add test for setting configFileNames through cli
* fix: fix merge
* test: use multiple config file names in tests
* test: add a length check after adding custom filenames
* feat: Cleanup mutexes before each run
* Update setup.ts
* Update mutex.spec.ts
* Update setup.ts
* Unmock mutex in deb datasource spec to prevent race condition
* Update index.spec.ts
* feat: add configValidationError option to log config validation errors as errors instead of warnings
* Moved `configValidationError` docs to correct file.
Adam Setch