You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Do we want to expand bash substitutions in some skaffold fields? It is a bit of feature creep, but might be useful for complete portability of skaffold.yaml
We could ship examples for other repos by including a workspace: $GOPATH/src/path/to/project, so that we don't need to keep all of the example code here, only the example configuration.
It also makes paths less fragile, since its not so dependent on where the user actually runs skaffold run.
The main issue is that each skaffold.yaml has a specific location that it must be run in.
In the example config workspace: examples/getting-started
This won't work anywhere other than the root directory.
If you do workspace: ., it won't work anywhere other than examples/getting-started. I'm sure there are more ambiguous situations too.
Of course, you can make it an absolute path, but that won't work when you're sharing the config with others.
I'm on the fence about this one, I really don't think that envsubst is a good solution, but I'd like to make the config paths as unambiguous as possible, especially to help with automation.
Do we want to expand bash substitutions in some skaffold fields? It is a bit of feature creep, but might be useful for complete portability of
skaffold.yaml
We could ship examples for other repos by including a
workspace: $GOPATH/src/path/to/project
, so that we don't need to keep all of the example code here, only the example configuration.It also makes paths less fragile, since its not so dependent on where the user actually runs
skaffold run
.Here's a library we could use (note: haven't used it before, this is just the result of a quick google search)
https://github.com/drone/envsubst
The text was updated successfully, but these errors were encountered: