Updates dependabot configs

[Schwad]

Description

Many of our dependencies should require a simple human check and then merge.

However there are some dependencies that we still want to be a manual process as they are quite tricky version to version.

Doing so through Github does not allow us to document these changes, so we are using dependabot configs to allow discussion and documentation of what may be ignored.

This was sparked by an ActiveSupport bump which would have broken ruby 2.4 support.

Signed-off-by: Nick Schwaderer nschwaderer@chef.io

Related Issue

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New content (non-breaking change)
• Breaking change (a content change which would break existing functionality or processes)

Checklist:

• I have read the CONTRIBUTING document.

[Schwad]

This sets out a dependabot config file, configs can be found here: https://dependabot.com/docs/config-file/

After a discussion with stocksy, he mentioned that it would be valuable to document what dependencies we don't want bumped every time dependabot comes around (for various reasons). You can do this via a comment in an issue but then we lose the documentation/knowledge as to why something was ignored or handled differently in the first place.

This file will be that config. NOTE: most of the work was just making sure I had a valid config file, and taking an initial stab at dependencies. Happy to remove/add more of these if needed.

[skpaterson]

Thanks @Schwad this looks great. Up to now we have been careful about testing cloud resource pack dependency updates prior to updating in train but in theory minor/patch version changes should be fine. The other route to consider would be removing the exceptions and e.g. https://dependabot.com/blog/ignoring-major-version-bumps/ but happy to proceed like this.

[tas50]

If we turn these all off we're going to lose visibility on new releases. Having these PRs opened is just the start of a conversation that should always involve humans, and allows us to make sure our product works with the latest and greatest cloud and system resources. I'd really much rather we use the dependabot chatbot functionality to skip releases instead.

[james-stocks]

@tas50 , +1 to figuring out a standard for how/when we ignore dependency updates.

I do prefer having a config file for "standing exceptions" - so they each have a git commit that allows everyone in the community to follow what's happened historically. But these "standing exceptions" should only be used for project-specific exceptional cases. It should not be used for "I don't personally benefit from this update so I don't care" skips.

If we use the chatbot, is there a way for other people in the community to follow along with skips that happened in the past?

For this case (cloud API gems), I was expecting that they would update fairly frequently, but each update requires careful testing against downstream to avoid breaking current (previously certified) content.
@skpaterson commented that minor/patch updates should be fine - so maybe we should go with his suggestion and tell dependabot to just ignore these gems if/when a major release comes up.

For ActiveSupport maybe we don't need config to skip this if the ruby 2.4 buildkite steps will demonstrate that updating this fails.

[Schwad]

I just think it's nice that we have this documented where we can review it. Future ActiveSupport will never be mergeable unless we drop ruby 2.4 support and this gives me a place in the code to make note of that.

If I kill it in the chatbot we lose visibility on what's being ignored.

I am +1 on being as liberal with dependabot as possible, and I am grateful that it has kicked off our discussion about these dependencies here as well.

The primary goal of this PR for me was to create a .dependabot/config.yml file and start a dependency discussion.

I think we have two meaningful options:

1. (most liberal) delete all of the config file but for ActiveSupport (I feel this really needs to be here)

2. (more conservative) maybe delete some of the agreed cloud dependencies, but for the ones that remain allow all minor and patches through the door with dependabot

[stevendanna]

Small recommendation if y'all go this route: Anything we are ignoring should have a comment with a link to an issue as well.

[stevendanna]

I don't know if this would help with people's concerns, but a thing that has worked well in a few other projects is that we also make updating deps part of the release cycle. That is, right after a release, we also generate a PR bumping all of the dependencies. At that point we have to "re-up" our decision to keep something held back. This has worked well on projects that are in active development. It becomes problematic once the release cadence for a project slows down though.

[Schwad]

+1 good point @stevendanna - I think the activesupport thing does warrant its own issue and a link. WIll do that now. Thanks for the additional perspective/thoughts!

[Schwad]

I have updated the PR to:

1. all < 6.0.0 updates for ActiveSupport
2. Allow all minor/patch/etc updates on the other gems.

If there are dependencies on there that we think might not be as nefarious I'm happy to hear from @skpaterson etc. and can remove those.

[james-stocks]

Thanks Nick :)