serving: Digest resolution not working?

/area build

I am using knative-serving along with tekton and kaniko. In a multi step Task my image is getting built and pushed to a private registry (yes, it supports api version 2) using kaniko. Then the next step runs a kn command to create a new Revision for the KService.

Unfortunately in the last step kn does resolve the digest and logs Service 'develop' with latest revision 'develop-00003' (unchanged) is available at URL:. However, when I run docker pull ... in the node CLI, kn creates a new revision (if triggered).

I have read this doc https://knative.dev/docs/serving/tag-resolution/ and i am sure i did not enable the digest resolution skipping.

I appreciate if you shed some light on this. Or have i just found a bug?

About this issue

Original URL
State: closed
Created 3 years ago
Comments: 16 (5 by maintainers)

Most upvoted comments

@xclud sorry for being late to the game. Your use case is very valid and we have some support from the client side to force an update of the image from the client side:

Use client side generated revision names with --revision-name (e.g. using a pattern like {{.Service}}-{{.Random 5}}-{{.Generation}}). This will force a new revision on every kn service update call. There might be a bug that prevents this (see https://github.com/knative/client/issues/1318) but in general this used to work, but also triggers a redeployment if nothing really has changed for the image (e.g. the tag points to the same digest as before)
Update a custom (dummy) annotation (or any other field) that triggers the creation of a new revision

However, the real solution is probably a fix on the server-side that allows the user to specify the behaviour for images updates on an UPDATE API (aka POST) for an Knative service. Should the image be checked for a new version or not, if the image name has not changed in that update call ? I believe the proper solution would be to introduce a similar concept like for ImagePullPolicy in the container spec, or maybe even reuse this for this purpose. I don’t even know if ImagePullPolicy has any effect for a container spec in a Knative context.

There is an ongoing discussion around this issue (see the latest Client WG call), so you might want to keep an eye on https://github.com/knative/client/issues/1329 and https://github.com/knative/client/issues/1318 .

rhuss on Jun 1, 2021

Thank you @nikhil-thomas. This solves my problem.

xclud on May 10, 2021

it should work in both cases. if we are writing sha to /tekton/results/<sha-result-name> file, from one step, then we can read the sha from another step from the same/tekton/results/<sha-result-name> file. in other words, from the context of a step (container) every result is a file in /tekton/results

infact, you can use the variable expansion, $(results.<result-name>.path).

nikhil-thomas on May 10, 2021