-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Enable multi config support in Skaffold #5160
Enable multi config support in Skaffold #5160
Conversation
Codecov Report
@@ Coverage Diff @@
## master #5160 +/- ##
==========================================
- Coverage 72.39% 71.84% -0.56%
==========================================
Files 385 387 +2
Lines 13735 13923 +188
==========================================
+ Hits 9944 10003 +59
- Misses 3063 3188 +125
- Partials 728 732 +4
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for a 98 file change, that was surprisingly painless to review :) left some comments but in general i'm actually feeling pretty good about this. two questions:
- what does the UX look like for providing multiple configs in different directory hierarchies? do things generally work well for relative paths in the skaffold.yamls?
- can you explain at a high level why we need the
PreBuild
andPostBuild
functions on the builders? i'm assuming this has something to do with parallel builds not stomping on each other, but documenting why we need this would be nice, especially for reference if/when this code gets touched later.
@@ -145,12 +145,12 @@ func IsSkaffoldConfig(file string) bool { | |||
} | |||
|
|||
// ParseConfig reads a configuration file. | |||
func ParseConfig(filename string) (util.VersionedConfig, error) { | |||
func ParseConfig(filename string) ([]util.VersionedConfig, error) { | |||
// TODO: update this function to parse the input as multiple configs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean that the input to the function would be a directory containing multiple configs? wondering if that's something that would make sense to support.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The input could be multiple files (multiple -f
flags support) and each file could define multiple configs (if we decide to do Skaffold Multiple Configs
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
got it. i'm still wondering if we might want to support running skaffold on a directory and having it find and use all nested configs, but i think that's out of scope of this PR.
func setDefaultDeployer(configs []util.VersionedConfig) bool { | ||
// set the default deployer only if no deployer is explicitly specified in any config | ||
for _, cfg := range configs { | ||
if cfg.(*latest.SkaffoldConfig).Deploy.DeployType != (latest.DeployType{}) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this applies to several places in the code but i had the thought here: i don't love that we do cfg.(*latest.SkaffoldConfig)
all over the place to access fields from the config. how easy would it be to through these into interface fields that util.VersionedConfig
implements? then we could do something like cfg.DeployType()
instead. just a thought
My idea is to support relative paths from all configs by resolving them immediately while parsing. We can use a
Let me know if you think there's a better way of doing this. But some builders like |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My idea is to support relative paths from all configs by resolving them immediately while parsing.
ok this makes sense to me. i was originally also thinking about supporting running skaffold from an arbitrary directory and collecting all the nested skaffold.yamls under that directory and using them in the run, but after thinking more about it i don't think this is a good idea. imagine running skaffold dev
from the root directory of our repo 😮
We can use a yamltag to denote which properties are to be interpreted as file paths.
this will all come down to documentation IMO - if we can demonstrate this in a real world scenario and make it easy to discover the moving parts a user needs to control to get their project working, it should be fine.
let's get this merged now, and start playing around with it 👍
This PR introduces the concept of multiple Skaffold configs. This is a prereq to implementing either
Skaffold Modules
orSkaffold Multiple Configs
.Summary of changes:
latest.Pipeline
anymore that provides build artifacts, deployers and tests. These methods have been moved intoruncontext.RunContext
which maintains all referenced configs internally and provides target methods for other modules to utilize.Local
,Gcb
andCluster
builders are modified to implementbuild.PipelineBuilder
interface instead ofbuild.Builder
.build.BuilderMux
implements thebuild.Builder
interface and internally manages allbuild.PipelineBuilder
instances. This simplifies out of order builds between the different pipeline builders.areImagesLocal
,importImage
, etc. are now functions on theimageName
since they can vary between pipelines.