gcp_cloudbuild_trigger – Creates a GCP Trigger

From Get docs
Ansible/docs/2.9/modules/gcp cloudbuild trigger module


gcp_cloudbuild_trigger – Creates a GCP Trigger

New in version 2.8.


Synopsis

  • Configuration for an automated build in response to source repository changes.

Requirements

The below requirements are needed on the host that executes this module.

  • python >= 2.6
  • requests >= 2.18.4
  • google-auth >= 1.3.0

Parameters

Parameter Choices/Defaults Comments

auth_kind

string / required

  • application
  • machineaccount
  • serviceaccount

The type of credential used.

build

dictionary

Contents of the build template. Either a filename or build template must be provided.

images

list

A list of images to be pushed upon the successful completion of all build steps.

The images are pushed using the builder service account's credentials.

The digests of the pushed images will be stored in the Build resource's results field.

If any of the images fail to be pushed, the build status is marked FAILURE.

steps

list

The operations to be performed on the workspace.

args

list

A list of arguments that will be presented to the step when it is started.

If the image used to run the step's container has an entrypoint, the args are used as arguments to that entrypoint. If the image does not define an entrypoint, the first element in args is used as the entrypoint, and the remainder will be used as arguments.

dir

string

Working directory to use when running this step's container.

If this value is a relative path, it is relative to the build's working directory. If this value is absolute, it may be outside the build's working directory, in which case the contents of the path may not be persisted across build step executions, unless a `volume` for that path is specified.

If the build specifies a `RepoSource` with `dir` and a step with a `dir`, which specifies an absolute path, the `RepoSource` `dir` is ignored for the step's execution.

entrypoint

string

Entrypoint to be used instead of the build step image's default entrypoint.

If unset, the image's default entrypoint is used .

env

list

A list of environment variable definitions to be used when running a step.

The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".

id

string

Unique identifier for this build step, used in `wait_for` to reference this build step as a dependency.

name

string

The name of the container image that will run this particular build step.

If the image is available in the host's Docker daemon's cache, it will be run directly. If not, the host will attempt to pull the image first, using the builder service account's credentials if necessary.

The Docker daemon's cache will already have the latest versions of all of the officially supported build steps (https://github.com/GoogleCloudPlatform/cloud-builders).

The Docker daemon will also have cached many of the layers for some popular images, like "ubuntu", "debian", but they will be refreshed at the time you attempt to use them.

If you built an image in a previous build step, it will be stored in the host's Docker daemon's cache and is available to use as the name for a later build step.

secret_env

list

A list of environment variables which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's `Secret`.

timeout

string

Time limit for executing this build step. If not defined, the step has no time limit and will be allowed to continue to run until either it completes or the build itself times out.

timing

string

Output only. Stores timing information for executing this build step.

volumes

list

List of volumes to mount into the build step.

Each volume is created as an empty volume prior to execution of the build step. Upon completion of the build, volumes and their contents are discarded.

Using a named volume in only one step is not valid as it is indicative of a build request with an incorrect configuration.

name

string

Name of the volume to mount.

Volume names must be unique per build step and must be valid names for Docker volumes. Each named volume must be used by at least two build steps.

path

string

Path at which to mount the volume.

Paths must be absolute and cannot conflict with other volume paths on the same build step or with certain reserved volume paths.

wait_for

list

The ID(s) of the step(s) that this build step depends on.

This build step will not start until all the build steps in `wait_for` have completed successfully. If `wait_for` is empty, this build step will start when all previous build steps in the `Build.Steps` list have completed successfully.

tags

list

Tags for annotation of a Build. These are not docker tags.

description

string

Human-readable description of the trigger.

disabled

boolean

  • no
  • yes

Whether the trigger is disabled or not. If true, the trigger will never result in a build.

env_type

string

Specifies which Ansible environment you're running this module within.

This should not be set unless you know what you're doing.

This only alters the User Agent string for any API requests.

filename

string

Path, from the source root, to a file whose contents is used for the template. Either a filename or build template must be provided.

id

string

The unique identifier for the trigger.

ignored_files

list

ignoredFiles and includedFiles are file glob matches using http://godoc/pkg/path/filepath#Match extended with support for `**`.

If ignoredFiles and changed files are both empty, then they are not used to determine whether or not to trigger a build.

If ignoredFiles is not empty, then we ignore any files that match any of the ignored_file globs. If the change has no files that are outside of the ignoredFiles globs, then we do not trigger a build.

included_files

list

ignoredFiles and includedFiles are file glob matches using http://godoc/pkg/path/filepath#Match extended with support for `**`.

