dependabot/dependabot-core

🤖 Dependabot's core logic for creating update PR's.

dependabot-core's Issues

HELP WANTED! PHP updates misbehaving in containers

Dependabot has been having trouble updating large PHP repos, and I've been unable to debug it. I'm not an expert on PHP, or on containerisation, and would love your help.

All of the details should be present in this repo, which has instructions on how to replicate. If you can help fix the bug you will have my gratitude forever, as I'm pulling my hair out here!

My current best guess is that this is a disk space / memory issue, as it only occurs for large composer.json files, and only when running within a container. I could, however, be completely wrong, and the issue may be todo with a composer.json setting I'm missing.

Other points to note:

• Dependabot runs fine on this composer.json
• Dependabot runs fine on this composer.json

I got 2 comments back

Hey @greysteil

I closed a PR like this:

But I got 2 comments afterwards, maybe one is too much?

Cheers, Oskar

Grouped PR for packages that are released simultaneously

Hi i have an interesting proposal, I have recently used dependabot for managing my dependencies and i have this some sort of problem in scoped packages like @angular/* packages having multiple PRs wherein they are all released at the same time.

Hopefully you'll take time considering this since updating Angular with multiple PRs results in many queued CI tasks and too many PRs that needs to merged Although there have been an auto-merge setting but i prefer not to use it. It would be better if it can be configured per repo basis.

Support multi-module Maven projects

In a lot of (open source and enterprise) projects it is very common to create Maven multi-module projects. One can for example have a module for only domain classes, utils or interfaces meant for public consumption.

Dependencies (code dependencies, plugins etc) can be attached to any module, optionally overriding dependencies higher up in the hierarchy (often referred to as the build reactor in Maven terminology).

In order for dependabot to be useful to a lot of Java shops, this functionality must be implemented.

See this project for a sample.

[Question] Why so many versions ?

I took a look at https://github.com/dependabot/dependabot-core/blob/master/CHANGELOG.md and noticed that there is sometimes 10 versions a day. At Foundation we release a new version every 1 to 6 months (I admit this is not better).

So I wonder: is there any benefits for this release process ? Are you deploying dependabot 10 times a day ?

Thanks.

Pull in changelog for Rails

The method to show changelogs apparently doesn't work for Rails (example: alphagov/policy-publisher#172). They would be particularly useful there.

Support vendoring for Ruby

From @biow0lf on August 11, 2017 8:47

Hello,

I am using vendored gems in vendor/cache/. So, dependabot update gem in Gemfile.lock, but leave old gem file in vendor/cache/. Plus, not put new gem to vendor/cache/.

So, I think, run bundle pack and add changed files will enough.

Copied from original issue: dependabot/feedback#15

Include old version in PR titles

From @Floppy on June 2, 2017 13:1

It would be handy, when looking at a big list of PRs, to get a quick flavour of which updates are small and simple, and which are potentially complex. Including the old version number as well as the new one in the title would help with that. Pretty much exactly the text in the first line of the PR, in fact, would be great.

Copied from original issue: dependabot/feedback#8

Does dependabot support updating transitive dependencies in lockfiles?

I couldn't find this on the features page.

21-hour old conflict resolution not happened yet

From @Floppy on June 1, 2017 10:35

Just found a dependabot notification comment from 21 hours ago which hasn't yet resolved the conflict.

Not sure if it's because I linked it to another issue (#1 here), so perhaps dependabot thinks I've changed it and has stopped updating it?

theodi/static#237

Copied from original issue: dependabot/feedback#7

Git submodules

From @Floppy on May 31, 2017 9:58

Probably a low priority niche use case, but a new "language" for updating git submodule versions would be incredibly useful (at least for me).

I have a number of Jekyll sites that include content from other repositories via submodules: https://github.com/SomethingNewUK/somethingnewuk.github.io/ is probably the most complex of those, with about 4 submodules in various subdirectories.

User story attempt:

As a website maintainer who does silly things with Jekyll
I would like to be able to add a "git submodule" language to a repository
So that I can get an automatic PR created when the submodule's repository has been updated

Copied from original issue: dependabot/feedback#4

[Feature request] Automatically upgrade dependencies, not only version number

1. Request

It would be nice, if would be possible upgrade dependencies, not only version numbers in requirements file.

For example, it would be nice add an option, that bot will run command after each version changing in requirements file.

2. Steps to reproduce

I develop plugins for Sublime Text, written on Python. By technical reasons I need add dependencies to my repository.

In my repository for testing I add outdated version of PyPI gsearch module to requirements.txt file. I use command:

pip install -r requirements.txt -t . --upgrade

3. Justification

Automatically dependencies upgrading may save developers time.

I test Dependabot on my test repository. Dependabot only change dependency version in requirements.txt file, but not upgrade my gsearch dependency, that I include to my repository.

I need upgrade my dependency manually; after merging I need run command again:

pip install -r requirements.txt -t . --upgrade

It would be nice, if Dependabot will run this command automatically after each version change in requirements.txt file.

Thanks.

Use AngularJS commit message conventions

Using AngularJS commit message conventions for dependabot would allow for automatic changelog creation using coventional-changelog (and other associated tools).

For dependabot commits, this would look something like

chore(node): bump #{dependency.name} from #{previous_version(dependency)} to {new_version(dependency)}

CURRENT COMMIT DETAIL GOES HERE

I am able to make the changes required in message_builder.rb, but I would like to hear your opinion on my suggestion before I do any work.

Does dependabot support making conventional commits when updating?

I couldn't find this on the docs page.
I.e. when the update was a semver-patch update, prefix the commit message with fix: , if it was a semver-minor update, prefix the commit message with feat: , if it was a semver-major update use chore: . That allows automatic semantic releases of the depending module

https://conventionalcommits.org/

Add support for C#

From @evenh on October 28, 2017 15:26

This seems like a great product for the company I work at, but almost all our projects are written in Java (Maven) or C#/.NET. Is there any plans to support this? :-)

Copied from original issue: dependabot/feedback#33

Update Ruby versions

From @Floppy on May 31, 2017 9:52

Some repos will have ruby version specified in the Gemfile, travis.yml, or .ruby-version (and there are probably others). It would be dead handy to have dependabot update these at least with patch or minor versions, so we don't miss a new release :)

Copied from original issue: dependabot/feedback#3

Changelog within PR

We're running a trial of dependabot on some of the GOV.UK repos at the moment. Would you be open to us creating a PR for dependabot-core which pulls the dependancy changes into the PR creator, rather than linking out to the changesets?

It's something that we feel would be a better experience for PR reviewers and also addresses a risk around the changesets being edited in dependant repositories. Wanted to get your thoughts on this before we cut any code.

Abstract github specifics to allow support for gitlab, bitbucket, etc

Would be nice to make the repository provider modular to allow support for other options (eg. gitlab or bitbucket)
I think it shouldn't be too difficult to make a generic "git repo client" class which presents the required features for dependabot-core on all of the above.

Allow weekly updates

From @pezholio on May 31, 2017 9:50

For some, a daily update might be a bit too noisy and distracting. It might be nice to offer a weekly update frequency, then users can schedule a time every week to check over and merge dependency updates.

Copied from original issue: dependabot/feedback#2

Option for single pull request per update

From @zach-taylor on June 20, 2017 18:37

We use deppbot (https://www.deppbot.com) at the moment and we like the idea of a single pull request for each update rather than a pull request for each gem update. The main reason we like this is we have a lot of dependencies, and it can get noisy and slow to perform a build for each one and the way our branch protections are set up.

Thanks for the consideration!

Copied from original issue: dependabot/feedback#11

Conflict resolution updates can be a bit noisy

From @Floppy on June 1, 2017 10:29

I'm updating a lot of stuff in one go, so this might be irrelevant for most users, but I find the conflict resolution comment to be unnecessarily noisy. Github already warns me that there are conflicts and won't let me merge, and dependabot is usually only a couple of minutes behind, so I'm not sure I really need a comment (lovely and polite though it is). I'm not in a "normal use" mode yet though, more of a "huge numbers of updates" mode, so this might not be a problem normally. Just raising in case others feel the same really. Perhaps an option to enable/disable them?

Copied from original issue: dependabot/feedback#6

yarn major/minor/patch upgrade flags

Could be interesting to add support for this yarn feature:
yarnpkg/yarn@1522cde

I think some of the teams here might use it.

Support multiple gemfiles

From @deivid-rodriguez on November 19, 2017 18:44

Some projects use multiple gemfiles. The main use case I know for this is to be able to test libraries against different major versions of dependencies.

Does dependabot support this kind of setups?

Copied from original issue: dependabot/feedback#51

Support Gradle Projects

things to consider here:

• map style notation: compile group: 'com.google.code.guice', name: 'guice', version: '1.0'
• short notation: compile 'commons-lang:commons-lang:2.6'
• different quotation marks (both " and ' are allowed)
• multi module projects

Support sbt projects

Hey,
it would be awesome to support sbt dependencies and plugin dependencies as well.

https://www.scala-sbt.org/1.x/docs/Library-Dependencies.html
https://www.scala-sbt.org/1.x/docs/Using-Plugins.html

Multi-projects are supported in sbt as well and is a common use case so that should be considered as well: https://www.scala-sbt.org/1.x/docs/Multi-Project.html

< version specifiers

From @Floppy on May 31, 2017 9:41

(I've filed this via email but I thought I'd christen the new issue tracker too)

I’ve got a few old repos where we were locking foreman at < 0.64. As it turns out, this isn’t necessary any more but dependabot is changing that to the current version, but still with the < specifier. So the update says 0.84, but the Gemfile now says < 0.84 (i.e. 0.83). Not sure what the right solution is really, but thought you’d like to know :)

Example change at theodi/static#237

Copied from original issue: dependabot/feedback#1

yarn.lock as generated by Dependabot is not optimal

This is part of a pull request created by Dependabot, and while this installs perfectly fine, I would expect `doctrine@^2.0.0, doctrine@^2.0.2:` to change into `doctrine@^2.0.0, doctrine@^2.1.0:`, so that only 2.1.0 is installed, instead of the current 2.0.2 and 2.1.0

doctrine is a dependency of eslint, that updated from 4.15.0 to 4.16.0

Archived repositories should be excluded

Since GitHub let archiving repos (and GitLab too), dependabot should take care of the archived property to:

• Avoid listing archived repo when creating a new dependabot project.
• Kill any attempt to bump dependencies on an archived repo.

🌈

Repo not getting scanned?

Hi!

I've tried setting up evenh/coffeebot for dependency bumping, but it seems like it is never getting scanned (just stuck in a queue)?

Add support for C# / NetStandard

Hi Guys, nice job with this.
Are you thinking about adding support for C# projects?

Allow JavaScript projects without a lockfile

From @nblackburn on June 6, 2017 15:34

As it stands, Yarn is required but i feel it should be optional just as yarn is.

Copied from original issue: dependabot/feedback#9

bumped manually, but no PR

locally I got an update for this package:

Package operations: 0 installs, 1 update, 0 removals
  - Updating sebastian/comparator (2.1.0 => 2.1.1): Downloading (100%)

but no PR by dependabot. Maybe thats because it is not a direct dependency?

For Debugging, this is my composer.json|.lock:
https://gist.github.com/OskarStark/21ad0cb2c0001f417833f52f5ecd4bb0

[question] ignore package names or wildcards

Some packages I want to keep at a specific version. I'd rather not receive PRs for these packages. Is it currently possible?

Update Peer dependencies

Hey guys,
we are using dependabot for some time, thx for nice service. But we are missing one feature. Dependabot doesn't updates peer dependencies and we need to do it manually each time.

Does it make sense to add support of it?

Thx

Lerna support

From @sobolevn on November 10, 2017 5:49

Seems like right now all files inside packages are ignored.

Each folder inside packages could contain its own package.json.
It would be really nice to have it updated.

For the reference: https://github.com/wemake-services/remark-lint-are-links-valid

Copied from original issue: dependabot/feedback#37

Which Mailaddress do you use?

Which Mailaddress do you use for the commits? Could you associate it which the Bot-Account to get the avatar?

Wrong version

This is written down in my composer.json

"sensio/framework-extra-bundle": "^3.0.2",

this means, that everything below 3.1 is allowed. Why do I get a PR like this?

you need to take care of semantic versioning

Hi @greysteil

lets take this picture as base of the conversation:

I defined ^2.5 in my composer.json to allow the following versions:

2.5.1
...
2.99.99 etc.

I am totally fine by upgrading to 2.5.14 in my composer.lock but not by changing the constraint itself in composer.json.

Because from now on, I cannot run composer update on my local machine AND you change the constraint, because now the allowed versions does not contain 2.6, 2.7.... but they were allowed before 😢

So we are back on #161 😄

Cheers, Oskar

Add badges

From @sobolevn on November 17, 2017 9:16

I want to inform my users, that dependencies are up-to-date.

The easiest way to do it, as for me, is a badge. Something similar to:

Do you have any plans to support this feature?

Copied from original issue: dependabot/feedback#49

Does not propose updates for dependent gems?

From @rdunlop on September 21, 2017 15:54

In my project, I have capybara in my Gemfile, which depends upon nokogiri >= 1.3.3.

Currently, I have nokogiri (1.8.0) installed.

Why hasn't dependabot prompted me to install nokogiri 1.8.1?

Doing bundle update nokogiri locally does succeed in creating a new Gemfile.lockwith an updated version ofnokogiriandmini_portile2`

Copied from original issue: dependabot/feedback#22

Invalid JSON in package.json results in Dependabot closing pull requests

I was foolish enough to commit directly to master and i accidentally typed part of the commit message into package.json. Needless to say, this meant the JSON was invalid. The result: Dependabot closed the one pull request that was still open, stating it detected that the dependency is now up to date and the PR is no longer needed.

So this seems to be a small bug which occurs when it tries to parse invalid JSON. Or, of course, it's completely unrelated and the timing is just coincidental... you never really know.

If you type my github username in your email client you'll find previous conversations which will direct you to our github organisation, the repository in question ends with -Tests and the pull request number is 47. Hopefully you'll be able to pull some data and fix this if it really is caused by invalid JSON.

Dependabot opened a PR with no files changed

We currently have an open pr with an empty commit by dependabot. I'm not sure why it happened (the commit message etc seems to be fine). There are two other PRs open in which only the lock file was updated, not the package.json - but I was told this has to do with carets (^) before our versions and an opt-in feature of dependabot. I'm not aware of any changes on our end, so this might be a bug as well?

You have had previous conversations with @StephanBijzitter - you should be able to find our github organisation, the repository in question ends with -Frontend and the pull request number is 512.

Authentication Error

Tried to sign in with github and it said it fails

2 dependencies should be updated

Hey @greysteil

I manually bumped my repo but I got no PR.

locally I got this:

Can you please check this?

Dependabot couldn't find a package.json for this project

Dependabot couldn't find a package.json for this project.

Dependabot requires a package.json to evaluate your project's current Javascript dependencies. It had expected to find one at the path: /helpers/javascript/package.json.

If this isn't a Javascript project, or if it is a library, you may wish to disable updates for it from within Dependabot.

You can mention @dependabot in the comments below to contact the Dependabot team.

Not updating package.json

In a recent PR I merged from Dependabot I've noticed that it has only updated my Yarn lockfile, not my package.json. Is this a bug or new behaviour?

If it is new behaviour, it would be nice to at least be able to opt into the old behaviour.

Add dependabot badge

Other services use a badge to show that the service is enabled for a certain GitHub repository. It might be a good way to increase awareness of dependabot by adding badges, showing that dependabot is enabled for a repo.

It could just be something as simple as a static badge like

When first enabling dependabot on a repo, the first PR could add the badge to the README.

Question about the commit message

Why do you start the commit message with:
chore(dependencies): ...

Is there a specific reason or could you make it configurable?

Handle upgrades that require upgrading multiple dependencies at once

From @greysteil on May 31, 2017 10:0

On a lot of old repos, we see Gemfiles with something like the below:

gem "rails", "~> 4.1"
gem "sass-rails", "~> 4.1"

To upgrade either of the dependencies in the above Gemfile, we need to update both, because sass-rails version 5 depends on the rails version being 5.

The right way to handle the above is to put in a PR upgrading both of the above, with clear details of both updates.

Copied from original issue: dependabot/feedback#5

Feature request: only update yarn.lock or package-lock.json if the version is within range

We're going to open source some of our tooling we've been using internally and to provide smaller download sizes (and bundles in case it's meant for the browser), we want to keep the ranges as open as possible for our users, leveraging yarn's deduping.

For example, this means we'd like to keep our package.json at ^1.0.0 for a dependency while our yarn.lock could already lock to 1.2.3.

This will still allow development of the projects to be done with constant updates, without bothering our users. It's not too big of an issue since we can just tell Dependabot to ignore the dependency until the next major release, though.

For us, this would be a bonus; certainly not a requirement.
(we're very happy with Dependabot already)