YAML Schema
The YAML schema for DockerBuild native step is as follows:
pipelines: - name:steps: - name: type: GoPublishModule configuration: #inherits all the tags from bash; //www.si-fil.com/confluence/display/JFROG/Bash forceXrayScan: # optional failOnScan: # default true autoPublishBuildInfo: # optional # for payloadType module: sourceLocation: # optional version: # required targetRepository: # required self: # optional deps: # optional resolverRepo: # optional integrations: - name: # required if autoPublishBuildInfo is false inputResources: - name: # required - name: # optional outputResources: - 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: #always - echo "Cleaning up some stuff"
Tags
name
Analphanumericstring (underscores are permitted) that identifies the step.
type
Must beGoPublishModulefor 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 |
|---|---|---|
integrations |
Specifies anArtifactory Integration. Required when |
May be required |
inputResources |
Must specify aGitReporesource.发布命令将运行在Git复位器y at Also may specify an optionalFileSpecresource that specifies what files to copy to |
Required Optional |
outputResources |
Must specify aBuildInforesourcewhen If |
May be required |
In addition, these tags can be defined to support the step's native operation:
Tags derived from Bash
All native steps derive from theBashstep. This means that all steps share the same base set of tags from Bash, while native steps have their own additional tags as well 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 |
|---|---|---|
sourceLocation |
Location of the Go source files relative to the root of the input GitRepo repository. If not specified, the default is the root of the GitRepo repository. | Optional |
version |
Version of the module to build. | Required |
targetRepository |
Repository in the Artifactory where the module will be published. | Required |
resolverRepo |
Name of the Artifactory repository to be used to resolve dependencies. | Optional |
self |
When true, uses the--selfoption to publish the project to Artifactory. For more information, see theCLI for JFrog Artifactory documentation. |
Optional |
deps |
When specified, uses the |
Optional |
forceXrayScan |
When set to true, force an Xray scan after publishing to Artifactory. Default is false. |
Optional |
failOnScan |
When set totrue, andwhen the XrayPolicy RuleFail Buildcheckbox is checked, a failed Xray scan will result in a failure of the step. Default is true. |
Optional |
autoPublishBuildInfo |
When set to true, automatically publish the implicitly created BuildInfo. Default is false. |
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 GoPublishModule step.
Full Pipeline Example
- This example requires anArtifactory Integrationand aGitHub Integration.
- The Pipelines DSL for this example isavailable inthis repositoryin theJFrogGitHub account.
#这个配置文件模板,以便它可以be easily customized. Values can be provided with a values.yml file. template: true # required for local templates valuesFilePath: ./values.yml resources: # Sample Go app in a GitRepo - name: go_repo type: GitRepo configuration: path: {{ .Values.repoPath }} branches: include: main gitProvider: {{ .Values.gitProvider }} # Build info for the published Go app - name: go_buildinfo type: BuildInfo configuration: sourceArtifactory: {{ .Values.artifactory }} pipelines: - name: go_publish_binary_example steps: # Build the Go sample app from the GitRepo. Docs at //www.si-fil.com/confluence/display/JFROG/GoBuild - name: build_go type: GoBuild configuration: sourceLocation: . resolverRepo: go-virtual noRegistry: true inputResources: - name: go_repo integrations: - name: {{ .Values.artifactory }} # Publish the Go sample app binary to Artifactory - name: cicd_go_publish_binary type: GoPublishBinary configuration: # forceXrayScan: true # failOnScan: false autoPublishBuildInfo: true inputSteps: - name: build_go targetRepository: go-local integrations: - name: myArtifactory outputResources: - name: go_buildinfo
Using Default Locations
A GoPublishModule step using default locations and publishing version v0.0.0 to an Artifactory repository named go-repo.
pipelines: - name: goPublishModulePipeline steps: - name: goPublishModuleStep type: GoPublishModule configuration: version: "v0.0.0" targetRepository: go-repo inputResources: - name: gitRepoResource integrations: - name: artifactory_integration
Different Source Location in the GitRepo
A GoPublishModule step specifying a different source location in the GitRepo and publishing the project and dependencies to the Artifactory repository named go-repo as well.
pipelines: - name: goPublishModulePipeline steps: - name: goPublishModuleStep type: GoPublishModule configuration: version: "v0.0.${run_number}" targetRepository: go-repo resolverRepo: go-virtual self: true deps: ALL inputResources: - name: gitRepoResource integrations: - name: artifactory_integration
Publish Build Info and Trigger Xray Scan
A GoPublishModule step that publishes the build info and triggers an Xray scan.
pipelines: - name: goPublishModulePipeline steps: - name: goPublishModuleStep type: GoPublishModule configuration: version: "v0.0.${run_number}" targetRepository: go-repo autoPublishBuildInfo: true forceXrayScan: true inputResources: - name: gitRepoResource outputResources: - name: outputBuildInfo integrations: - name: artifactory_integration
How it Works
When you use theGoPublishModulenative step in a pipeline, it performs the following functions in the background:
- jfrog config add (if there is an output BuildInfo resource, configure the JFrog CLI with the Artifactory credentials in that resource)
- jfrog config use (to set the current default Artifactory configuration)
- cp (if there is an input FileSpec, copy the files to the root of the cloned GitRepo)
- jfrog rt go-config (configure the repository to resolve dependencies)
- jfrog rt go-publish (publish)
- add_run_variables (save information about this step for future steps)
- jfrog rt build-collect-env (collect environment variables)
- jfrog rt build-publish (if autoPublishBuildInfo is true, publish the build info)
- write_output (ifautoPublishBuildInfo is true, update the output resource)
- jfrog rt build-scan (if forceXrayScan is true, trigger a scan)
- add_run_files (save the build information in the run state for later publish steps)