If any of the files altered in the commit pass the ignoredFiles filter and includedFiles is empty, then as far as this filter is concerned, we should trigger the build.

If any of the files altered in the commit pass the ignoredFiles filter and includedFiles is not empty, then we make sure that at least one of those files matches a includedFiles glob. If not, then we do not trigger a build.

project

string

The Google Cloud Platform project to use.

scopes

list

Array of scopes to be used.

service_account_contents

jsonarg

The contents of a Service Account JSON file, either in a dictionary or as a JSON string that represents it.

service_account_email

string

An optional service account email address if machineaccount is selected and the user does not wish to use the default email.

service_account_file

path

The path of a Service Account JSON file if serviceaccount is selected as type.

state

string

  • present

  • absent

Whether the given object should exist in GCP

substitutions

dictionary

Substitutions data for Build resource.

trigger_template

dictionary

Template describing the types of source changes to trigger a build.

Branch and tag names in trigger templates are interpreted as regular expressions. Any branch or tag change that matches that regular expression will trigger a build.

branch_name

string

Name of the branch to build. Exactly one a of branch name, tag, or commit SHA must be provided.

commit_sha

string

Explicit commit SHA to build. Exactly one of a branch name, tag, or commit SHA must be provided.

dir

string

Directory, relative to the source root, in which to run the build.

This must be a relative path. If a step's dir is specified and is an absolute path, this value is ignored for that step's execution.

project_id

string

ID of the project that owns the Cloud Source Repository. If omitted, the project ID requesting the build is assumed.

repo_name

string

Default:

"default"

Name of the Cloud Source Repository. If omitted, the name "default" is assumed.

tag_name

string

Name of the tag to build. Exactly one of a branch name, tag, or commit SHA must be provided.



Notes

Note

  • API Reference: https://cloud.google.com/cloud-build/docs/api/reference/rest/
  • Automating builds using build triggers: https://cloud.google.com/cloud-build/docs/running-builds/automate-builds
  • The id for this resource is created by the API after you create the resource the first time. If you want to manage this resource after creation, you’ll have to copy the generated id into the playbook. If you do not, new triggers will be created on subsequent runs.
  • for authentication, you can set service_account_file using the c(gcp_service_account_file) env variable.
  • for authentication, you can set service_account_contents using the c(GCP_SERVICE_ACCOUNT_CONTENTS) env variable.
  • For authentication, you can set service_account_email using the GCP_SERVICE_ACCOUNT_EMAIL env variable.
  • For authentication, you can set auth_kind using the GCP_AUTH_KIND env variable.
  • For authentication, you can set scopes using the GCP_SCOPES env variable.
  • Environment variables values will only be used if the playbook values are not set.
  • The service_account_email and service_account_file options are mutually exclusive.


Examples

- name: create a repository
  gcp_sourcerepo_repository:
    name: projects/{{ gcp_project }}/repos/{{ resource_name }}
    project: "{{ gcp_project }}"
    auth_kind: "{{ gcp_cred_kind }}"
    service_account_file: "{{ gcp_cred_file }}"
    state: present

- name: create a trigger
  gcp_cloudbuild_trigger:
    trigger_template:
      branch_name: master
      project_id: test_project
      repo_name: test_object
    filename: cloudbuild.yaml
    project: test_project
    auth_kind: serviceaccount
    service_account_file: "/tmp/auth.pem"
    state: present

Return Values

Common return values are documented here, the following are the fields unique to this module:

Key Returned Description

build

complex

success

Contents of the build template. Either a filename or build template must be provided.


images

list

success

A list of images to be pushed upon the successful completion of all build steps.

The images are pushed using the builder service account's credentials.

The digests of the pushed images will be stored in the Build resource's results field.

If any of the images fail to be pushed, the build status is marked FAILURE.


steps

complex

success

The operations to be performed on the workspace.


args

list

success

A list of arguments that will be presented to the step when it is started.

If the image used to run the step's container has an entrypoint, the args are used as arguments to that entrypoint. If the image does not define an entrypoint, the first element in args is used as the entrypoint, and the remainder will be used as arguments.


dir

string

success

Working directory to use when running this step's container.

If this value is a relative path, it is relative to the build's working directory. If this value is absolute, it may be outside the build's working directory, in which case the contents of the path may not be persisted across build step executions, unless a `volume` for that path is specified.

If the build specifies a `RepoSource` with `dir` and a step with a `dir`, which specifies an absolute path, the `RepoSource` `dir` is ignored for the step's execution.


entrypoint

string

success

Entrypoint to be used instead of the build step image's default entrypoint.

If unset, the image's default entrypoint is used .


env

list

success

