1416054 - Assess use of external addon Renovate in Mozilla's GitHub organization 'mozilla'

Status: RESOLVED FIXED

(mozilla.org :: Github: Administration, task)

Description

[Ed Morley [:emorley]]

I want to use the Renovate addon in 'mozilla' for the following reasons:

So we can use it to keep javascript NPM dependencies up to date, like we use https://pyup.io to keep Python deps up to date. It's a superior alternative to Greenkeeper, since it has non-hacky support for Yarn lockfiles.

Below are my answers to your stock questions:

** Which repositories do you want to have access? (all or list)

https://github.com/mozilla/treeherder

** Are any of those repositories private?

No

** Provide link to vendor's description of permissions needed and why

https://renovateapp.com/
https://renovateapp.com/docs/all-other/data-security

Install here:
https://github.com/apps/renovate/installations/new

Many thanks!

Comment 1

[Hal Wine [:hwine] use NI!]

[Being a bit verbose here, as we're trying to clarify our decision process.]

Since this is implemented as a GitHub App, there is no risk to other repositories in the organization.

I'm a bit surprised it requires code write access (I would have expected everything to be done via PRs). But if the repository admin is willing to assume that risk, that's not an org issue.

:gene - any concerns before we flip the switch?

Comment 2

[Ed Morley [:emorley]]

(In reply to Hal Wine [:hwine] (use NI) from comment #1)
> I'm a bit surprised it requires code write access (I would have expected
> everything to be done via PRs). 

If it's anything like https://pyup.io that we're already using, it will create branches for the PRs on the upstream repo rather than a fork (presumably to reduce the amount of state the tool has to track), which requires code write access.

Comment 3

[Hal Wine [:hwine] use NI!]

TIL - makes sense. And I guess it would make for a huge account on GitHub to hold all those forks. With co-mingled private repos. That's ugly, too.

Comment 4

[Osmose [:osmose, :mkelly]]

Any updates or ETA on this? I'd like to use this in the mozilla-services organization as well, but want to wait until we approve use in this bug here.

Comment 5

[Hal Wine [:hwine] use NI!]

(In reply to Michael Kelly [:mkelly,:Osmose] from comment #4)
> Any updates or ETA on this? I'd like to use this in the mozilla-services
> organization as well, but want to wait until we approve use in this bug here.

Mozilla-services is handled by a different team -- go ahead and make the request there.

Comment 6

[Hal Wine [:hwine] use NI!]

This has been enabled on the 'treeherder' repository.

(In reply to Hal Wine [:hwine] (use NI) from comment #1)
> [Being a bit verbose here, as we're trying to clarify our decision process.]

Off bug discussions have arrived at the decision that GitHub apps are up to each repository's admin team to decide on whether the risk is worth the reward.

I.e. any requests from a repo admin will be implemented.

> :gene - any concerns before we flip the switch?

We discussed offline.

Comment 7

[Ed Morley [:emorley]]

Thank you :-)

Comment 8

[Ed Morley [:emorley]]

In case this is of interest to anyone - there is also now another variant of the Renovate app, that creates PRs from it's own fork of repositories, so needs fewer permissions:
https://renovateapp.com/docs/all-other/data-security#github-permissions
https://github.com/apps/forking-renovate

...though it means:
(a) forgoing the auto-merge feature (should people want to use it for eg low risk linter updates that pass CI)
(b) making it harder to push your own changes to the PR, should a breaking version update need in-code changes for compatibility (even with the "allow maintainers to make edits" GitHub feature, this workflow is a pain given it requires HTTPS auth not SSH and manually creating remotes etc)