Two builds created for a single image

[trisberg]

I created a riff function that in turn creates an image resource. This image resource ended up having two builds created for it:

$ kubectl get images.build.pivotal.io
NAME                    LATESTIMAGE                                                                                               READY
square-function-42dl7   index.docker.io/trisberg/square@sha256:cff3dc342ba638814c3c75ae350e7d2ee580791fdbe6d65eafd1f8526a0abc0e   True
$ kubectl get builds.build.pivotal.io
NAME                                  IMAGE                                                                                                     SUCCEEDED
square-function-42dl7-build-1-c8dr6   index.docker.io/trisberg/square@sha256:cff3dc342ba638814c3c75ae350e7d2ee580791fdbe6d65eafd1f8526a0abc0e   True
square-function-42dl7-build-1-mm7hf   index.docker.io/trisberg/square@sha256:cff3dc342ba638814c3c75ae350e7d2ee580791fdbe6d65eafd1f8526a0abc0e   True
$ kubectl get pods
NAME                                            READY   STATUS        RESTARTS   AGE
square-function-42dl7-build-1-c8dr6-build-pod   0/1     Completed     0          13m
square-function-42dl7-build-1-mm7hf-build-pod   0/1     Completed     0          13m

I've attached the kpack controller log. I'll add comments if I see this happening again.

kpack.log

The kpack version is v0.0.5

[matthewmcnew]

This looks like it is a known race condition which we had non observed in the wild, yet.

[trisberg]

Happened again today, any progress on this?

default           inventory-api-application-dqvdb-build-1-ns7mp-build-pod   0/1     Init:4/7   0          2m42s
default           inventory-api-application-dqvdb-build-1-zrmqq-build-pod   0/1     Init:4/7   0          2m42s

[thisisnotashwin]

Hey @trisberg

We haven't had the bandwidth to get around to this just yet. Will bring it tomorrow and get this prioritized.

Thanks for being patient.

[matthewmcnew]

#847 should resolve this issue.