0

I need some help with cloud build --substitutions.

This is the doc: https://cloud.google.com/cloud-build/docs/build-config#substitutions

Here is what is says:

cloudbuild.yaml

substitutions:
    _SUB_VALUE: world
options:
    substitution_option: 'ALLOW_LOOSE'

The following snippet uses substitutions to print "hello world." The ALLOW_LOOSE substitution option is set, which means the build will not return an error if there's a missing substitution variable or a missing substitution.

My case: I'm NOT using the ALLOW_LOOSE option. I need my substitutions to be required. I don't want any default values being applied. And I need it to fail immediately if I forget to pass any of the substitutions that I need.

Here is my cloudbuild.yaml file:

cloudbuild.yaml

substitutions: 
  _SERVER_ENV: required
  _TAG_NAME: required
  _MIN_INSTANCES: required

I'm initializing their default value as required specifically because I'm expecting the build call to fail if I forget to pass any of them to the gcloud builds submit call.

I'm expecting it to fail if I call gcloud builds submit and don't pass any of the defined substitutions. But it's not failing and the build completes normally without that value.

There is this observation in the docs:

Note: If your build is invoked by a trigger, the ALLOW_LOOSE option is set by default. In this case, your build will not return an error if there is a missing substitution variable or a missing substitution. You cannot override the ALLOW_LOOSE option for builds invoked by triggers.

But if I'm calling gcloud builds submit manually, that means that my build is not being invoked by any triggers, right? So the ALLOW_LOOSE options shouldn't be enabled.

Here is my full cloudbuild.yaml:

cloudbuild.yaml

steps:
  - name: "gcr.io/cloud-builders/docker"
    args:
      - "build"
      - "--build-arg" 
      - "SERVER_ENV=$_SERVER_ENV"
      - "--tag"
      - "gcr.io/$PROJECT_ID/server:$_TAG_NAME"
      - "."
    timeout: 180s

  - name: "gcr.io/cloud-builders/docker"
    args:
      - "push"
      - "gcr.io/$PROJECT_ID/server:$_TAG_NAME"
    timeout: 180s

  - name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
    entrypoint: gcloud
    args:
      - "beta"
      - "run"
      - "deploy"
      - "server"
      - "--image=gcr.io/$PROJECT_ID/server:$_TAG_NAME"
      - "--platform=managed"
      - "--region=us-central1"
      - "--min-instances=$_MIN_INSTANCES"
      - "--max-instances=3"
      - "--allow-unauthenticated"
    timeout: 180s

images: 
  - "gcr.io/$PROJECT_ID/server:$_TAG_NAME"
substitutions: 
  _SERVER_ENV: required
  _TAG_NAME: required
  _MIN_INSTANCES: required
cbdeveloper
  • 27,898
  • 37
  • 155
  • 336

1 Answers1

1

In your cloudbuild.yaml file, when you define a substituions variable you automatically set his default value

substitutions: 
  # Value = "required"
  _SERVER_ENV: required 
  # Value = ""
  _TAG_NAME: 

Try to use a variable that is not defined in the substitutions array, such as:

steps:
  - name: "gcr.io/google.com/cloudsdktool/cloud-sdk"
    entrypoint: bash 
    args:
      - -c
      - | 
         # print "required"
         echo $_SERVER_ENV 
         # print nothing
         echo $_TAG_NAME
         # Error, except if you allow loose. In this case, print nothing
         echo $_MIN_INSTANCES
substitutions: 
  _SERVER_ENV: required
  _TAG_NAME: 
guillaume blaquiere
  • 66,369
  • 2
  • 47
  • 76
  • Thank you for your answer. This is what I thought at first. But I've tried removing the `_SERVER_ENV` from the `subtitutions` property (it's not an array) and the same happens. I'll try to add the `substitution_option: "MUST_MATCH"` and see how it goes. Just found out about it [here](https://cloud.google.com/cloud-build/docs/api/reference/rest/v1/projects.builds#substitutionoption). – cbdeveloper Jan 18 '21 at 20:06
  • I'm starting to be pretty sure that this is a bug. That didn't work either. I removed the `substitutions` property completely. And didn't pass any of the expected `substitutions`. The build failed, but not because the `substitutions` where missing from the `gcloud builds submit` call, but because their missing values broke the steps that were relying on them being populated. – cbdeveloper Jan 18 '21 at 20:16
  • 1
    What!! I just tried and you are right, no error!!! Few weeks ago I got errors.... Agree, it should be a bug. – guillaume blaquiere Jan 18 '21 at 20:42
  • No luck with the PM. I opened this issue: https://issuetracker.google.com/issues/178013730 – guillaume blaquiere Jan 20 '21 at 21:07