All PRs/branches will be shown in onboarding even if they have been scheduled for another day or time, providing a "full view" in the onboarding.
Closes#429
Collaborator
rarkins commented 14 hours ago
Base branch for Pull Requests is now configurable via a new baseBranch configuration option. To take effect, this much be present in the default branch (e.g. master in most cases) so that it can be discovered and used. See FAQ for more details.
Closes#443
A separate routine is run after branch creation to detect any branches that should be deleted. A branch will be removed if:
- It was not created by renovate in the last run, AND
- It has no PR, or its corresponding PR is not mergeable
Closes#426, Closes#428
This starts off [#359](https://github.com/singapore/renovate/issues/359) (configurable status checks) but only implements one sub-feature of it: disabling status checks to allow automerge if tests fail or if no tests are present.
Warnings and Errors are bubbled up when renovating a repository, together with the existing upgrades. The Onboarding PR ("Configure Renovate") now displays them and encourages the user to fix before merging/closing the PR.
Closes#414
This changes how group are configured to align with the new lock file configuration.
BREAKING CHANGE: old group* template options are no longer supported but can be migrated into group object
This feature now allows a custom schedule to be defined for lock file maintenance. It is now enabled by default but runs only before 5m on Sundays. Closes#399
BREAKING CHANGE: lock file maintenance is enabled by default.
Rules will apply to both yarn and npm (npm is yet to be implemented however). Existing mainainYarn* variables are removed and replaced by new lockFileMaintenance object.
No longer supporting preformatted (markdown) changelog input for templates.
BREAKING CHANGE: Preformatted {{changeloge}} no longer supported in PR body template.
Generate changelog using handlebars as in the default templtaes.
This PR adds a scheduling feature, including timezone support.
It's described in detail in the FAQ, but the summary is:
* Timezones can be defined so that schedules are written in timezone of target repository
* Schedules can be written in "plain english"
* Multiple schedules allowed
* Schedules can be defined all the way down to package level
Closes#387
