[LRUG] Automated gem updates

Sun Jun 11 08:27:52 PDT 2017

I actually do a manual `bundle update` most days, push it to CI and see
what breaks.

Necessarily this means I hit a lot of bleeding edge incompatibilities.

Normally this can be fixed by adding a constraint to your gemfile (with a
comment), or possibly forking it and issuing a PR.

Of course, if you can't trust your test suite, this would be impossible.

`bundle outdated` is a good follow up,
To see if any of our pegged versions have been superseded.

This takes a bit of time every day.
But I think it's fun.

On Tue, 6 Jun 2017, 11:57 Riccardo Tacconi, <rtacconi at gmail.com> wrote:

> Jesse,
>
> It's a very good observation. I would automate minor version updates,
> which are supposed not to break anything - and it is not guaranteed - but I
> would not automatically automate major version unless I had 100% test
> coverage. Another important thing to mention is that I saw many times
> a 'relaxed' way to specify gem versions, moreover there are two ways of
> specifying gems' versions, one is 'relaxed' and using ~ the other is
> something like = 4.1.1. I usually prefer to specify major and minor, but I
> would definitely always update the patch number automatically.
>
> In the end, tests are very important.
>
> On 31 May 2017 at 12:32, 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
>>>>> <https://developer.github.com/apps/> API (formerly known as
>>>>> integrations
>>>>> <https://developer.github.com/changes/2017-04-25-Integrations-Pre-Release/>).
>>>>> 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 <https://dependabot.com/>,
>>>>>>>> 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
>>>>>>>>    <https://dependabot.com/blog/introducing-dependabot>,
>>>>>>>>    - why we think staying up-to-date is worthwhile
>>>>>>>>    <https://dependabot.com/blog/why-bother>,
>>>>>>>>    - and the impact of staying up-to-date on responding to
>>>>>>>>    security issues
>>>>>>>>    <https://dependabot.com/blog/the-latest-dependency-version-is-probably-the-most-secure>
>>>>>>>>
>>>>>>>> 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
>>
>>
>
>
> --
> Riccardo Tacconi
>
> _______________________________________________
> 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/20170611/005bc6a9/attachment-0003.html>