Artifacts & post actions

Archive results; act on success or failure.

A build usually produces something worth keeping — a compiled binary, a jar, a coverage report, a packaged image. Archiving artifacts attaches those files to the build record so you can download exactly what a given build produced, weeks later, without rebuilding. It is the difference between "we think build 412 shipped this" and "here is the precise binary build 412 made."

stage('Package') {
  steps { sh 'make dist' }
  post {
    success {
      archiveArtifacts artifacts: 'dist/**', fingerprint: true
      // fingerprint records a hash so you can trace this exact file across jobs
    }
  }
}

Artifacts vs a real registry

Jenkins artifact archiving is for build outputs you want attached to the build for convenience and traceability. It is not a distribution system — container images belong in a container registry, packages in an artifact repository (Artifactory, Nexus). The pattern is: build the image, push it to the registry (tagged with the build/commit), and archive only the small stuff (reports, manifests) in Jenkins.

post conditions do the housekeeping

The post block is where you wire outcome-driven actions: archive on success, capture logs and notify on failure, and always clean the workspace so the next build starts fresh. Because these run based on the build result, your pipeline behaves sensibly whether it passed or failed — results are saved, people are told, and disk is reclaimed, without you thinking about it each time.

post {
  success { archiveArtifacts 'dist/**' }
  failure {
    archiveArtifacts artifacts: 'logs/**', allowEmptyArchive: true
    slackSend channel: '#builds', message: "FAILED: ${env.JOB_NAME} #${env.BUILD_NUMBER}"
  }
  cleanup { cleanWs() }
}