A list of environment variable definitions to be used when running a step.

The elements are of the form "KEY=VALUE" for the environment variable "KEY" being given the value "VALUE".


id

string

success

Unique identifier for this build step, used in `wait_for` to reference this build step as a dependency.


name

string

success

The name of the container image that will run this particular build step.

If the image is available in the host's Docker daemon's cache, it will be run directly. If not, the host will attempt to pull the image first, using the builder service account's credentials if necessary.

The Docker daemon's cache will already have the latest versions of all of the officially supported build steps (https://github.com/GoogleCloudPlatform/cloud-builders).

The Docker daemon will also have cached many of the layers for some popular images, like "ubuntu", "debian", but they will be refreshed at the time you attempt to use them.

If you built an image in a previous build step, it will be stored in the host's Docker daemon's cache and is available to use as the name for a later build step.


secretEnv

list

success

A list of environment variables which are encrypted using a Cloud Key Management Service crypto key. These values must be specified in the build's `Secret`.


timeout

string

success

Time limit for executing this build step. If not defined, the step has no time limit and will be allowed to continue to run until either it completes or the build itself times out.


timing

string

success

Output only. Stores timing information for executing this build step.


volumes

complex

success

List of volumes to mount into the build step.

Each volume is created as an empty volume prior to execution of the build step. Upon completion of the build, volumes and their contents are discarded.

Using a named volume in only one step is not valid as it is indicative of a build request with an incorrect configuration.


name

string

success

Name of the volume to mount.

Volume names must be unique per build step and must be valid names for Docker volumes. Each named volume must be used by at least two build steps.


path

string

success

Path at which to mount the volume.

Paths must be absolute and cannot conflict with other volume paths on the same build step or with certain reserved volume paths.


waitFor

list

success

The ID(s) of the step(s) that this build step depends on.

This build step will not start until all the build steps in `wait_for` have completed successfully. If `wait_for` is empty, this build step will start when all previous build steps in the `Build.Steps` list have completed successfully.


tags

list

success

Tags for annotation of a Build. These are not docker tags.


createTime

string

success

Time when the trigger was created.


description

string

success

Human-readable description of the trigger.


disabled

boolean

success

Whether the trigger is disabled or not. If true, the trigger will never result in a build.


filename

string

success

Path, from the source root, to a file whose contents is used for the template. Either a filename or build template must be provided.


id

string

success

The unique identifier for the trigger.


ignoredFiles

list

success

ignoredFiles and includedFiles are file glob matches using http://godoc/pkg/path/filepath#Match extended with support for `**`.

If ignoredFiles and changed files are both empty, then they are not used to determine whether or not to trigger a build.

If ignoredFiles is not empty, then we ignore any files that match any of the ignored_file globs. If the change has no files that are outside of the ignoredFiles globs, then we do not trigger a build.


includedFiles

list

success

ignoredFiles and includedFiles are file glob matches using http://godoc/pkg/path/filepath#Match extended with support for `**`.

If any of the files altered in the commit pass the ignoredFiles filter and includedFiles is empty, then as far as this filter is concerned, we should trigger the build.

If any of the files altered in the commit pass the ignoredFiles filter and includedFiles is not empty, then we make sure that at least one of those files matches a includedFiles glob. If not, then we do not trigger a build.


substitutions

dictionary

success

Substitutions data for Build resource.


triggerTemplate

complex

success

Template describing the types of source changes to trigger a build.

Branch and tag names in trigger templates are interpreted as regular expressions. Any branch or tag change that matches that regular expression will trigger a build.


branchName

string

success

Name of the branch to build. Exactly one a of branch name, tag, or commit SHA must be provided.


commitSha

string

success

Explicit commit SHA to build. Exactly one of a branch name, tag, or commit SHA must be provided.


dir

string

success

Directory, relative to the source root, in which to run the build.

This must be a relative path. If a step's dir is specified and is an absolute path, this value is ignored for that step's execution.


projectId

string

success

ID of the project that owns the Cloud Source Repository. If omitted, the project ID requesting the build is assumed.


repoName

string

success

Name of the Cloud Source Repository. If omitted, the name "default" is assumed.


tagName

string

success

Name of the tag to build. Exactly one of a branch name, tag, or commit SHA must be provided.





Status

Authors

  • Google Inc. (@googlecloudplatform)

Hint

If you notice any issues in this documentation, you can edit this document to improve it.


© 2012–2018 Michael DeHaan
© 2018–2019 Red Hat, Inc.
Licensed under the GNU General Public License version 3.
https://docs.ansible.com/ansible/2.9/modules/gcp_cloudbuild_trigger_module.html