Our intent for `onboardingAutoCloseAge` would be that the global
config would take precedence over the inherited config value.
Our implementation missed this, which means that inherited config could
then override the value, including disabling it.
To correct this, we can make sure that when using `getInheritedOrGlobal`
we only allow the inherit config option if it is lower than the global
option.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
feat(logging): include PR number when detecting existing branch PR
Include the PR number in debug log messages when:
- An existing open branch PR is found ("Found existing branch PR #123")
- A closed PR already exists ("Closed PR #123 already exists")
This aids debugging by making it easier to correlate log entries with
specific PRs when reviewing Renovate logs.
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
To make sure that we're using secure defaults, we can make sure that
this is off-by-default.
Self-hosted administrators will be able to turn this back in if they
wish.
* feat: inherit support for onboardingAutoCloseAge
* reduce changes
* onboardingAutoCloseAgeLimit
* use global onboardingAutoCloseAge as limiter
* update
* revert extra changes
* afterAll
* fix: `workingDirTemplate` must be relative to the repo root
The `postUpgradeTasks.workingDirTemplate` did not work correctly,
as the working directory is the directory where Renovate is executed.
Thus prepend the paths with `localDir`, i.e. the repository root.
* refactor: use the return value of ensureLocalDir
The function already expands the path.
As noted in #40631, when autoclosing an onboarding PR due to age, we're
not marking the repository status as `closed-onboarding`, which means
the repository cache (and current status fo the repo) is not
appropriately updated, and a repository needs to be scanned again to
update accordingly.
We should throw this error when we've performed the auto-close, so
Renovate can then mark the status correctly.
As noted in #40627, when using a Repository Cache, the
onboardingAutoCloseAge does not trigger if the repository already has
its onboarding state already cached.
This is most prevalent in the Mend Developer Platform, where we heavily
cache our users' repositories, but leads to the fact that turning on
`onboardingAutoCloseAge` will take no effect.
To make this work, we can refactor how we handle `ensureOnboardingPr`,
to make sure that we still perform auto-closing even if the cache is
up-to-date.
Although not at the "rule of there", we can reduce code duplication for
`ensureOnboardingAutoCloseAge` by extracting a function.
As noted in #40604, we're seeing cases where we need to wait
`onboardingAutoCloseAge+1` days until the onboarding PR will be
auto-closed.
To fix this, we can refactor `getElapsedDays` to optionally return a
floating point number, which we can then perform more careful
calculations against.
As we're now being a little more careful with timings being used for our
date comparisons, we need to make sure that Vitest fakes our timer
during these tests.
Instead of long floating-point numbers, we should use a 2 decimal
place value for log messages, as they're more readable to humans.
To provide more information around the process used to determine whether
an onboarding PR will be auto-closed by `onboardingAutoCloseAge`, we can
add some more logs.
As part of future changes, we want to log the shallow configuration (the
full resolved configuration, but without any internal Renovate
configuration presets), where we'll want to note which presets have not
been merged in.
Before that, we can start with an initial refactor to indicate which
have been merged, and return them.
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>
Jamie Tanna