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.
appNameFromManifestcfPushbuildCommitShacleanUpArtifactscreateArtifactuploadToArtifactory
You can also use pipeline libraries to make sure teams adhere to their specific naming conventions. See these examples:
nextVersionisFeatureBranchisReleaseBranch
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.