Managing multiple tanka repos

[nabadger]

Hey,

Wondering if anyone has any tips on managing lots of tanka repos.

We struggled with a monorepo (prior to tanka), mostly because we found the workflow around monorepos pretty blocking, especially when multiple teams start contributing to it (and CI can get tricky).

Managing a few tanka repos is quite easy, but what if you have lots. We've gone down the route of creating a re-usable base jsonnet web-service lib - but now need to think about pushing updates (via jsonnet-bundler) to the tanka repos that use it.

The same problem exists if say we wanted to upgrade k8s version - we need to iterate across all the repos, bump the k8s-alpha version (k.libsonnet) and re-render.

Current toolset looks like:

• Shared CI (linting / kubecfg / conftest etc)
• Shared Makefiles (via build-harness)
• Cookiecutters for generating repo structure
• Git submodules to update some shared-makefile components

I think I'm going down the following route:

• Make the repos discoverable, either via a YAML file, or by querying the Git provider API
• Some kind of bot that can can submit PRs to each repo
• Wait for the CI to pass, then let a human review / merge (or even auto-merge)
• Let the Gitops tooling (flux in my case) sync the manifests on merge

The downside of this approach is probably dealing with tons of MR's when the bot runs (I imagine this could be once a week).

---

Just wondering if anyone has done anything similar?

This wasn't a problem when we had a monorepo :)

[olegmayko]

Hi,
We have been faced similar problem once we decided to move away from monorepo, which contains old go-templating yaml tool, plus jsonnet. It is still ongoing process. We actually decided to use git submodule approach for common tasks (create a repo structure, manifests validations/generation/testing & deployment). The initialisation (we use bitbucket there is no builtin feature but via plugin) and the update of repo to get update from submodule are manual. The only scenario when autoupdating of tanka repos would fit for us is the k8s cluster upgrade, thus the manifests will get regenerated to the k8s version accordingly. So we have some small go ops tool which auto-creates PRs in bitbucket for other use cases, but we gonna adapt it for this one as well.