YAML Schema
The YAML schema for DockerPush native step is as follows:
管道:名称:<字符串>步骤:-名称:<字符串> type: DockerPush configuration: #inherits all the tags from bash; //www.si-fil.com/confluence/display/JFROG/Bash affinityGroup:targetRepository: # may be required. Must be a local repository. Virtual repositories are not supported. forceXrayScan: # default false failOnScan: # default true autoPublishBuildInfo: # default false integrations: - name: # required inputSteps: - name: # required outputResources: - name: # optional - name: # required if autoPublishBuildInfo is true execution: onStart: - echo "Preparing for work..." onSuccess: - echo "Job well done!" onFailure: - echo "uh oh, something went wrong" onComplete: - echo "Cleaning up some stuff"
Tags
name
Analphanumericstring (underscores are permitted) that identifies the step.
type
Must beDockerPushfor this step type.
configuration
Specifies all configuration selections for the step's execution environment.This step inherits theBash/PowerShellstep configuration tags, including these pertinenttags:
Tag |
Description of usage |
Required/Optional |
|---|---|---|
affinityGroup |
Must specify an affinity group string that is the same as specifiedin a priorDockerBuildstep. | Optional |
integrations |
Must specify anArtifactory Integration. | Required |
inputSteps |
Typically theDockerBuildstep that built the image. The DockerBuild step must always be in the same affinity group, but other steps, such as Bash or PowerShell, are also permitted in the same affinity group, between DockerBuild and DockerPush. | May be Required |
outputResources |
May specify anImageresource. If one is specified, the Must specify aBuildInforesource if |
Optional May be required |
In addition, these tags can be defined to support the step's native operation:
Tags derived from Bash
来自本地所有步骤Bashstep. This means that all steps share the same base set of tags from Bash, while native steps have their own additional tags as well as that support the step's particular function. So it's important to be familiar with theBashstep definition, since it's the core of the definition of all other steps.
Tag |
Description of usage |
Required/Optional |
|---|---|---|
targetRepository |
The name of the Docker repository in Artifactory. Required when using JFrog CLI v1 and not used when the pipeline is configured to use JFrog CLI v2. Must be a local repository. Virtual repositories are not supported. |
May be required |
forceXrayScan |
When Default is |
Optional |
failOnScan |
When set to Default is |
Optional |
autoPublishBuildInfo |
When set to Default is |
Optional |
execution
Declares collections of shell command sequences to perform for pre- and post-execution phases:
| Tag | Description of usage | Required/Optional |
|---|---|---|
onStart |
Commands to execute in advance of the native operation | Optional |
onSuccess |
Commands to execute on successful completion | Optional |
onFailure |
Commands to execute on failed completion | Optional |
onComplete |
Commands to execute on any completion | Optional |
The actions performed for theonExecutephase are inherent to this step type and may not be overridden.
Examples
The following examples show how to configure a DockerPush step to push a Docker image.
Push Image to Artifactory
Pushes the image created by the DockerBuild input step to Artifactory. Does not trigger a scan.
- This example requires anArtifactory Integrationand aGitHub Integration.
- 管道DSLfor this example isavailable inthis repositoryin theJFrogGitHub account.
- For a full tutorial, seePipeline Example: Docker Build and Push.
# This config file is templatized so that it can be easily customized. Values can be provided with a values.yml file. template: true # required for local templates valuesFilePath: ./values.yml resources: - name: app_repo1 type: GitRepo configuration: gitProvider: {{ .Values.gitIntegration }} path: {{ .Values.gitRepositoryPath }} branches: include: master - name: app_buildinfo1 type: BuildInfo configuration: sourceArtifactory: {{ .Values.artifactoryIntegration }} - name: app_promoted_buildinfo1 type: BuildInfo configuration: sourceArtifactory: {{ .Values.artifactoryIntegration }} pipelines: - name: app_dev_pipeline steps: - name: app_build type: DockerBuild configuration: affinityGroup: docker_group dockerFileLocation: . dockerFileName: Dockerfile dockerImageName: {{ .Values.artifactoryUrl }}/{{ .Values.sourceRepository }}/{{ .Values.imageName }} dockerImageTag: ${run_number} inputResources: - name: app_repo integrations: - name: {{ .Values.artifactoryIntegration }} - name: app_push type: DockerPush configuration: affinityGroup: docker_group targetRepository: {{ .Values.sourceRepository }} integrations: - name: {{ .Values.artifactoryIntegration }} inputSteps: - name: app_build - name: publish_app_build type: PublishBuildInfo configuration: affinityGroup: docker_group inputSteps: - name: app_push outputResources: - name: app_buildinfo
Affinity Group
This extends one of theDockerBuild examples, pushing that image to Artifactory. Note that an affinity group has been specified in both steps.
pipelines: - name: demo_pipeline steps: - name: bld_image type: DockerBuild configuration: affinityGroup: dockerGroup dockerFileLocation: . dockerFileName: Dockerfile dockerImageName: docker.artprod.mycompany.com/gosvc # replace with your fully qualified Docker registry/image name dockerImageTag: ${run_number} dockerOptions: --build-arg build_number_env_variable=${run_number} inputResources: - name: gosvc_app integrations: - name: MyArtifactory - name: dockerPushStep type: DockerPush configuration: affinityGroup: dockerGroup targetRepository: dockerRepo inputSteps: - name: bld_image outputResources: - name: outputBuildInfo integrations: - name: MyArtifactory
Publish Build Info, Trigger Xray Scan, Update Output Image Resource
In this, publishing build info, triggering an Xray scan, and updating an output Image resource has been added to the previous example.
pipelines: - name: demo_pipeline steps: - name: bld_image type: DockerBuild configuration: affinityGroup: dockerGroup dockerFileLocation: . dockerFileName: Dockerfile dockerImageName: docker.artprod.mycompany.com/gosvc # replace with your fully qualified Docker registry/image name dockerImageTag: ${run_number} dockerOptions: --build-arg build_number_env_variable=${run_number} inputResources: - name: gosvc_app integrations: - name: MyArtifactory - name: dockerPushStep type: DockerPush configuration: affinityGroup: dockerGroup targetRepository: dockerRepo autoPublishBuildInfo: true forceXrayScan: true inputSteps: - name: bld_image outputResources: - name: outputBuildInfo - name: outputImage integrations: - name: MyArtifactory
How it Works
When you use theDockerPushnative step in a pipeline, it performs the following functions in the background:
- jfrog rt use (to set the current default Artifactory configuration to the one set up for the integration in
integrations) - restore_run_files (copy the build information saved from the DockerBuild step)
- jfrog rt docker-push (push the image to Artifactory)
- jfrog rt build-publish (if
autoPublishBuildInfois true, publish the build info) - write_output (if
autoPublishBuildInfois true, update the BuildInfo buildName and buildNumber) - write_output (if there is an output Image resource, update the Image imageTag)
- jfrog rt build-scan (ifforceXrayScanis true, trigger a scan)
- add_run_files (save/update the build information in the run state for later publish steps)
