Skip to content
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.

Sign up for GitHub

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

Jump to bottom

ko builder sideload displays both correct and incorrect tag when using default tag policy #6835

Closed
halvards opened this issue Nov 11, 2021 · 2 comments · Fixed by #6928
Closed

ko builder sideload displays both correct and incorrect tag when using default tag policy #6835

halvards opened this issue Nov 11, 2021 · 2 comments · Fixed by #6928
Assignees
@halvards
Labels
build/ko kind/todo implementation task/epic for the skaffold team

Comments

@halvards
Copy link
Contributor

Expected behavior

Using the ko builder with the default tag policy results in the output displaying the correct tag name.

Actual behavior

The image builds correctly, and the correct tag is applied.

However, using the default tag policy results in the output displaying both the correct tag name and an image name with the wrong tag.

Using the sha256 tag policy results in the correct tag being displayed.

Information

Build from main at commit a9d7152

Output:

$ skaffold build --cache-artifacts=false --push=false

Generating tags...
 - skaffold-ko -> australia-southeast1-docker.pkg.dev/test/default/skaffold-ko:v1.34.0-42-ga9d715237-dirty
Starting build...
Found [minikube] context, using local docker daemon.
Building [skaffold-ko]...
2021/11/11 22:49:46 Using base gcr.io/distroless/static:nonroot for github.com/GoogleContainerTools/skaffold/examples/ko
2021/11/11 22:49:50 Building github.com/GoogleContainerTools/skaffold/examples/ko for linux/amd64
2021/11/11 22:49:51 Loading australia-southeast1-docker.pkg.dev/test/default/skaffold-ko:83b8d5fec80f5c121ff0f4365f19a679ca1bb674c8533dd7189995c882da9d13
2021/11/11 22:49:51 Loaded australia-southeast1-docker.pkg.dev/test/default/skaffold-ko:83b8d5fec80f5c121ff0f4365f19a679ca1bb674c8533dd7189995c882da9d13
2021/11/11 22:49:51 Adding tag v1.34.0-42-ga9d715237-dirty
2021/11/11 22:49:51 Added tag v1.34.0-42-ga9d715237-dirty
australia-southeast1-docker.pkg.dev//default/skaffold-ko:83b8d5fec80f5c121ff0f4365f19a679ca1bb674c8533dd7189995c882da9d13

The image australia-southeast1-docker.pkg.dev//default/skaffold-ko:v1.34.0-42-ga9d715237-dirty is correctly built and exists in the local Docker daemon after the build is done.
@halvards halvards self-assigned this Nov 11, 2021
halvards added a commit to halvards/skaffold that referenced this issue Nov 11, 2021
@halvards
fix(ko): Display correct tag
b0da432 
Display the expected tag after successfully building a ko image, for
both sideloaded and published images.

Also handles the `tagPolicy.sha256` scenarios.

Fixes: GoogleContainerTools#6835
Tracking: GoogleContainerTools#6041
@halvards halvards mentioned this issue Nov 11, 2021
Closed
halvards added a commit to halvards/skaffold that referenced this issue Nov 11, 2021
@halvards
fix(ko): Display correct tag
8033e5a 
Display the expected tag after successfully building a ko image, for
both sideloaded and published images.

Also handles the `tagPolicy.sha256` scenarios.

Fixes: GoogleContainerTools#6835
Tracking: GoogleContainerTools#6041
@briandealwis
Copy link
Member

The final image ref also seems to be missing the test repository component:
....dev//default/skaffold-ko... vs
...dev/test/default/skaffold-ko...

@halvards
Copy link
Contributor Author

That may have been me editing out the project ID... :-)

@briandealwis briandealwis added the kind/todo implementation task/epic for the skaffold team label Nov 13, 2021
halvards added a commit to halvards/skaffold that referenced this issue Dec 3, 2021
@halvards
fix(ko): Do not print image name to stdout
373c210 
With this change, the `ko` builder no longer prints the image name to
`stdout` by default.

Originally, this was added to the `ko` builder to mimic the behavior of
the `ko` CLI. Other Skaffold image builders do not print the image name
in this way.

The reason this is useful for existing `ko` CLI users is that some
documented workflows rely on capturing the image name from `stdout`, see
https://github.com/google/ko/blob/v0.9.3/README.md#build-an-image

After some investigation, the better option seems to be to rely on the
existing `--quiet` and `--output` Skaffold flags to format the output of
the image name(s).

This change also updates the `ko` builder documentation to show existing
`ko` CLI users how to capture the image name by providing an appropriate
Go template to `--output`.

Fixes: GoogleContainerTools#6835
Closes: GoogleContainerTools#6836
Tracking: GoogleContainerTools#6041
@halvards halvards mentioned this issue Dec 3, 2021
Merged
halvards added a commit to halvards/skaffold that referenced this issue Dec 3, 2021
@halvards
fix(ko): Do not print image name to stdout
4a34ec7 
With this change, the `ko` builder no longer prints the image name to
`stdout` by default.

Originally, this was added to the `ko` builder to mimic the behavior of
the `ko` CLI. Other Skaffold image builders do not print the image name
in this way.

The reason this is useful for existing `ko` CLI users is that some
documented workflows rely on capturing the image name from `stdout`, see
https://github.com/google/ko/blob/v0.9.3/README.md#build-an-image

After some investigation, the better option seems to be to rely on the
existing `--quiet` and `--output` Skaffold flags to format the output of
the image name(s).

This change also updates the `ko` builder documentation to show existing
`ko` CLI users how to capture the image name by providing an appropriate
Go template to `--output`.

Fixes: GoogleContainerTools#6835
Closes: GoogleContainerTools#6836
Tracking: GoogleContainerTools#6041
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@halvards halvards

Labels
build/ko kind/todo implementation task/epic for the skaffold team
Projects
None yet
Milestone
No milestone
2 participants
@halvards @briandealwis