jenkins post build step and action - what is the difference - jenkins

Might sound like a very basic question - but I am unable to find any article which explains why Jenkins provides a post build step as well as action.
In Jenkins - I do see that the options are different in post build step vs. action, but
what is the order of execution?
When should we use which option?
What are the best practices?

At a glance, here is Jenkins' job workflow (without additional plugins)
[On demand, if needed] Install tools, (such as JDK, Ant, Maven, etc).
[Optional] Perform SCM checkout, (such as SVN or Git).
Perform build step(s), (such as build Ant project, compile code, etc).
[Optional] Perform post-build steps(s), (such as Archive Artifacts, send email, etc).
There are plugins that allow to perform actions right after Tools installation, such as Pre-SCM-step and EnvInject plugins. There are also plugins that add a lot more possible Build Steps and Post-build steps.
The difference between Build and Post-build steps is based partially on logical separation, partially on workflow configuration.
From the logical perspective, when you build/compile a project, that's a "Build" step, whereas when you Archive Artifacts, since that happens after the build, that's a "Post-build" step.
But there is also workflow configuration considerations, and it has everything to do with:
"When do the the builds fail", and with
"Build Status" (such as Success, Unstable, Failed)
When there are multiple "Build" steps, Jenkins:
Executes the first build step
Checks for exit code of the first build step
If exit code is 0 (success), Jenkins continues to next build step (if there is one)
If exit code is not 0 (failure), Jenkins marks build as FAILED, and continues to Post-build actions.
Jenkins executes Post-build steps (regardless if build was marked FAILED or not)
So, in other words:
If Build step succeeds, Jenkins can execute the following Build steps (if any).
If Build step fails, Jenkins will not execute the following Build steps.
If all Build steps succeeded, Jenkins will mark build SUCCESS.
If any Build step failed, Jenkins will mark build FAILED.
Post-build steps are executed regardless of Build Status (FAILED or not).
Technically, all post-build steps should be executed at all times, however in practice, if a Post-build step exceptions, the job never completes which can lead to some Post-build steps not being executed.
Also, generally Post-build steps do not change the Build Status, but there are some that are specifically designed to do that (for example, when Archiving Artifacts, you can choose to mark build FAILED if not all artifacts are found, even if after all Build steps, the build was marked SUCCESS)
So, knowing the above, it's your responsibility to design your job, and decide what steps need to be executed one after another, only if previous was successful, and will affect the Build Status (i.e. Build steps), and what steps need to happen at all times regardless of result (i.e Post-build steps).
EDIT:
Since I keep getting comments, here is a screenshot of a brand new clean installation of Jenkins (Windows) ver.1.634 (as was mentioned in comments).
On the screenshot, note the following:
New Freestyle project.
Scrollbar all the way down, there is nothing more on page.
Version 1.634 (as requested).
Build section with Add build step drop down.
Post-build Actions section with Add post-build action drop down.
So, to re-iterate my previous comment:
There is only one post-build "anything"
whether you want to call it "step" or "action" (Jenkins changed the labeling over the years).
Custom plugins can add a lot of extras, but for a clean install a basic job is just as I have described.

For an item (job) created as a Maven project build steps are not configurable (only the maven goals are configurable for the build), so two new extra categories are available to configure: pre-build step and post-build step.
In my experience pre/post-build step are used to execute actions that can influence the build result (such as Sonar Analysis), and post-build actions for actions to be performed based on the build's result (such as e-mail notifications).

Clarification. Post build Step can be set to only execute when build has a specific status. i.e. if failed do something (send logs to someone?) if passed or unstable do something. i.e. tag the source so that it can be promoted for release?
Post build action is ALWAYS executed. There is where you send emails, archive artifacts, send artifacts to master (if using slaves and have the plugin), etc.
I use the Post build Step to tag/label the successfully built source code in my GIT workspace. I use a small script to do that.
Now I just wish that Post Build step was available in Freestyle jobs since it is such a great option for only tagging successful builds.

Related

what did jenkins actually build?

I created a freestyle project in jenkins, in which I chose source code management as git, screenshot below
That's pretty my config. The repo you see in there is public repo. then I save the config, then I click build now.
It seems to works base on the notification on screen, which says 'success'. But I have no idea I what the heck Jenkins produced. I didn't instruct what to build and how to build. How does it know what I want? And lets say it did build something, where does it store the build? I didn't instruct it where to store the built file either. Can someone explain what is going on?
To actually build something you need to add something to your Build section in the project configuration. For a javascript configuration it might look something like:
npm install
npm run test-coverage
npm run linter
npm run complexity
where each item after run is a script in your package.json. Then you can add plugins to read the outputs of those actions, for example:
Clover test coverage publisher
TAP (Test) results publisher
HTML Publisher for publishing static analysis results
Checkstyle publisher for linting results
This allows you to pass and fail builds based on certain test criteria and where continuous integration starts to shine.
In Jenkins job you have several sections - you can define pre build actions to prepare the environment, SCM to check out from source control, Build section to run your build pipeline and post build operation to run actions after the build section.
If you defined only the SCM section all your job did is to check out your sources from the source control you provided. the status of this action is SUCCESS.
Don't forget to check the console output of the job that ran to see which steps ran.

