-
Notifications
You must be signed in to change notification settings - Fork 25
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
Feat: As Penny I want full control over where files are scheduled in a Destination #129
Comments
Hello,
I am attempting to create a promise to onboard tenants onto our FluxCD Hub/Spoke and I figured this might allow me to push the files to the specific directory structure that FluxCD is expecting. |
Hi @tdiaque, it is released. The error you are getting is because its immutable, we don't support changing the values for an existing Destination. To get the desired behaviour you want you can delete:
|
That worked @aclevername. Thank you for the clarification. |
Follow up from #127
Background
As part of #127 you can now specify that files written to the destination either:
kratix/platform-cluster/resources/default/redis/example/instance-configure/5058f/redis-instance.yaml
These are 2 common use cases we think we will run into, but is not the definitive list. To enable users with more complex use cases we want to support expressing your own desired filepath structure via a key.
Proposal
Expand the
filepathExpressionType
key to have an additional valuecustom
and introduce two new keyspromise
andresource
value. e.g.:We should expose all the variables we use today to template our default to the user:
for resources:
.spec.uid
)for promises:
.spec.uid
)We should add proper validation so that any usage of
custom
withotu settingresource
/promise
results in an errorTemplating style
TBD what format the templating should take, in the example its bash variables. We could do something like the go-templating that helm uses
{{ .PromiseName }}
. Investigate which makes sense and use thatthis current solution is just for setting prefixes, in a follow up story we can add more complex templating language to enable suffixes etc as there are many more complicated use cases.
The text was updated successfully, but these errors were encountered: