Document options for keeping dependencies up to date

[dbwiddis]

Signed-off-by: Daniel Widdis widdis@gmail.com

Description

Adds a section to the maintainer responsibilities document outlining dependency update options.

Issues Resolved

Closes #97

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[dblock]

Thanks! I have some questions.

[peternied]

Thanks for writing this up

[peternied]

This recommendation for OpenSSF is old, why not link to their main branch?

[dbwiddis]

Well, I just followed the link from the press release but certainly linking to a permalink off the current main would be better.

Although that introduces a bit more complexity to this whole paragraph as it includes Sonatype Lift as another option. But I believe that only scans for dependencies with vulnerabilities, not overall dependency updates. So should it be included?

[peternied]

It sounds like you are proposing duplicate the OpenSSF content, I would rather link out, but provide the guidance based on their fielding e.g.

We recommend you use renovate, and there are a number of other tools available such as {dependabot, ...?} that might work better depending on a repositories needs, see this publication from Open SSF that includes many other technologies {link}

How does that sound?

[dbwiddis]

I don't want to be the one saying "we recommend..." yet. I do think I can link to the current OpenSSF scorecard and reference #93, though, since using one of these options contributes to that.

[peternied]

It seems like renovate is the superior choice, what would you think about marking it as the best practice? Then if you'd like we can list other options such as dependabot?

[dblock]

Either way reorder the recommendations then. If it is we should probably also run a campaign to replace dependabot -> renovate.

[dbwiddis]

It seems like renovate is the superior choice, what would you think about marking it as the best practice?

Either way reorder the recommendations then. If it is we should probably also run a campaign to replace dependabot -> renovate.

I think it's a preference thing: there are pros and cons of both, and more detailed integrations (e.g., change logs) to consider.

While I prefer it and I advocated for it on a repo where I am a maintainer, I would want maintainers of other repos to evaluate and consider using it before calling it a best practice. There are some OpenSearch maintainers on the SDK repo who can evaluate it for a while and consider if they want to make that recommendation.

I think for now outlining the options and letting maintainers view/consider both is a good step.

[peternied]

Individual repositories they should choose the best tool for the job, as OpenSearch-Project I think we have strong feelings that an automated tool is used.

As this is the project's guidance I would rather take a position in a primary approach such as renovate and we can update guidance as we learn more with future pull requests on this section, what do you think of this approach?

run a campaign to replace dependabot

I think is a great discussion to be had for the cost and value to migrate from dependabot to renovate - legacy support vs what I think of this pull request around new repositories.

[dbwiddis]

As this is the project's guidance I would rather take a position in a primary approach such as renovate and we can update guidance as we learn more with future pull requests on this section, what do you think of this approach?

While I was initially trying to hold back on a hard recommendation, I've changed my mind. Since we now have the "Mend for Github" application thanks to efforts by @peterzhuamazon and @CEHENKLE, and since Renovate can be directly integrated into that application with just a few lines in the config file, I think that should be our primary recommendation.

(Pedantic/branding point: "Renovate" is the open source offering. "Remediate" is the product that fixes security vulnerabilities that comes with Mend for Github. Renovate can be enabled as part of Remediate with a simple config file boolean.)

If projects have already put significant effort into dependabot integrations (e.g., changelog updates) it may make sense for them to keep those, but I would recommend new projects work with Renovate.

[dblock]

I mean to add an example to "adding dependabot.yml"

[dbwiddis]

The link already included has an example YAML file lower down on the page (here) but I thought starting earlier in the documentation was a better link.

[dbwiddis]

Switching this to draft for now. It looks like Renovate is integrated with Mend for Github / whitesource which many other repos already have, which greatly simplifies installation.

[dblock]

Do we want to add "Renovate is recommended"? I am fine without.

[dbwiddis]

Do we want to add "Renovate is recommended"? I am fine without.

Nah, I think listing it first and bragging about its features is good enough.