When creating custom pipelines, shared code and patterns can be extrapolated into shared libraries, which are imported into your pipelines like so:
@Library('demo-pipeline-library') _
This is a working library and features integrations with
This demo pipeline library includes global variables defined in groovy files in the vars/
subfolder, which are singletons and automatically instantiated:
Consider making these methods available to all teams across your organization.
appNameFromManifest
cfPush
buildCommitSha
cleanUpArtifacts
createArtifact
uploadToArtifactory
You can also use pipeline libraries to make sure teams adhere to their specific naming conventions. See these examples:
nextVersion
isFeatureBranch
isReleaseBranch
Some are standard helpers like isFeatureBranch()
which commmunicate what is happening and hide the how. Others accept closures, for example createArtifact
or uploadToArtifactory
, which do the same and enable a declarative syntax that is easier to understand (and debug!)
post {
success {
script {
createArtifact {
prefix = 'artifact-'
version = nextVersion()
sha = buildCommitSha()
}
uploadToArtifactory {
pattern = 'artifact-*.zip'
target = 'snapshot-local/cidemo-frontend/'
}
cleanUpArtifacts()
}
}
}
When you create libraries that you want to be used, pay attention to the design of your domain specific language (DSL). A beautiful DSL let's developers ship without worrying about how something works. Aim for clear DSLs for greater long-term productivity.