The YAML schema for DockerBuild native step is as follows:
An alphanumeric string (underscores are permitted) that identifies the step.
GoPublishModule for this step type.
Description of usage
| ||May be required|
Must specify a GitRepo resource. The publish commands will run on the Git repository at
Also may specify an optional FileSpec resource that specifies what files to copy to
Must specify a BuildInfo resource when
|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 the Bash step. 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 the Bash step definition, since it's the core of the definition of all other steps.
Description of usage
|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 of the module to build.||Required|
|Repository in the Artifactory where the module will be published.||Required|
|Name of the Artifactory repository to be used to resolve dependencies.||Optional|
When specified, uses the
When set to true, force an Xray scan after publishing to Artifactory.
Default is false.
When set to true, and when the Xray Policy Rule Fail Build checkbox is checked, a failed Xray scan will result in a failure of the step.
Default is true.
When set to true, automatically publish the implicitly created BuildInfo.
Default is false.
Declares collections of shell command sequences to perform for pre- and post-execution phases:
|Tag||Description of usage||Required/Optional|
|Commands to execute in advance of the native operation||Optional|
|Commands to execute on successful completion||Optional|
|Commands to execute on failed completion||Optional|
|Commands to execute on any completion||Optional|
The actions performed for the
onExecute phase are inherent to this step type and may not be overridden.
The following examples show how to configure a GoPublishModule step.
Full Pipeline Example
- This example requires an Artifactory Integration and a GitHub Integration.
- The Pipelines DSL for this example is available in this repository in the JFrog GitHub account.
Using Default Locations
A GoPublishModule step using default locations and publishing version v0.0.0 to an Artifactory repository named go-repo.
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.
Publish Build Info and Trigger Xray Scan
A GoPublishModule step that publishes the build info and triggers an Xray scan.
How it Works
When you use the GoPublishModule native 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 (if autoPublishBuildInfo 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)