Investigate if greenkeeper and renovate could generate PRs to add testing against recommended versions.

[mhdawson]

No description provided.

[ghinks]

Greenkeeper

I reached out to the greenkeeper team only to discover they are organizing JSConfEU and are really busy at the moment.

These are the questions I asked of them

1. Please could the package maintenance team have a contact at Greenkeeper

2. The package maintenance team would like to know if it is possible to add
   testing against recommended node versions?

3. Are aware of the smaller conferences before JSConfEU. There is a collaborators conference and the package maintenance team would really like to meet the Greenskeeper team.

We did get a responses from them

1. you can always email support@greenkeeper.io the whole team see this. If you use a subject of [nodejs pkg] or something like that, we can easily see your requests. In addition, feel free to email me any time: email was provided to us

2. We already run PRs for major version updates (adding say node 12 to travis.yml and engines in package.json),
   but we’re only doing that for the major versions
   (and we haven’t done 12 yet ;) — adding automatic PRs for all node minor versions might be asking too much
   for our general audience, but we could at least make this an opt-in function, would that work?

3. As mentioned above, we run the whole show, so this week is rather busy, but we are generally happy to meet during JSConf EU.

Currently I am speaking at a conference in NYC and I also noticed another member of our team speaking too.
These are our next possible steps which I will look at shortly.

• get on a call with them before the collaborators conference
• should we talk to them at a booth at JSConf
• leave it a few weeks as they are most likely super busy until the end of JSConfEU.

[mhdawson]

I think it's probably best to wait until after JSConfEU so we can have their full attention.

[ghinks]

ok, I think that is best too :)

[dominykas]

Just checked up on renovate and it seems they also already support it: https://renovatebot.com/docs/configuration-options/#travis - I'll see if I can test it out on a project (they don't seem to support matrix config, but maybe the simple version is good enough).

[mhdawson]

@dominykas good find.

[ghinks]

Renovate latest LTS investigation

( the following was done via travis ci )

So it is now after JSConfEU and I'll start to look at these items again. So I signed up for the renovate service on my little test repo and the only thing that was required was the following in the renovate.json file in the root folder.

{
  "extends": [
    "config:base"
  ],
  "travis": {
    "enabled": true,
    "supportPolicy": ["lts_latest", "current"]
  }
}

after adding this and merging it into my test repo I saw the travis job kick off

After completion I got

in travis which was what I was expecting.

The renovate default lts definitions are

Here are some useful links

renovate bot top level docs
renovate node versions
renovate node configuration support policy

items of note

• I have not been able to get Greenkeeper to work with a mono repo I took care to choose something other than the simply example cases. I am going to contact Greenkeeper about this.
• Renovate worked out of the box for a lerna based mono repo with no configuration.
• Renovate is very configurable and does require a bit a reading in order to make that configuration work.
• test travis
• repo used for test
• extra fun fact, do not create a branch of your own named renovate/something as it does not reflect in github after the push. Once you sign up for renovate in a repo that tag is not for you.

[trivikr]

We're using Greenkeeper with our aws-sdk-js-v3 monorepo for around 4 weeks now (link) with no issues

[ghinks]

cheers, looking into it.

[ghinks]

@trivikr I see your use case. I choose to test the example for case where package-lock.json files are used in a mono repo. In this case I could not get it working. Sorry for any confusion. What I am looking for is an example use that uses the greenkeeper-lockfile mechanism within a monorepo that has lock files.

Quite a bit has been written about it and it has 24k downloads a day. But for a mono repo with locks in the packages I have not seen a working use case.

[trivikr]

@ghinks we're considering switching to dependabot as it has support for lockfiles and it also works with monorepo. Not sure if it supports lockfiles in a monorepo though.

[ghinks]

one more to look at :)

[trivikr]

Yup :-)
GitHub acquired them on May 23rd, doubled the team size and it's already integrated for automated dependency updates for security fixes!

[ghinks]

So just to wrap up this discussion. I adjusted the renovate configuration so that it triggered nightly ( you do not seem to be able to trigger a test yourself )

{
  "extends": [
    "config:base"
  ],
  "travis": {
    "enabled": true,
    "supportPolicy": ["lts_latest", "current"]
  },
  "schedule": "before 2am"
}

I took my travis config and reduced the lts current number so I could get a PR triggered by renovate.

language: node_js
os:
  - linux
node_js:
  - 10.15.3
  - 12.4.0
script:
  - npm test
  - npm run lint
  - npm run build

This PR was triggered.

The 10.15.3 was bumped up by the PR to lts latest.

renovate does meet the needs.

I did look at dependabot from github, it worked, but lacked all the configuration options we require for current and lts_latest stipulations.

[mhdawson]

@ghinks I think we need a follow on if this is going to be closed. We don't necessarily want to recommend a single commercial tool so it would be good if all of the tools had the option that kept you up to date testing against recommended versions. Maybe we need guidance which explains how to do that with each of the 3 mentioned (and we'd be open to other's being PR'd in as well). It sounds like currently renovate might be the easiest of the 3, but that might change over time, particularly if the other providers agree with our guidance and then want to make it easier to implement in their tooling.

[ghinks]

Agreed. I think it would be best. Let me start off with a description of what is possible with the three bots that I have investigated.

[mhdawson]

@ghinks sounds perfect. Feel free to re-close this issue if you want to do that in a new issue, just re-opened so we would not forget.

[ghinks]

Leaving this item open. Greenkeeper (Jan Lehnardt) have reached back out to me after JSConfEU and the thread of our conversation is kicking off again.

[ghinks]

Requests for help were sent to Greenkeeper on June 22nd 2019 and a follow up request has been sent to them on July 9th 2019.

[ghinks]

Greenkeeper

After talks with Greenkeeper they have said that they will at some point have options to opt into node releases but do not wish to give a schedule yet. A sensible middle ground between defaults and optional configuration will be offered. Although we cannot close this item we may keep it opening perhaps under awaiting future developments

[dominykas]

I did look at dependabot from github, it worked, but lacked all the configuration options we require for current and lts_latest stipulations.

@ghinks I'm working on #204 and would like to include dependabot information as well - I'm happy to go test it out myself, although if you can share more details/links to docs/tests that you did - I could just include that?

[ghinks]

Thank you, I'll follow up on #204

[dominykas]

Just found a note to self to look in here - is there anything left to be done specifically for this issue?

[ghinks]

Apologies I have not followed up on this as the other blog endeavor of #248 looks to be enough for me.

[mhdawson]

Renovate looks like it can do that, the others don't. @dominykas is going to write up a best practice on how to use renovate to keep your testing updated to LTS versions.

Closing

[ljharb]

I’ve actually come up with a way to do it on Travis using a new unannounced feature of theirs :-) I’ll update here once I’ve finished testing it on the rest of my projects.