0

Problem: I am trying to deploy a function with this step in a second level compilation (second-level-compilation.yaml)

- name: 'gcr.io/cloud-builders/gcloud'
  args: ['beta', 'functions',
       'deploy', '${_FUNCTION_NAME}',
       '--source', 'path/to/function',
       '--runtime', 'go111',
       '--region', '${_GCP_CLOUD_FUNCTION_REGION}',
       '--entry-point', '${_ENTRYPOINT}',
       '--env-vars-file', '${_FUNCTION_PATH}/.env.${_DEPLOY_ENV}.yaml',
       '--trigger-topic', '${_TRIGGER_TOPIC_NAME}',
       '--timeout', '${_FUNCTION_TIMEOUT}',
       '--service-account', '${_SERVICE_ACCOUNT}']

I get this error from Cloud Build using the Console.

Step #1: Step #11: ERROR: (gcloud.beta.functions.deploy) Error creating a ZIP archive with the source code for directory path/to/function: ZIP does not support timestamps before 1980

Here is the global flow:

  1. The following step is in a first-level compilation (first-level-compilation.yaml). Which is triggered by Cloud build using a Github repository (via Application GitHub Cloud Build) :

    - name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args: ['-c', 'launch-second-level-compilation.sh ${_MY_VAR}']

  2. The script "launch-second-level-compilation.sh" does specific operations based on ${_MY_VAR} and then launches a second-level compilation passing a lot of substitutions variables with "gcloud builds submit --config=second-level-compilation.yaml --substitutions=_FUNCTION_NAME=val,_GCP_CLOUD_FUNCTION_REGION=val,....."

  3. Then, the "second-level-compilation.yaml" described at the beginning of this question is executed, using the substitutions values generated and passed through the launch-second-level-compilation.sh script.

The main idea here is to have a generic first-level-compilation.yaml in charge of calling a second-level compilation with specific dynamically generated substitutions.

Attempts / Investigations

  1. As described in this issue Cloud Container Builder, ZIP does not support timestamps before 1980, I tried to "ls" the files in the /workspace directory. But none of the files at the /workspace root have strange DATE.

  2. I changed the path/to/function from a relative path to /workspace/path/to/function, but no success, without surprise as the directory ends to be the same.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
Dorian
  • 13
  • 5
  • In your "ls" test, did you list the files recursively? What about the date/time of the /workspace directory itself? – Kolban Nov 18 '19 at 05:52
  • Have you been able to deploy a Go Cloud Function without the extra indirection? Probably unrelated, Go Cloud Functions are out of beta, so you don't need the beta arg in the gcloud command. – Tyler B Nov 25 '19 at 20:12
  • Thank you for your feedback. We finally moved to only one level compilation for the moment. More readable implementation but needs more specific things and variables to define explicitly prior to deployment. – Dorian Nov 26 '19 at 09:48

1 Answers1

0

Please make sure you don't have folders without files. For example:

|--dir
   |--subdir1
   |  |--file1
   |--subdir2
      |--file2

In this example dir doesn't directly contain any file, only subdirectories. During local deployment gcp sdk puts dir into tarball without copying last modified field. So it is set to 1st Jan 1970 that causes problems with ZIP.

As possible workaround just make sure every directory contains at least one file.

SBond
  • 59
  • 4