[LRUG] Automated gem updates

Riccardo Tacconi rtacconi at gmail.com
Tue Jun 6 03:56:46 PDT 2017


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20170606/292ca1c3/attachment-0002.html>


More information about the Chat mailing list