Add integration dependabot

[antgamdia]

Description of the change

This PR updates the current dependabot config to also upgrade our integration deps periodically. The release process docs have also been updated accordingly

Benefits

The bot will send PRs for the integration dependencies as well. We no longer will get notified about security issues in these deps (though they are not part of the kubeapps code itself).

Possible drawbacks

Please note the integration image is not being created automatically. According to our release process, this image might be updated when releasing a new kubeapps version. Direct consequence: the current code in the main branch won't match the actual code in the image container image.

Alternatives:

A) We just assume the integration image won't match the declared dependencies in the main branch. They eventually sync once we release a new Kubeapps version (albeit not guaranteed according to the current process documentation)

B) We push ourselves to create a new integration image version. It implies:

• Dependabot creates a PR in the integration image
• We pull that PR branch (once we've got the green light), build the integration image, tag with a new patch version, push to the image registry and bump the version up in the circle configuration.
• We merge the PR, so the next CI execution will run with the new image.

If B) we will have to update our docs to show these instructions.

A B' is possible, where we send another PR in addition to the dependabot one, but I personally think it will generate more overhead rather than being useful.

Applicable issues

• fixes Auto-update integration deps in dependabot #2782

Additional information

Additional idea: what if we build the integration image in CI-runtime? This way it's guaranteed it'll use the latest deps versions.

PS: woah - it was supposed to be a straightforward one-line change indeed...

[absoludity]

Additional idea: what if we build the integration image in CI-runtime? This way it's guaranteed it'll use the latest deps versions.

This sounds like the least (human) overhead? Do you mean that it'll bump the circleci config too right?

[antgamdia]

Yes, we'll need some script retrieving the latest tag, building the image, tagging with version+1, pushing to dockerhub, upgrading the manifest.

Problem: we also need to commit the version bump... so we got a similar scenario as the chart syncing (therefore adding complexity, error-prone...) Does it worth it?

Another approach: changing v1.0.0 to latest back again. This way we don't need to sync versions or commit files to the repo from this CI step.
Caveat: we lost traceability (but, since the versioning is a manual process, could we possibly guarantee we ever had it?)

Relevant files:

• https://github.com/kubeapps/kubeapps/blob/master/integration/Makefile
• https://github.com/kubeapps/kubeapps/blob/master/integration/manifests/executor.yaml#L25

[absoludity]

PS: woah - it was supposed to be a straightforward one-line change indeed...

Agreed - let's not start shaving another yak here.

Looks like the additional idea requires more work than we are (or should be) willing to invest in this right now.

Re-reading your original description, I think your alternative (A) is just this PR right, and when we re-create the CI image during release it gets in sync again. If so, +1 to just land this.

[antgamdia]

I think your alternative (A) is just this PR right, and when we re-create the CI image during release it gets in sync again. If so, +1 to just land this.

That's right, I think it is the best option according to our capacity, but let me file an issue tomorrow before merging to keep track of it.