[LRUG] Automated gem updates

Jesse Waites jesse.waites at gmail.com
Wed May 31 04:32:07 PDT 2017 

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

More information about the Chat mailing list