Adds basic support for renovating C# project files. The scope is initially limited to:
- .Csproj only (no VB.NET / F#)
- SDK style csproj's only (this is the default in .net core anyway)
- Limited to nuget.org support (no custom repository support)
Closes#935, Closes#2050
Adds a series of functions related to the commenting aspect of GitLab for the API wrapper. These functions are: `getComments`, `addComment`, `editComment`, `deleteComment`, `ensureComment` and `ensureCommentRemoval`.
Adds range support for composer. Mostly leverages existing npm semver range support, but massages where necessary to support Composer differences.
Closes#2097
This PR adds the feature of commenting on a failed automerge. It's done by adding a conditional in `lib/workers/branch/automerge.js` which, in case of receiving `failure` or `error` from the `getBranchStatus` function, returns the "branch status error" value. Another modification is in `lib/workers/branch/index.js`, which is an adition to the failure response of the `tryBranchAutomerge` function. The added functionality is the ability to add a comment to the PR which had a failure automerging. In case of receiving the aforementioned "branch status error" value, to the comment is appended a note which emphasize the fact that there're multiple failed status checks.
Closes#1934
Added permission checking on `initRepo` which, in case of an error, throws a clear message (`The token doesn't have the write permissions to the repository`)
Closes#509
This PR follows up and fixes#1968
The previous PR didn't behave correctly as it was expecting Github Enterprise to ALWAYS been configured and that the github.com token was available in the `GITHUB_COM_TOKEN` env variable.
But for non GHE project `GITHUB_COM_TOKEN` is not defined and github.com token is available at the `GITHUB_TOKEN` env variable instead.
This updated PR fix this issue and avoid further problems by prioritising `github.com` over GHE.
Now the code is NOOP if no `GITHUB_ENDPOINT` is configured.
If it's configured, instead, now the codes assumes that, by DEFAULT, a dependency is hosted on `github.com` so it removes `GITHUB_ENDPOINT` and use `GITHUB_COM_TOKEN` as Github token immediately.
They are restored only if needed, when a dependency is hosted on the provided GithubEnterprise.
This PR replaces the existing `pinVersions`, `upgradeInRange` and `versionStrategy` settings with a single one: `rangeStrategy`.
Previously:
- `pinVersions` could be `true` or `false`, but defaulted to `null`, which meant that Renovate would decide. `true` meant that Renovate would replace existing ranges like `^1.0.0` with an exact/pinned version such as `1.2.0`.
- `upgradeInRange` could be true or false, default to false. If `true`, it would mean Renovate would replace an existing range like `^1.0.0` with something like `^1.2.0`
- `versionStrategy` could be `replace` or `widen` and was mainly used for `peerDependencies` to widen existing ranges, e.g. from `^1.0.0` to `^1.0.0 || ^2.0.0`
It was possible to set conflicting settings, e.g. configuring `pinVersions=true` and `upgradeInRange=true`.
Now, we combine them into a single setting: `rangeStrategy`:
- `auto` = Renovate decides (this will be done on a manager-by-manager basis)
- `pin` = convert ranges to exact versions
- `bump` = same as `upgradeInRange` previously, e.g. bump the range even if the new version satisifies the existing range
- `replace` = Same as pinVersions === false && upgradeInRange === false, i.e. only replace the range if the new version falls outside it
- `widen` = Same as previous versionStrategy==='widen'
This PR adds support for pip changelog,
unlike npm, I couldn't find a mapping between github and pip other than github being used as the homepage of some projects, if there are other ways of mapping it would be helpful.
Closes#1911
This PR splits the logic behind changelog into manager (npm) and source (github)
the manager provides the repo url + versions
the source consumes the manager info and generates changelog info
Closes#1911
Adds a link to the latest version notes in the PR body, as well as a source compare link for all commits between the current version and the new version.
Closes#1876
Refactor changelog (commits) logic to separate sources, and remove the `changelog` dependency. Instead of a full copy/paste of commits, a link is now provided to the source repo.
Closes#381
Renovate now comes with a variety of package managers supported, each with their own filename pattern(s). These patterns are now exposed for user configuration through the new `fileMatch` list/array configuration option, which has been added to each manager (npm, bazel, docker-compose, etc). `fileMatch` is defined as a mergeable list, meaning that users can add to the default pattern to extend the files being detected.
Closes#799
Rules for dep types (e.g. dependencies, devDependencies, peerDependencies, optionalDependencies) should now be done with `packageRules` and the `depTypeList` selector
This PR adds basic support for requirements.txt. Currently it works on fully specified (pinned) versions only, so is disabled by default. Enable it by setting `pip_requirements.enabled = true` in config.
This PR adds initial support for buildkite plugin renovation.
It supports `plugin-name` or `my/plugin-name` plugins, and fully specified semver versions only (e.g. `v1.3.2`). Currently it will always propose an upgrade to the latest version available, e.g. if current version is v1.3.1 and both v1.3.2 and v2.0.0 exist then v2.0.0 will be proposed. Looks for any yml file in the `.buildkite/` directory.
Closes#1869
The matchCurrentVersion option sets a range of versions that a package update can be in. If the package's current version doesn't satisfy the matchCurrentVersion range, it won't match the rule.
Closes#1771
This PR refactors `branchName`, `commitMessage` and `prTitle` so that they are more easily editable and hopefully more understandable. By breaking each up into subsections, users can modify one part without needing to copy/paste the entire string.
Directly editing any of these fields will now be deprecated and a warning issued.
packageRules selectors should only ever be inside a packageRule object, or at the top level of a preset. This feature enforces this rule with a validation check.
Closes#1773
Adds a field `depTypeList` to `packageRules`, enabling rules for packages to be applied for any `depType`. Config objects `dependencies`, `devDependencies` and `peerDependencies` will be deprecated in favour of this new approach.
Closes#1807
Merges any static config from config.js with repositories list that is autodiscovered.
BREAKING CHANGE: Repositories in config.js will have their config combined with the autodiscover list and a warning if any statically configured repositories are not found.
No longer defaults to supportPolicy=[‘lts’] when supportPolicy is undefined.
BREAKING CHANGE: If you wish to use travis with supportPolicy=lts, then you need to explicitly set that in node or travis config.
Change default of pinVersions from null (autodetect) to false. Note: The preset “config:base” still reverts this to null/autodetect.
BREAKING CHANGE: pinVersions defaults to false. To switch back to autodetect, use preset “:autodetectPinVersions”, which is already included within “config:base”.
Removes hardcoded “fix” commitType from dependencies. Doing so allows for easier overriding without requiring complicated/deep presets or config.
BREAKING CHANGE: dependencies default semantic commit type now uses main config commit type (chore)
Changes the default onboarding config from `{ extends: [‘config:base’] }` to `{}` (empty). Self-hosted bot users can add it back by configuring `onboardingConfig` in `config.js` or env. Doing this makes the bot less “opinionated” by default and more convenient for self-hosted users, who can configured everything in config.js or env now.
Closes#1554
BREAKING CHANGE: onboarding config now defaults to empty config instead of config:base. Self-hosted users need to add it back if they with to retain it as default suggested config.
