add dependabot config script

[davidspek]

Inspired by kubeflow/pipelines#4682 I created a script that will create a config file for depandabot so that it knows what directories to scan. It will scan the repository for files named *ockerfile*, package*.json, *requirements.txt and go.*. It is setup for dockerfiles, npm packages, pip dependencies and gomod at the moment. It is trivial to further customize what folders are selected if further customization is needed. It also parses the closest OWNERS file for a given dependency listing file, and assigns the relevant approvers and adds the relevant reviewers to the PRs it creates.

This is a sibling PR to kubeflow/pipelines#5015, kubeflow/kubeflow#5542, kserve/kserve#1309, kubeflow/arena#403, kubeflow/testing#855, kubeflow/fairing#550, kubeflow/kfp-tekton#432, kubeflow/katib#1420, kubeflow/training-operator#1224, kubeflow/kfp-tekton-backend#28, kubeflow/mpi-operator#319, kubeflow/pytorch-operator#315, kubeflow/metadata#255, kubeflow/xgboost-operator#107, kubeflow/fate-operator#26, kubeflow/mxnet-operator#87, kubeflow/website#2459 and kubeflow/kfctl#479.

As it stands now, there are about 70 PRs that will be created with this configuration.

There are 55 reported security vulnerabilities so I believe somebody needs to take a look into these PRs as soon as possible.

For reference, the PRs that will be created can be found here: https://github.com/DavidSpek/examples/pulls

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: DavidSpek
To complete the pull request process, please assign jlewi after the PR has been reviewed.
You can assign the PR to them by writing /assign @jlewi in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[davidspek]

/assign @jlewi @jinchihe

[jlewi]

I'm no longer actively involved in this repository. I'm not sure what the current ownership structure is.

It doesn't look like this repo is currently owned by a WG:
https://github.com/kubeflow/community/blob/master/wgs.yaml

Which suggests to me it might be orphaned.
cc @kubeflow/project-steering-group

I would suggest starting a thread on the mailing list to figure out which WG owns this repository and if no WG owns it what to do about it.

[davidspek]

It seems like some of the examples do contain OWNERS files. I think another route of action is that each example should belong to a WG, this way an example demonstrating serving would be owned by the serving WG. With this structure it would be possible to pull in the example folder from each upstream repo (such as pipelines or serving) and have them together in this repo, similar to how manifests works.

[jinchihe]

/cc @Bobgy comments for this? Thanks.

[davidspek]

I am holding the PR to have some control over when it gets merged so that the optional test infra doesn't get overloaded if all the repo's were to merge this at the same time.
/hold

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.