[LRUG] Automated gem updates

Tue Jun 6 03:53:43 PDT 2017

Having used it for a week now, and not being one of the developers, let me give my perspective :)

It’s *super useful* for updating those sort of dependencies as it does one gem per PR, and over time will slowly creep your app forward, letting you resolve one problem at a time. I’m doing exactly that on a bunch of old apps that have exactly that sort of dependency chain, and it’s working great. There might well be something it can’t resolve, but that will become clear once the rest are done. It’s probably not perfect but I’m finding it useful, for sure.

As for making sure things don’t break, well… you’ve got tests right? ;)

cheers,
James Smith

On 6 June 2017 at 11:49:09, Jesse Waites (jesse.waites at gmail.com) wrote:

I'm not understanding quite how this will work in a real world situation. For example, I tried to add rails_admin to a project last
week. Turns out that rails_admin depends on Kaminari, which uses the same helper as some other pagination system I had already installed. Solving that problem was a pain. 

It seems to me that, especially in older rails applications, things end up in kind of a delicate situation. X gem has a dependency on Y gem no higher than the 1,5 version, which means I have to use an older version of X because Z gem depends on it... Hopefully some of you have experienced this and know what I mean. So in situations like that, I'm not sure how useful automating it would be. But I guess you could just lock those and automatically update everything else?

I'm also wondering how you could be sure the app doesn't due to updating gems from this tool. 

On Wed, May 31, 2017 at 6:07 AM, Harry Marr <harry.marr at gmail.com> wrote:
Yes - good point Ben. Using Snyk would definitely mitigate the risk of moving to less regular updating. We'll get weekly updating implemented ASAP :-)

On Wed, May 31, 2017 at 11:02 AM, Ben Lovell <benjamin.lovell at gmail.com> wrote:

On 31 May 2017 at 10:59, Harry Marr <harry.marr at gmail.com> wrote:
Thanks Stuart!

We’ve had it running with some of the ODI gems, and it’s a tad noisy to get PRs on a daily basis. Could there be an option to do it weekly?

The advantage of daily bumping is you'll pull in vulnerability fixes faster,

Snyk https://snyk.io/ is worth an honourable mention here.

but I can definitely see the argument for a less noisy mode though, so we'll add weekly bumping as an option. Longer term we may keep track of vulnerabilities, which would let us bump vulnerable gems immediately, while doing the standard bumping run less regularly.

I’ve also noticed that it seems to default to only one organisation, and I can’t seem to work out how to manage personal repos or any other orgs?

This is because we're using GitHub's new apps API (formerly known as integrations). Unlike traditional OAuth integrations, you install the app to each GitHub account (org or your personal account) individually, and can give access to only specific repos within the account.

To add accounts to Dependabot, click the dropdown in the top right and select "Add account". We're aware this is not totally intuitive, so we'll have a think about how we could make it clearer!

Thanks again - that's really helpful feedback.

On Wed, May 31, 2017 at 9:31 AM, Stuart Harrison <pezholio at gmail.com> wrote:
I love this, thank you! (for the record, I worked with James at the Open Data Institute on Bimble)

We’ve had it running with some of the ODI gems, and it’s a tad noisy to get PRs on a daily basis. Could there be an option to do it weekly? When I was at the ODI, this is what we did with Bimble, and this meant we had some time scheduled to review all the updates, check the tests passed and merge.

I’ve also noticed that it seems to default to only one organisation, and I can’t seem to work out how to manage personal repos or any other orgs?

Other than that, it looks awesome! :)

On 30 May 2017 at 21:11:00, Mark Burns (markthedeveloper at gmail.com) wrote:

I think if I used this, I'd like the option to update dependencies of dependencies. Otherwise, you may have a false sense of security. Other tools would still flag them leaving it as a manual step.

Perhaps the dependency chain to your app's dependencies could be highlighted in the PR description. The title could also be different to make it less confusing.
On Tue, 30 May 2017 at 23:48, Harry Marr <harry.marr at gmail.com> wrote:
Thanks James, I'm glad you find it useful!

So far we've deferred doing anything with git dependencies (including those specified in the Gemfile), but we're very aware we'll need to tackle them at some point! Handling dependencies that specify a tag would be tough - everyone uses different tagging schemes, and just using the most recently created could be dangerous - but dealing with branches should be relatively easy.

On Tue, 30 May 2017 at 14:32, James Smith <james at floppy.org.uk> wrote:
Harry, 

This is bloody brilliant, thankyou. We wrote something similar at the Open Data Institute to do dependencies for us (https://github.com/theodi/bimble), and always meant to turn it into a proper SaaS thing, but never got time. Thankyou for doing it so we don’t have to :)

I’ll give you bonus points if you can do git submodules too :)

cheers,
James Smith

On 30 May 2017 at 14:08:31, Harry Marr (harry.marr at gmail.com) wrote:

El Rug, hola!

A friend and I just released Dependabot, a tool (built in Ruby) for automatically keeping Ruby & JS dependencies up-to-date. We'd love any feedback -- does this match your ideal flow for keeping your Gemfile{,.lock} up-to-date? If not, what would you like to see it do differently?

Currently it'll run each morning and create a GitHub PR for each dependency that needs bumping. We've seen other tools that submit one big PR for all updates, but we found those PRs much harder to review, and much risker to merge. That said, more PRs is a bit noisier, so there is a tradeoff.

Another thing to note: we won't proactively bump sub-dependencies - they only get bumped when the top-level dependency gets updated (e.g. arel will only get updated when activerecord or rails gets updated). I'd particularly like to hear thoughts on this one. If we did bump sub-dependencies, the volume of PRs would dramatically increase, and could be quite confusing ("what's loofah?! oh, a sub-sub-dependency of rails...."). However, not bumping means we could miss out on important patches.

We also wrote up a few blog posts explaining:
what Dependabot is,
why we think staying up-to-date is worthwhile,
and the impact of staying up-to-date on responding to security issues
Look forward to hearing your thoughts!

Harry
_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org
_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org

_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org

_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org

_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org

_______________________________________________
Chat mailing list
Chat at lists.lrug.org
Archives: http://lists.lrug.org/pipermail/chat-lrug.org
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org

--
Jesse Waites
Web Developer
JesseWaites.com
_______________________________________________  
Chat mailing list  
Chat at lists.lrug.org  
Archives: http://lists.lrug.org/pipermail/chat-lrug.org  
Manage your subscription: http://lists.lrug.org/options.cgi/chat-lrug.org  
List info: http://lists.lrug.org/listinfo.cgi/chat-lrug.org  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20170606/c20d33d6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Message signed with OpenPGP using AMPGpg
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20170606/c20d33d6/attachment.sig>