initial commit to add in a dependabot.yml file

[CEHENKLE]

Signed-off-by: CEHENKLE henkle@amazon.com

Description

adding dependabot.yml file to enable automatic scanning for issues in dependencies.

Check List

• Commits are signed per the DCO using --signoff

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.

[opensearch-ci-bot]

Can one of the admins verify this patch?

[opensearch-ci-bot]

✅   DCO Check Passed c991d9b

[opensearch-ci-bot]

✅   Gradle Wrapper Validation success c991d9b

[CEHENKLE]

@dblock I'm thinking we might want to pull out the test gradle build files. What do you think?

[opensearch-ci-bot]

✅   Gradle Precommit success c991d9b

[dblock]

@dblock I'm thinking we might want to pull out the test gradle build files. What do you think?

I don't think so. We should be upgrading test dependencies the same. We get endless vulnerability reports for those by automated software and have to spend a lot of time digging through the dependency tree to finally find out that they are only used in tests. Furthermore developer machines can be compromised through a dev/test dependency.

Is the list of gradle files here basically the list of all gradle files in the project? As a stretch goal we could automate updating this file with a GH workflow that opens a PR every time there's a change.

[dblock]

start gradle check

[opensearch-ci-bot]

✅   Gradle Check success c991d9b
Log 663

Reports 663

[CEHENKLE]

Is the list of gradle files here basically the list of all gradle files in the project? As a stretch goal we could automate updating this file with a GH workflow that opens a PR every time there's a change.

Yeah, this should be every gradle file in the project. That's a good thought. Although honestly I want to be fierce as tigers about adding new dependencies, so hopefully it should be noticeable when we do.

[dblock]

#1355