* fix(config/global): return default values for `GlobalConfig.get`
As noted in #39949, it can be awkward working with in `GlobalConfig.get`, where
we would previously need to specify the default value when calling `.get`,
which could lead to drift with the defaults for a given config option.
To reduce this risk, we can rely on a given `default` for a configuration
option, providing that as a default.
Because this now definitely returns a value that matches the config option, it
now allows us to remove `!` assertions.
* fixup! fix(config/global): return default values for `GlobalConfig.get`
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
* fixup! fix(config/global): return default values for `GlobalConfig.get`
* test(presets): remove impossible test
As it's now not possible to set a value as `undefined` (as
`GlobalConfig` will then use the default), this test no longer validates
anything.
* test(workers/repository): add mock
Now `platform` defaults to `github`, we need to mock out the call to
fetch config.
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test: coverage
* test: coverage
---------
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
* test(noNewURL): add new rule enforcing parseUrl() from 'lib/util/url.ts'
* replace newURL with parseUrl
* remove non-null assertions marks if appropiate
* test: add additional tests
* test: add additional tests and ignore where it makes sense
* implement suggestions
* test: further improve coverage
* apply suggestion
* fix(github): set commit message explicitly for platform automerge
When GitHub's "Use PR title and body as commit message" setting is
enabled, the verbose Renovate PR description gets used as the squash
commit body. Pass `commitHeadline` and `commitBody` to the
`enablePullRequestAutoMerge` GraphQL mutation so the actual commit
message is used instead.
* add REBASE test
* pr feedback
* fix: Add `github-digest` to `GITHUB_API_USING_HOST_TYPES` list
* fix(http): detect x-access-token prefix before hostType-based auth branching
Moves GitHub App installation token detection (`x-access-token:` prefix)
before the hostType-based authorization chain in `applyAuthorization`.
This ensures correct `token` scheme auth for any GitHub-related hostType,
not only those listed in `GITHUB_API_USING_HOST_TYPES`.
* test(http/auth): add regression test for GitHub App token with non-listed hostType
* Fixes
* Fix tests
* feat(vulnerabilities): add support for github-actions vulnerability alerts
* fix failed merge from main
* now for real
* review comments
* remove no longer needed assertion
As part of efforts to improve the performance of the `getPrCache`
function, we can add additional instrumentation to understand the time
taken.
This adds additional insight through our instrumentation functions, for
those using OpenTelemetry, as well as a `durationMs` for our logs.
* fix(github): prevent PR cache sync from exhausting all pages
* refactor(github): derive cutoff from cached items, simplify reconcile
- When lastModified is missing but items exist (via updateItem()),
derive cutoff from max(item.updated_at) instead of falling back
to reconcile's return value. Eliminates the fallback branch.
- reconcile() now called purely for side effects; return value ignored.
- MAX_SYNC_PAGES guard checks needNextPageSync (not needNextPageFetch)
to avoid spurious warning when cutoff already stopped the loop.
- Add test for mixed pages (Renovate + non-Renovate PRs interleaved).
- Update derived-cutoff test for caches without lastModified.
* fix(github): advance PR cache watermark from unfiltered page
* fix(github): add comment clarifying MAX_SYNC_PAGES is a safety net
As part of #39309 we enabled "Vigilant Mode" for the `@renovate-bot`
author.
To give an indication to folks who are self-hosting (on GitHub.com) and
using this Git commit author, we can provide a log message to let them
know.
This does not at all stop usage of this default committer email address,
but does provide a "nudge" to folks that they may see `Unverified`
commits pop up.
* use branchPrefix if multiple base branches expected
* fix test
* fix coverage
* apply suggestions
* apply suggestions
* use utility fn
* refactor tests
* fix test
* major overhaul: use baseBranches field internally
suggested by @secustor
* refactor: cleanup
* test: use better descriptions
* add tests
* fix logic
* fix test
* exclude unlisted versions when finding latestStable
---------
Co-authored-by: Rhys Arkins <rhys@arkins.net>
* fix: Use SHA of fresh branches when reopening PR
* Revert
* Add force push for differing local and PR commit SHAs
* Update GitHub PR reopening with local SHA
* Update GitHub platform PR reopening logic
* Fix
* Remove title-related changes, keep only force-push logic
According to the [GitHub Docs](https://docs.github.com/en/rest/repos/rules?apiVersion=2022-11-28#get-rules-for-a-branch), the definition of the non_fast_forward ruleset is: “Prevent users with push access from force pushing to refs.”
Even if this ruleset is applied, a head branch that lags behind the base branch can still be merged normally. In other words, this ruleset has nothing to do with whether a rebase is required.
Sebastian Poxhofer