Private submodules in .gitmodules cause argocd failures

[soudaburger]

Not sure where this really goes, so feel free to relabel or otherwise change this issue as necessary.

We are using argocd to deploy/manage our teleport stack. Because of the way that teleport is managed (helm chart) the appVersion and the version are now identical values. We noticed an issue where, although we had not made changes on our end, there were now deltas with the teleport helm chart with regards to appResources (dynamic application registration).

As a result, we looked to take a different approach. We instead attempted to leverage git submodules to clone down the teleport repository with a specific tag, e.g., v10.1.0. We were able to get this to properly work locally, but because argocd performs a git submodule --init --recursive, it ALSO pulled in the .gitmodules from the teleport repository. However, the e repository at git@github.com:gravitational/teleport.e.git appears to be a private repository and since we don't have access to the repository, argocd applications simply fail to render at all when submodules simply exist in our repo.

Ultimate question: Is that private submodule actually used/needed? Is there a corresponding "public" branch that we could checkout similar to v10.1.0 but that wouldn't have the submodule included?

[zmb3]

teleport.e is not needed for OSS teleport. It contains enterprise-specific code.

[zmb3]

We won't be getting rid of private submodules, but the following issues might be worth following for updates. They also include a few suggested workarounds.

• Git Submodules should be configurable to ignore upstream, private submodules argoproj/argo-cd#10174
• Disable the submodule fetch in a declarative way argoproj/argo-cd#3799