Skip to content

Add logic for creating default deployer in runner #5541

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

Merged
merged 2 commits into from
Mar 12, 2021

Conversation

nkubala
Copy link
Contributor

@nkubala nkubala commented Mar 12, 2021

This change adds logic for creating a default deployer, to create arbitrary resources provided as hydrated manifests to skaffold apply. This will create a kubectl deployer, regardless of deploy configuration from the provided skaffold.yaml (except for a select set of configuration passed to the kubectl deployer itself).

As per the comment in code:

The "default deployer" is used in skaffold apply, which uses a kubectl deployer to actuate resources
on a cluster regardless of provided deployer configuration in the skaffold.yaml.
The default deployer will honor a select set of deploy configuration from an existing skaffold.yaml:

  • deploy.StatusCheckDeadlineSeconds
  • deploy.Logs.Prefix
  • deploy.Kubectl.Flags
  • deploy.Kubectl.DefaultNamespace
  • deploy.Kustomize.Flags
  • deploy.Kustomize.DefaultNamespace

For a multi-config project, we do not currently support resolving conflicts between differing sets of this deploy configuration.
Therefore, in this function we do implicit validation of the provided configuration, and fail if any conflict cannot be resolved.

Part 1 of #4856

@nkubala nkubala requested a review from a team as a code owner March 12, 2021 19:39
@google-cla google-cla bot added the cla: yes label Mar 12, 2021
@codecov
Copy link

codecov bot commented Mar 12, 2021

Codecov Report

Merging #5541 (74dbec1) into master (f241521) will decrease coverage by 0.17%.
The diff coverage is 53.44%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #5541      +/-   ##
==========================================
- Coverage   71.39%   71.21%   -0.18%     
==========================================
  Files         400      400              
  Lines       14839    14934      +95     
==========================================
+ Hits        10594    10635      +41     
- Misses       3473     3511      +38     
- Partials      772      788      +16     
Impacted Files Coverage Δ
pkg/skaffold/deploy/status/status_check.go 50.75% <0.00%> (ø)
pkg/skaffold/runner/new.go 63.13% <50.94%> (-4.46%) ⬇️
pkg/skaffold/runner/runcontext/context.go 79.27% <100.00%> (+0.77%) ⬆️
pkg/skaffold/util/tar.go 50.66% <0.00%> (-5.34%) ⬇️
pkg/skaffold/docker/image.go 78.13% <0.00%> (-1.40%) ⬇️
pkg/skaffold/test/custom/error.go 6.66% <0.00%> (-0.93%) ⬇️
pkg/skaffold/test/custom/custom.go 56.17% <0.00%> (-0.28%) ⬇️
pkg/skaffold/docker/parse.go 85.40% <0.00%> (+1.08%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f241521...74dbec1. Read the comment docs.

@@ -233,6 +236,107 @@ func getSyncer(cfg sync.Config) sync.Syncer {
return sync.NewSyncer(cfg)
}

/*
The "default deployer" is used in `skaffold apply`, which uses a `kubectl` deployer to actuate resources
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we move this to pkg/skaffold/apply/deployer.go or something similar?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah it probably should....i didn't do it here because it's a bigger refactor and i didn't want to mix organization patterns. let me go take a stab at the refactor though, new PR pending

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

my comment was only scoped to the new function added. Are you talking about refactoring your other PR? This function doesn't seem to be used anywhere else.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ahh sorry i misread your comment, i thought you were suggesting putting it in pkg/skaffold/deploy. i actually think that's where it should be, so the runner would make calls like deploy.GetDeployer and build.GetBuilder instead of having private getDeployer and getBuilder functions which do pre-processing and then instantiate.

IMO this pattern makes more sense, but is a bigger refactor, so rather than set an example with this PR (but have mismatched organization patterns) i decided to just put it alongside the pre-existing getDeployer function. i can move it to an apply package so it's more clear what it's used for though.

separately - this PR just adds this logic for ease of review, it's only actually used in the other PR which adds the apply command.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make sense. I thought it's putting too many things in new.go.

Copy link
Contributor

@gsquared94 gsquared94 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants