Discuss use of Greenkeeper in this repo

[valentijnnieman]

Had a brief discussion with @bpostlethwaite about Greenkeeper, and talked about removing it from this repo. My feelings on it are that Greenkeeper isn't super helpful for this repo at this point, because we are a bit behind on React versions. Seeing as most of the packages Greenkeeper will update are React dependant, more often than not the PR's that Greenkeeper makes will break the build, and makes PR's pile up and create a messy PR section on this repo. I would remove it, and maintain packages at the same time as we are updating React versions (which is a bit more work then merging a Greenkeeper PR anyway), so that it all happens in one go. Would love to discuss this.

@plotly/dash

[rmarren1]

The issues / PR sections do look a little cluttered because of GreenKeeper. I think https://github.com/plotly/dash-core-components/network/alerts can be used to keep track of dependency issues that open up critical security vulnerabilities, I think it tracks package.json (it doesn't have any now, but I'm pretty sure I saw npm packages there before).

Do you think we would add it back once we upgrade to React 16? I think it would be useful if we stayed on top of it and if most updates didn't break the build.

[bpostlethwaite]

Actually yes - we could try to keep on top of Greenkeeper. Treat the PRs as PRs from the community and tend to them sooner.

Let's get upgraded and see how it goes for a little bit? If it isn't working then let's readdress.

[valentijnnieman]

As a maintainer I find it to be more of a nuisance than helpful. PR's that upgrade just babel-eslint to a newer version don't really make that much sense anyway. It makes more sense to update all the internal tooling (webpack + babel + linting) in one go to make sure it works well together, instead of doing it in tiny increments and spending time doing it gradually. I would be more interested in using Ryan's suggestion of GH alerts, and making sure to update tooling once in a while.

[Marc-Andre-Rivet]

I think alerts are useful but the automatic PRs not so much because of cross-dependencies -- just this one for example -- https://github.com/plotly/dash-core-components/pull/235/files, this react-dates version needs react-with-direction in the project to work correctly. -- or this one -- The babel 6.x -> 7.x upgrade saw many packages move from 3rd party to 1st class and automation is not super useful there.

Those PRs also don't include the necessary rebuild for the built package.json to be updated or for the build itself to be updated with the new packaged dependency. Forcing a follow up anyway.

[Marc-Andre-Rivet]

Alternatively, is it possible to configure the Greenkeeper differently? Say, so that it creates one PR with all the possible updates each month (-ish) -- the maintainer can then cherry pick what makes sense at that moment and propose a single meaningful PR.

[Marc-Andre-Rivet]

Fun fact: 202 of the 241 existing branches in dcc have been created by the Greenkeeper, just seems abusive. It makes navigating branches / finding valuable info harder.

[valentijnnieman]

@Marc-Andre-Rivet That would make more sense to me - in the case of Babel updates that PR would then include all of the necessary updates, and will allow the maintainer to look at that PR as a whole and make changes to the configs if necessary too.

[bpostlethwaite]

Ok did we turn it off? If not turn it off :)

[Marc-Andre-Rivet]

I've looked into the Greenkeeper.io documentation and there's not much we can do to combine the PRs into a single PR or in terms of configuration in general -- lots of opened issues dating as far back as 2016.

I've looked into this GitHub Bot https://renovatebot.com/ that has a free tier for non-private repos / open source.

It provides grouping and granularity over how dependencies relate to each other (how they should be grouped for PRs) and has an explicit scheduling scheme that can be configured by project.

I've made an attempt with an old project of mine

This configuration checks every hour and groups all modifications (package.json only) into a single PR.
https://github.com/Marc-Andre-Rivet/vuex-model-template/blob/master/renovate.json

It can be modified to schedule it every two weeks or every month, etc. as we want
https://renovatebot.com/docs/configuration-options/#schedule

Setting up the repo in the known repos list will trigger an automatic setup PR that can be edited
Marc-Andre-Rivet/vuex-model-template#4

When changes are detected / per schedule, a PR will be created
Marc-Andre-Rivet/vuex-model-template#5

@bpostlethwaite To try this out I would need to either have someone with admin rights on the Plotly organization to install Renovate or get the rights myself.

I suggest setting it up for dash-table and dcc as a trial and then disconnect the Greenkeeper hook from this repo.

My understanding is that other dependency files like requirements.txt are also supported by this platform, which sounds pretty interesting! --> for example, getting dash-docs to pull a PR automatically when a comp is published! -- I think a reporter can even be assigned -- e.g. if dash-table is updated I get assigned as a reviewer for the dash-docs dash-table dep update (or we even automerge), making sure I don't forget :)

[Marc-Andre-Rivet]

@bpostlethwaite Do you have the rights to install a new app in the Plotly organization?

[valentijnnieman]

I'm closing this since we've decided to stop using Greenkeeper for now in favour of Renovate.