"skaffold deploy" is not useful #922

ahmetb · 2018-08-23T04:16:00Z

I cannot figure out the use case for "skaffold deploy".

This command is not able to populate the image tags. Without that, all it's doing is corrupting the Deployments by deploying the tag-less images.

This command cannot use the result of "skaffold build" like this (as far as I know):

skaffold build > images.txt
skaffold deploy < images.txt

Without these functionality this command just appears like a kubectl apply that is not compatible with skaffold run to me.

Please consider either making "deploy" cmd work with "build" cmd or consider eliminating to avoid confusing users.

The text was updated successfully, but these errors were encountered:

dgageot · 2018-08-23T11:25:19Z

I agree that this command is not working well.

balopat · 2018-08-23T19:43:12Z

The use case would be to use skaffold deploy as part of other orchestration tools, e.g. https://github.com/GoogleContainerTools/skaffold-tools-for-java or an IDE to call it. I think we should figure out the tagging situation with skaffold deploy.

mxey · 2018-08-24T16:12:27Z

See also #653

cliveza · 2018-08-28T15:46:48Z

Yeah, I just picked up on this too. I thought I could `

RELEASE=v1.0.0 skaffold build
RELEASE=v1.0.0 skaffold deploy

While the build command is able to build an image with the correct tag, using an environment variable and envTemplate, the deploy command just ignore this all together.

r2d4 · 2018-09-05T19:33:20Z

I think the right fix for this is that skaffold deploy should also generate the tag through the git commit tagger (or env tagger).

r2d4 · 2018-09-05T19:33:39Z

Eventually we might want to get rid of the "non-stable" taggers that rely on information from the build artifact itself

rsanders · 2018-09-21T12:41:11Z

Could skaffold build write the build artifact names to an output file that is also read by skaffold deploy? I see that it has support for outputting those, but it leaves the plumbing as an exercise for the user.

We are using skaffold in our CD pipeline, and we like having "non-stable" components like build ID in the docker image tag. We also prefer to have separate build -> test -> deploy stages.

r2d4 · 2018-09-21T17:51:18Z

@rsanders yes, skaffold build already outputs the go template of the struct that deploy uses. Deploy should be able to read from that generated output

I imagine something like

skaffold build > build.out
# do some work
skaffold deploy --build-artifacts=build.out

or

skaffold build | skaffold deploy --build-artifacts -

or

skaffold build > build.out
# do some work
skaffold deploy --build-artifacts - < build.out

balopat · 2019-02-15T23:41:52Z

cc @tejal29

FX-HAO · 2019-02-21T04:22:41Z

I can't agree with this, i use build and deploy in different pipelines. Sometimes I just need to build the image and then I can decide if we should deploy it.

tejal29 · 2019-03-20T06:58:35Z

My Implementation plan right now is

First fix skaffold build --output to write the produced build artifacts correctly. Fix skaffold build output templating #1839
Support skaffold deploy to consume this output (--build-artifacts <build-output-file>)
- [x ] Added [ DRAFT] Add two new flag types and Inputfilepath, Outputfilepath #1869 to define input and output flag types.
- Add flag --build-artifacts to skaffold deploy and get rid of --images. This is a mandatory flag.
Verify "skaffold deploy" should not run build before #1352 still exists and if it does, do not run skaffold build in skaffold deploy
~~Finally add support for git tagger or env tagger for skaffold build to tag images built.~~
will track this as a new issue Infer deployables from git tagger in skaffold deploy flow #2056

Follow-up ideas:

"explore inference use-cases": figure out if skaffold deploy can infer --build-artifacts from git tagger or env tagger definition found in skaffold.yaml plus maybe leveraging the artifact cache locally

pepjo · 2019-03-20T12:00:53Z

Is this issue linked to this one: #1352 ?

tejal29 · 2019-03-20T19:58:00Z

So with the changes as described above this is how the workflow will look like

First run skaffold build

skaffold build --quiet > build.out

( Note: untill we support git tagger or env tagger artifacts listed in build.out with be digest based)
2. Now deploy

skaffold deploy --build-artifacts build.out

Note: --build-artifacts is a new flag to skaffold deploy.

@dgageot and @balopat, i feel,
skaffold build --quiet is unhelpful from user and IDE perspective because,

If there was a built error, you only see the error on stdout. The Build log is discarded. Users or even IDE's will have to re-run the command without --quiet flag to see at what stage the build failed.
e.g.

../../out/skaffold build --quiet > test_error.out
FATA[0000] introducing an error forcefully              
tejaldesai@tejaldesai~/go/src/github.com/GoogleContainerTools/skaffold/examples/getting-started: (pr/tejal29/1841)$

Maybe we could an explicit flag to build like:

--list-built-artifacts : make it more explicit that artifacts build will be written to a file.
If this flag is present, users can still see the build output on std in addition to build results written to file.

What do you think?
This could be an additional task i can add once we all agree.

1. Inputfilepath: Inputfilepath flag, makes sure the file present exists. 2. Outputfilepath: Outputfilepath flag does not do any validation right now. Motivation: For, GoogleContainerTools#922 I am going to add `--build-output` as new flag to `skaffold build` to dump all artifacts built with with their tags. Similarly, the deploy will have additional flag `--build-artifacts` which will point to the output written by `skaffold build --build-output <file>` The Inputfilepath, can also be used to replace all the places where we expect an input file without repeating validation. ``` (add_flag_to_deploy)$ git grep 'Filename or URL to the pipeline' cmd/skaffold/app/cmd/cmd.go: cmd.Flags().StringVarP(&opts.ConfigurationFile, "filename", "f", "skaffold.yaml", "Filename or URL to the pipeline file") cmd/skaffold/app/cmd/diagnose.go: cmd.Flags().StringVarP(&opts.ConfigurationFile, "filename", "f", "skaffold.yaml", "Filename or URL to the pipeline file") cmd/skaffold/app/cmd/fix.go: cmd.Flags().StringVarP(&opts.ConfigurationFile, "filename", "f", "skaffold.yaml", "Filename or URL to the pipeline file") cmd/skaffold/app/cmd/init.go: cmd.Flags().StringVarP(&opts.ConfigurationFile, "filename", "f", "skaffold.yaml", "Filename or URL to the pipeline file") ```

pepjo · 2019-03-26T13:48:21Z

I am trying to understand the need for this when trying to deploy with an image that has already been built:

skaffold build --quiet > build.out

Our current planned use case is:

If someone triggers a pull request skaffold build should be triggered in CI (creating and pushing an image with the git commit as the tag)
When the pull request is merged CI would run skaffold deploy to deploy the image that we already created. It will use the same naming convention to try to deploy the image that corresponds to the commit. This only works if the merges are fast-forward as the git commit reference will be kept. A useful addition would be to add a flag that checks with the docker registry if the image does indeed exist and return 1 if not.

Adding the build.out is complicated (and unnecessary?) in this use case. We do continuous deployment so it's ok for us to not have meaningful docker tags (eg. with version numbers).

Will this use case be supported with the planned implementation?

tejal29 · 2019-03-26T20:09:26Z

Adding the build.out is complicated (and unnecessary?) in this use case. We do continuous deployment so it's ok for us to not have meaningful docker tags (eg. with version numbers).

The first thing we are going to address is deploy should be able to consume build output and its easier if we first implement a build.out based approach.

Will this use case be supported with the planned implementation?

@pepjo we mention your use case in follow up ideas where skaffold deploy can infer tags from git or an env variable.

pepjo · 2019-03-26T20:15:36Z

Thanks, I did not see that particular part of the comment. Thanks for the answer.

For GoogleContainerTools#922, i am making changes to `skaffold deploy` to not run `skaffold build`. `--images` flag is only used `deploy` flow. The way it works is when `--images` flag is present, runner creates a `PreBuiltImageBuilder`. All it does is, parses the images and converts them to build.Artifact. If during deploy, an image in the list was also built, then it uses the built image tag vs the tag present on the commmand line flag. In this change, we remove creating a PreBuiltImageBuilder in the runner. (Remember this flag is only available for deploy and hence other command won't get affected) The `--images` will now be converted to build.Artifact in the runner.Deploy flow.

tejal29 · 2019-04-18T22:14:10Z

#1986 fixes one of the subtasks for "Verify #1352 still exists and if it does, do not run skaffold build in skaffold deploy"

For GoogleContainerTools#922, i am making changes to `skaffold deploy` to not run `skaffold build`. `--images` flag is only used `deploy` flow. The way it works is when `--images` flag is present, runner creates a `PreBuiltImageBuilder`. All it does is, parses the images and converts them to build.Artifact. If during deploy, an image in the list was also built, then it uses the built image tag vs the tag present on the commmand line flag. In this change, we remove creating a PreBuiltImageBuilder in the runner. (Remember this flag is only available for deploy and hence other command won't get affected) The `--images` will now be converted to build.Artifact in the runner.Deploy flow.

1. Add kubectl apply command after setting labels 2. Integration tests for helms are back a. GoogleContainerTools#1823: Use env template in skaffold release name 3. During helm deploy, build is assumed and hence if no build-artifacts are supplied, it fails with following error "no build present for gcr.io/k8s-skaffold/skaffold-helm" Since Build and Deploy are now separate ( GoogleContainerTools#922 for notes) use the image value as is if not present as build artifacts TODO: 1. Add PR description 2. Figure out why we get 2 pods, 1 with valid labels which is running but another 1 with different labels.

1. Add kubectl apply command after setting labels 2. Integration tests for helms are back a. GoogleContainerTools#1823: Use env template in skaffold release name 3. During helm deploy, build is assumed and hence if no build-artifacts are supplied, it fails with following error "no build present for gcr.io/k8s-skaffold/skaffold-helm" Since Build and Deploy are now separate ( GoogleContainerTools#922 for notes) use the image value as is if not present as build artifacts Fix test fot this. TODO: 1. Add PR description 2. Figure out why we get 2 pods, 1 with valid labels which is running but another 1 with different labels.

On master, skaffold deploy fails with following error. ``` skaffold deploy -f examples/helm-deployment/skaffold.yaml Starting deploy... Error: release: "skaffold-helm" not found Helm release skaffold-helm not installed. Installing... FATA[0002] deploying skaffold-helm: matching build results to chart values: no build present for gcr.io/k8s-skaffold/skaffold-helm ``` This is because in GoogleContainerTools#922, we removed deploy triggering the build. Running deploy should use the default tag i.e. "latest" when depoying images.

dgageot added kind/bug Something isn't working kind/feature-request labels Aug 23, 2018

balopat added the priority/p2 May take a couple of releases label Aug 27, 2018

ahmetb mentioned this issue Oct 22, 2018

Ability to takeout the processed kubernetes YAML file #1187

Closed

dgageot added the area/deploy label Jan 21, 2019

balopat added this to the 1.0.0 milestone Jan 30, 2019

nkubala mentioned this issue Mar 6, 2019

Support --render options for skaffold deploy. #1739

Closed

tejal29 self-assigned this Mar 13, 2019

tejal29 mentioned this issue Mar 20, 2019

Fix skaffold build output templating #1839

Closed

tejal29 mentioned this issue Mar 20, 2019

"skaffold deploy" should not run build before #1352

Closed

tejal29 mentioned this issue Mar 20, 2019

Support for replacing image names in env vars #995

Closed

tejal29 mentioned this issue Mar 22, 2019

[ DRAFT] Add two new flag types and Inputfilepath, Outputfilepath #1869

Closed

balopat mentioned this issue Mar 26, 2019

--tail In Deploy Mode Mixes Outputs #1753

Closed

tejal29 mentioned this issue Apr 18, 2019

Remove PreBuiltImageBuilder and make it a function instead. #1986

Closed

tejal29 mentioned this issue Apr 29, 2019

Deploy to consume build output #2001

Merged

tejal29 closed this as completed in #2001 May 1, 2019

tejal29 mentioned this issue May 1, 2019

Infer deployables from git tagger in skaffold deploy flow #2056

Closed

tejal29 mentioned this issue May 10, 2019

Use Manifest Labeller for helm. #2105

Closed

tejal29 mentioned this issue May 14, 2019

Remove build dep for helm deploy #2121

Merged

tejal29 mentioned this issue Jul 23, 2019

Document end-to-end GitOps solutions #1937

Closed

AndiDog mentioned this issue Jan 23, 2020

Add option to render manifest from previous build result #3567

Merged

7 tasks

matti mentioned this issue Jul 9, 2020

skaffold deploy to support -t for tags #4455

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

"skaffold deploy" is not useful #922

"skaffold deploy" is not useful #922

ahmetb commented Aug 23, 2018 •

edited

Loading

dgageot commented Aug 23, 2018

balopat commented Aug 23, 2018 •

edited

Loading

mxey commented Aug 24, 2018

cliveza commented Aug 28, 2018

r2d4 commented Sep 5, 2018

r2d4 commented Sep 5, 2018

rsanders commented Sep 21, 2018

r2d4 commented Sep 21, 2018

balopat commented Feb 15, 2019

FX-HAO commented Feb 21, 2019

tejal29 commented Mar 20, 2019 •

edited

Loading

pepjo commented Mar 20, 2019

tejal29 commented Mar 20, 2019

pepjo commented Mar 26, 2019

tejal29 commented Mar 26, 2019 •

edited

Loading

pepjo commented Mar 26, 2019

tejal29 commented Apr 18, 2019

"skaffold deploy" is not useful #922

"skaffold deploy" is not useful #922

Comments

ahmetb commented Aug 23, 2018 • edited Loading

dgageot commented Aug 23, 2018

balopat commented Aug 23, 2018 • edited Loading

mxey commented Aug 24, 2018

cliveza commented Aug 28, 2018

r2d4 commented Sep 5, 2018

r2d4 commented Sep 5, 2018

rsanders commented Sep 21, 2018

r2d4 commented Sep 21, 2018

balopat commented Feb 15, 2019

FX-HAO commented Feb 21, 2019

tejal29 commented Mar 20, 2019 • edited Loading

pepjo commented Mar 20, 2019

tejal29 commented Mar 20, 2019

pepjo commented Mar 26, 2019

tejal29 commented Mar 26, 2019 • edited Loading

pepjo commented Mar 26, 2019

tejal29 commented Apr 18, 2019

ahmetb commented Aug 23, 2018 •

edited

Loading

balopat commented Aug 23, 2018 •

edited

Loading

tejal29 commented Mar 20, 2019 •

edited

Loading

tejal29 commented Mar 26, 2019 •

edited

Loading