Add forwarding deployer muxer to enable multiple deployers#3391
Add forwarding deployer muxer to enable multiple deployers#3391dgageot merged 3 commits intoGoogleContainerTools:masterfrom
Conversation
Codecov Report
|
pkg/skaffold/deploy/deploy_mux.go
Outdated
| // it collects the results and returns it in bulk. | ||
| type DeployerMux []Deployer | ||
|
|
||
| var _ Deployer = DeployerMux{} |
There was a problem hiding this comment.
gotcha, it is just a compile time check to make sure that DeployerMux implements the Deployer interface.
There was a problem hiding this comment.
Exactly, this was my local compile check that I have implemented the interface. As this pattern seems to be unused in Skaffold, I opted to remove the line instead.
| func (m DeployerMux) Labels() map[string]string { | ||
| labels := make(map[string]string) | ||
| for _, deployer := range m { | ||
| copyMap(labels, deployer.Labels()) |
There was a problem hiding this comment.
I don't think this is what we want, if I understand this correctly this will result in a single label with skaffold.dev/deployer: <last deployer>.
The best would be to label resources with their own deployers. However that seems hard with this current architecture.
So I'd rather have something like:
skaffold.dev/deployer0: helm
skaffold.dev/deployer1: kubectl
skaffold.dev/deployer2: kustomize
WDYT?
There was a problem hiding this comment.
Good catch. This was already addressed with #3390, where the deployer labels are removed from the global list of labellers and are applied just in the specific deployer instead.
So I think the semantics of this line is correct.
pkg/skaffold/deploy/deploy_mux.go
Outdated
| } | ||
|
|
||
| func (m DeployerMux) Deploy(ctx context.Context, w io.Writer, as []build.Artifact, ls []Labeller) *Result { | ||
| seenNamespaces := sets.String{} |
There was a problem hiding this comment.
this is cool, but kinda scares me that it's in kubernetes. Haven't made up my mind yet about it.
The risk of it disappearing / changing is minimal as skaffold is for kubernetes. But in general we tend to avoid depending on utilities from dependencies - unless the dependency is specifically for that utility. E.g. docker has some great stuff in their ioutils package but we decided not to use them.
There was a problem hiding this comment.
Yeah that totally makes sense. The de-duplication is easily implemented so there's no need to add a dependency here.
I think there are a few places where Skaffold code could benefit from a StringSet util, but this is not the right PR to make that change :). So I've inlined a small helper in this file.
This allows re-use by other deployer renderers. Signed-off-by: Cornelius Weig <22861411+corneliusweig@users.noreply.github.com>
This Deployer implemenation forwards commands to all of the deployers in his list. It will be useful to allow multiple deployers in skaffold.yaml. Signed-off-by: Cornelius Weig <22861411+corneliusweig@users.noreply.github.com>
Signed-off-by: Cornelius Weig <22861411+corneliusweig@users.noreply.github.com>
cc58e63 to
be44da2
Compare
|
Sorry for my confusion. I accidentally committed the review comments to the wrong branch 2 weeks ago 🤦♂️ |
Relates to #2875, #3292
Should merge before : #3392
Description
Add a deployer implementation (
DeployerMux) that multiplexes the deployer actions with multiple deployer instances. This new deployer is simply a[]deploy.Deployerwhich forwards the commands of theDeployerinterface to the instances in the list. When encountering an error,DeployerMuxaborts and returns this error. Otherwise it collects the outputs and returns all results in bulk.This is a pre-requisite for enabling multiple deployers in
skaffold.yaml.User facing changes
n/a
This PR only adds the functionality but does not enable anything.
Next PRs.
skaffold.yamlto accept multiple deployer configurations in thedeployfield.Submitter Checklist
These are the criteria that every PR should meet, please check them off as you
review them:
Reviewer Notes