chore: track customization in templates

[JoeWang1127]

Append env_vars in all kokoro build configuration files (*.cfg in .kokoro/) which contain an env_vars (key: JOB_TYPE, value: integration)

When you want to append the environment variable too all templated .cfg which has an env_vars (key: JOB_TYPE, value: integration), follow the steps below:

1. Create a partial file in the repository root directory.
   Note that the file extension should be .yaml.
2. Write customization entries in the partial file.
3. Create a pull request containing changes in step 1 - 2
4. Confirm the customizations appear in the configuration file in the same pull request after the OwlBot post processor runs.

Modify default env_vars in Kokoro build templates

You don’t need to modify existing env_vars defined in the templates because if there are multiple env_vars with the same key, the last value will be used.

Please refer to Maps in proto 3 language guide.

Example

Append env_vars in configuration files with an env_vars (key: JOB_TYPE, value: integration)

1. Add a partial file .integration-partials.yaml to the repository root.
2. In .integration-partials.yaml, add the following section:

integration: |
  env_vars: {
    key: "INTEGRATION_TEST_ARGS"
    value: "-P bigtable-emulator-it"
  }
  
  env_vars: {
    key: "GCLOUD_PROJECT"
    value: "gcloud-devel"
  }

3. Create a pull request containing the changes in step 1 - 2.

After the change

The following section will be appended to

• .kokoro/nightly/integration.cfg
• .kokoro/nightly/java11-integration.cfg
• .kokoro/presubmit/integration.cfg

env_vars: {
  key: "INTEGRATION_TEST_ARGS"
  value: "-P bigtable-emulator-it"
}

env_vars: {
  key: "GCLOUD_PROJECT"
  value: "gcloud-devel"
}

Because these files contain env_vars (key: JOB_TYPE, value: integration)

For env_var entry with key GCLOUD_PROJECT, the default value is overwritten by customized value (gcloud-devel) that appears later in the file.

Fix #1798.

[JoeWang1127]

Kokoro CI error:

>               raise CalledProcessError(retcode, process.args,
                                         output=stdout, stderr=stderr)
E               subprocess.CalledProcessError: Command '['docker', 'build', '-t', 'owlbot-php-test', '-f', 'docker/owlbot/php/Dockerfile', '.']' returned non-zero exit status 1.

/[usr/local/lib/python3.10/subprocess.py:526](https://cs.corp.google.com/piper///depot/google3/usr/local/lib/python3.10/subprocess.py?l=526): CalledProcessError
---------------------------- Captured stderr setup -----------------------------
DEPRECATED: The legacy builder is deprecated and will be removed in a future release.
            Install the buildx component to build images with BuildKit:
            [https://docs.docker.com/go/buildx/](https://www.google.com/url?q=https://docs.docker.com/go/buildx/&sa=D)

unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /tmpfs/src/github/synthtool/tests/fixtures/java_templates/partials/docker: no such file or directory

Full log.

[JoeWang1127]

Changed test directory and only lint failed:

would reformat /tmpfs/src/github/synthtool/synthtool/gcp/common.py
would reformat /tmpfs/src/github/synthtool/synthtool/languages/java.py
would reformat /tmpfs/src/github/synthtool/tests/test_language_java.py

[suztomo]

Think about the possibility of not needing partial_files arguments to java_library and _load_generic_metadata. If you still feel it's better to let users to explicitly specify the partial files, then I'm good. Approving either case.

[chingor13]

Generally, looks ok to me

addressed