Flux: Also update submodules on checkout/update

Created on 6 Apr 2020  路  7Comments  路  Source: fluxcd/flux

Describe the feature
Currently flux does not seem to be checking out submodules and/or updating them on sync runs. This is a request to add that feature.

What would the new user story look like?
How would the new interaction with Flux look like? E.g.
Allowing submodules to be updated/fetched, this allows one to abstract away some reusable stuff in separate repositories, or allows one to spread out the infrastructure-as-a-code layout between teams responsible for specific areas, by separating it on a repository level.

Expected behavior
During repository init/update, the --recurse-submodules option can be passed to git clone and git pull ( as per https://git-scm.com/book/en/v2/Git-Tools-Submodules ) to automaticall also update submodules. Alternatively git submodule update --init --recursive should also work.

blocked-needs-validation enhancement

Most helpful comment

If you are in a total bind, I have used this in my .flux.yaml to emulate the same behaviour:

version: 1
commandUpdated:
generators:
- command: git submodule init >> /dev/null
- command: git submodule update --remote >> /dev/null
- command: kustomize build .

All 7 comments

We would also use this heavily - would love to see it added.

Specifically, I'd like to use this to include a common cluster config repo in many individual cluster repos, allowing them to share common configs, but all be independently versioned.

Also open to alternative suggestions on how to accomplish a similar workflow.

Is there anything I could do to help push this forward @Xaroth ?

+1 for this, I'm not an expert but I would hope adding something like a --recurse-submodules=true command to fluxd would not be a massive change and would really help add some flexibility to repository structures

This is a must have feature. Supporting On-prem deployment thru gitops with existing architecture of Flux requires to have multiple git repos or multiple branches, if you have multiple on-prem deployments. This certainly can't scale.

+1 for this feature, it's a must-have for big repositories with multiple sub repos.

If you are in a total bind, I have used this in my .flux.yaml to emulate the same behaviour:

version: 1
commandUpdated:
generators:
- command: git submodule init >> /dev/null
- command: git submodule update --remote >> /dev/null
- command: kustomize build .

The command in .flux.yamlapproach almost worked for me. Except the deploy key could not be added to my submodule repo because it already was added to my main repo. I ended up creating a new flux ns for the submodule.

A small amendment to @jgalliers comment.

I was not using kustomize native layout on my repo, so building up all possible manifests from the repository led me to the following instead:

version: 1
commandUpdated:
  generators:
    - command: git submodule init >> /dev/null
    - command: git submodule update --remote >> /dev/null
    - command: kustomize edit add resource $(find -not -path "./_charts/*" -mindepth 2 -type f \( -name "*.yaml" -o -name "*.yml" \) 2>/dev/null)
    - command: kustomize build .

The kustomize edit line is quite a hack to build a list of all possible manifests, and it gets important to know how to structure your repo with this workaround in place. But if that is tolerable - this works.

Was this page helpful?
0 / 5 - 0 ratings