-
Notifications
You must be signed in to change notification settings - Fork 166
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support of rendering to another repository #1354
Comments
Hi @dan1el-k! This is an interesting idea. I want to try and split this into two different parts.
While this generally seems doable, it upsets the apple cart a little bit in terms of that fundamental premise of Kargo Render. I think before either committing (or not committing to this), I'd like to get a sense of how common a pattern it is to read config management templates/overlays from one repo and render them to another. Let's leave this open and see where it goes. Tangentially: idk if this other thread of yours and mine might give you an alternative way to approach this? |
In the enterprise company I am working in, teams uses different repo patterns, based on size and complexity of the applications.
While the first 2 patterns are perfectly supported by kargo, I am specifically targeting the 3rd one with this request. Yes, this could potentially be achieved as well using Kustomize remote base or an Helm umbrella chart with dependencies or via Git Submodules out of the service repo, as I have requested with my other ticket in "kargo-render" project. |
Hi, this proposal is a pattern we also want to support. Besides collecting and rendering multiple repos to one service to have the deployed state of the service audited at every point in time. Taking this idea even further you could render all manifests to a cluster repo to archive the same on cluster level. |
I'm tentatively contributing a WIP PoC in #1447. |
This issue has been automatically marked as stale because it had no activity for 90 days. It will be closed if no activity occurs in the next 30 days but can be reopened if it becomes relevant again. |
Not stale. I think this is something we can tentatively do, but it's a more involved change than it may seem on the surface. Priority still undetermined. |
Hey @krancour, |
In v0.9.0, we plan to break up our "russian nesting doll" of opinionated promotion mechanisms into an ordered sequence of more granular, more explicit, user-defined steps. It is largely a guess, but this issue may be solved incidentally by those plans. |
Following up on previous comment. I do expect that this will be addressed naturally by #2219 |
The new promotion steps feature can support this. |
Checklist
kargo version
, if applicable.Proposed Feature
Rendering to a another repository. (Service Repo concept)
Motivation
As of version
0.3.0
kargo, just supports rendering in branches of the same repository as the sourcehelm
orkustomize
files exists.This is fine and supported for:
What I would like to have is the support of:
Rendered Target
and furthermore as deployment source for ArgoCD.To bundle multiple application rendered manifests in one repo, however having the original manifests still in separate repos.
With that, this
Service repo
could be a pure pipeline/infrastructure repo with no manual changes need after setup, and theapplication repos
(multiple, one for each microservice) are used as a source and working repo for the team/engineers.Suggested Implementation
Support of following new parameters
readRepoURL
: currentlyrepoURL
, mandatoryreadBranch
: optional as of nowwriteBranch
: optional as of nowwriteRepoURL
: optional, newFull example
The text was updated successfully, but these errors were encountered: