THRIFT-5701: Add dependabot

[Fokko]

To keep up to date with the latest dependencies

• Did you create an Apache Jira ticket? (Request account here, not required for trivial changes)
• If a ticket exists: Does your pull request title follow the pattern "THRIFT-NNNN: describe my issue"?
• Did you squash your changes to a single commit? (not required, but preferred)
• Did you do your best to avoid breaking changes? If one was needed, did you label the Jira ticket with "Breaking-Change"?
• If your change does not involve any code, include [skip ci] anywhere in the commit message to free up build resources.

[ctubbsii]

I think this is a good idea, but I would suggest making Java deps less frequent. Maybe monthly. Java dependencies can move pretty quickly, and I can imagine things getting spammy pretty quickly.

[Fokko]

@ctubbsii Thanks for the quick response. How about weekly? I agree that we don't want too much spam, however, we don't want to miss any deprecations. Looking at other projects weekly is a good balance.

[Jens-G]

Don't we have dependabot already? And why only Java?

[ctubbsii]

@ctubbsii Thanks for the quick response. How about weekly? I agree that we don't want too much spam, however, we don't want to miss any deprecations. Looking at other projects weekly is a good balance.

It was already set to weekly when I made my comment. The GitHub Actions were set to daily. I don't think those change very often, so that doesn't really matter.

My main concern about doing the Java libs weekly, is that this only really matters for release and release testing, and this project doesn't release very often. So, this can just create a bunch of busy work... bumping dependencies every week, resulting in possibly several dozen bumps between releases. That can get annoying, because one bump during the development period would suffice. Frequent bumps can have benefits, in that slowly moving incompatibilities can be fixed more easily in smaller chunks... but more likely, these bumps will merely fix bugs and not create any incompatibilities at all. So, it's just busy work. I would choose a longer duration to match the less frequent release cycle of this project in order to avoid redundant busy work, and more ability to focus on the outstanding PRs that are more important for the project.

[Fokko]

@Jens-G

Don't we have dependabot already? And why only Java?

Github does create PRs for bumping libraries that have security holes, but for the regular updates, you need to enable it explicitly by adding the file. I'm comfortable with Java, and I t think we can add more languages later on.

@ctubbsii I see your concern. My argument to that would be that you don't want to do all the updates just before a release as something might have broken you want to know earlier. I would argue that it will reduce the work because you don't have to look up the latest version, and you only have to merge the PR that's being created by Dependabot. As I said, I have seen this work well on other projects, and I would recommend giving it a try.

[jimexist]

make sure you also include /lib/kotlin

[Fokko]

@jimexist done! 👍🏻

[ankit-gautam23]

Where are we consuming this?

[ctubbsii]

Where are we consuming this?

If this is merged to the default branch, then GitHub will use it to automatically open pull requests to propose updates to dependencies that are tracked. See https://github.blog/2020-06-01-keep-all-your-packages-up-to-date-with-dependabot/

[Fokko]

You can see it in action on the Parquet-mr repository: https://github.com/apache/parquet-mr/pulls