How can I get notified if part of my build fails prior to running my Maven goals with Jenkins?

I’m using Jenkins v 1.61 with Java 7. I have a Maven job set up, using SVN for Source Code Management. I have a “Run buildstep before SCM runs” set up (courtesy of the pre-scm-buildstep plugin) and a pre-build step (a short script) set up prior to the Maven goals being run.
My question is, if any of these steps fails, how can I get notified via email of the failure?
Use Jenkins Mailer Plugin, This plugin allows you to configure email notifications for build results.
Plugin ID mailer
Latest Release 1.18
Latest Release Date Sep 04, 2016
Required Core 1.625.3
E-Mail notifications are configured in jobs by adding an E-mail notification Post-build Action. If configured, Jenkins will send out an e-mail to the specified recipients when a certain important event occurs:
Every failed build triggers a new e-mail.
A successful build after a failed (or unstable) build triggers a new
e-mail, indicating that a crisis is over.
An unstable build after a successful build triggers a new e-mail,
indicating that there's a regression.
Unless configured, every unstable build triggers a new e-mail,
indicating that regression is still there.
How about combining pre-scm-buildstep, conditional-buildstep and any-buildstep plugin.
This should allow you to run a publisher step like sending email notifications on a regular build step or a pre scm build step (feature provided by any-buildstep plugin). You could also add a condition check (feature provided by the conditional-buildstep plugin) on the pre-scm-buildstep phase.
You've mentioned that you use a short script prior to the pre-scm-buildstep, just in case you're exporting environment variables as input for your conditional check, remember that you'll also need to write that to a properties file (SEND_EMAIL=true >> my-job.properties) and use env inject plugin to load them on your job environment variables, freestyle jobs don't persist exported shell variables on build steps to be visible to the next steps that come after it.
Lot's of plugins right? Quite annoying. If you want something more elegant, I would recommend using pipeline as code plugin and wrapping everything on a try/catch/finally block, so you could raise an exception before the code checkout stage given a failed check, there are some examples in this article.

How to prevent older builds from entering stage with concurrency 1

We've setup a Jenkins build pipeline that uses Maven to build a large project, including stages for update, compile, unit test and deploy (to Nexus). The "deploy to Nexus" stage has concurrency 1 to ensure that no more than one build is in this stage at any point in time. However, this setting does not prevent older builds from entering that stage after a later build has finished it.
For instance, if build #2 is startet after build #1 and hits a fast node, it may outrun build #1 and enter the "deploy to Nexus" stage first. Build #1 cannot enter this stage at the same time, so it waits until build #2 is finished; but then build #1 enters this stage and thus overrides the Maven artifacts deployed by the later build, which is not what you want.
There must be a way to avoid this, i.e. to prevent older builds from entering a stage that was already executed successfully by later builds. I just could not find a solution for this problem... Any thoughts?
The upcoming milestone step is supposed to solve this.
Send the current build number of the job and add a simple condition to test it with the latest successful build number of the job using the following Jenkins URL:
http://JenkinsMaster:Port/job/MyJob/lastSuccessfulBuild/buildNumber
If the current build number is smaller than the last successful one then skip the upload.
Good Luck!

Trigger Jenkins Build with "Poll SCM" AND "Build after other projects are built"

I'd like to trigger the nightly cq build ONLY if last commit build was successful.
Currently I have the cq build being triggered with a scm poll at midnight, but I would like to include the additional condition that another build (the last commit build) was successful. Because it makes no sense letting the slow cq build run just to inevitably fail.
The build triggers section of a build have multiple ways of triggering a build including when another build is finished, but as far as I can tell these triggers happen if any one of them is selected I want to effectively AND the "Build after other projects are built" and "Poll SCM" conditions together.
I've looked at https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin
but that's about putting conditions on a build step, not conditionally triggering the build as a whole.
and
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin
but that's about launching another build from another.
Does anyone know how to do this?
Regards,
Phil.
I think you want the Build Result Trigger plugin

Jenkins: Multiple tasks or build dependent project after first (even if first fails)

I have some reports that I would like to push up to Github after my main project target builds.
These reports should be pushed up whether the first project succeeds or not. Can Jenkins do either of the following:
Specify multiple tasks (like Bamboo).
Build another project after the first, even if the first fails.
Reading your comment on the other Answers I propose this solution for you Jasper
Keep you existing project that builds and generates your reports and create a new project that you might call "report uploader" which only uploads your reports to your git.
1) Main Project Build
this will build you system, run it and test it (resulting in some reports, let's call them REPORT.o)
this project might or might not fail
REPORT.o should be archived as artifacts then the build is finished
the job should always trigger the "report uploader" job - Use the parameterized build trigger plugging
make sure this job has the checkbox wait for downstream jobs (else a new job might be started and overwrite the report files)
2) Report uploader Build
this will project will take arguments from the upstream job to find the artifacts
fetch them and upload them to whatever server you like to have
The same concept is loosely described on jenkins wiki
hope this fits your need
Yes.
With Git publisher you can push to a branch and choose whether or not to only do so when the build succeeds.
There is also a post-build action where you can build other projects and an option to do so even if the build fails.

Resources