Jenkins declarative pipelines offer a post directive to execute code after the stages have finished. Is there a similar thing to run code before the stages are running, and most importantly, before the SCM checkout?
For example something along the lines of:
pre { always { rm -rf ./* } }
This would then clean the workspace of my build before the source code is checked out.
The Conditional BuildStep plugin lets users add conditional logic to Freestyle jobs from within the Jenkins web UI. It does this by: Adding two types of Conditional BuildStep ("Single" and "Multiple") - these build steps contain one or more other build steps to be run when the configured condition is met.
The Jenkins scripted pipeline model is recommended for those who have numerous specific requirements for their continuous delivery pipeline. You may also consider leveraging a “best of both worlds” approach, by using declarative pipelines with script() step to run a created scripted pipeline.
pre
is a cool feature idea, but doesn't exist yet. skipDefaultCheckout
and checkout scm
(which is the same as the default checkout) are the keys:
pipeline { agent { label 'docker' } options { skipDefaultCheckout true } stages { stage('clean_workspace_and_checkout_source') { steps { deleteDir() checkout scm } } stage('build') { steps { echo 'i build therefore i am' } } } }
For the moment there are no pre-build
steps but for the purpose you are looking for, it can be done in the pipeline job configurarion and also multibranch pipeline jobs, when you define where is your jenkinsfile, choose Additional Behaviours -> Wipe out repository & force clone.
Delete the contents of the workspace before building, ensuring a fully fresh workspace.
If you do not really want to delete everything and save some network usage, you can just use this other option: Additional Behaviours -> Clean before checkout.
Clean up the workspace before every checkout by deleting all untracked files and directories, including those which are specified in .gitignore. It also resets all tracked files to their versioned state. This ensures that the workspace is in the same state as if you cloned and checked out in a brand-new empty directory, and ensures that your build is not affected by the files generated by the previous build.
This one will not delete the workspace but just reset the repository to the original state and pull new changes if there are some.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With