PubSub "Payload Constraints" not working as expected


We are currently using Container Builder (rebranded recently as Cloud Build) to build and upload our docker images to GCR. Generally, we tag our docker images with a commit-sha and latest. This causes our GCR PubSub to emit two messages one for the image with each tag name. In order to prevent double builds in Spinnaker I had setup a Payload Constraint where the key: tag and value: latest. This seemed to work well enough for a while. Recently we added a pipeline that would deploy an image based on if it was tagged as dev when it was uploaded to GCR. Following the same logic as above, I updated the Payload Constraints to be key: tag and value: dev for this new pipeline.

I am noticing though that builds are getting kicked off for this new pipeline when our normal build process happens (the one resulting in a tag of latest) and I can’t figure out why. I read in the help bubble next to Payload constraints that the values can be provided as regex so I tried to be more explicit with value: ^dev$ but this caused the pipeline to not be triggered at all.

One thing to note, the pipeline DOES kick off when the dev tagged image is uploaded (while the pipeline that checks latest DOES NOT) it just also kicks off with the latest tag too.

It’s very possible I’m not understanding how this is supposed to work correctly but any help would be much appreciated!


@briananderson1222: The “tag” field in the PubSub message sent by the container registry actually contains the full image + tag name. There are examples of the formats at the bottom of this page. My guess is that your container (or registry) name contains “dev” which is triggering a match even when the tag isn’t “dev”.

You’ll probably want to either put the full image + tag name in your filter, or just include a colon in the filters the filters to make sure they’re matching the actual tag (:dev or :latest).


Thanks. I’m sure that I had seen the tag was that a while back but didn’t think there would be overlap with our tag names. You are correct, our repo name was something along the lines of which was probably matching on the dev in devops.