In order to save on the maintenance of build definition I create one build for Gated & Publish.
I also create a release that triger when my build run as deploy (As described in the link)
When build run as deploy (not Gated) there are another tasks that run during the build:
Publish Build Artifacts - upload artifacts
Update Build Name - change the build name to "Auditing [Version]" format
Add build tag - Use to triger release
When I am try to create release manuly I get list of artifacts, some of the artifact are resualt of gated build.
In the image bellow I market the gated build.
I'm interested in keeping a clean list, is there a way to prevent from tfs to add gated build to my articact list
I am working with TFS 2018.2 On-Prem.
Thanks In advance for all.
I have two Jenkins tasks, one that builds and promotes the successful build, and another task that deploys those promoted builds. I'm using two plugins to accomplish this task, Copy Artifact Plugin and promoted builds.
The job that I have to build the code is a very standard one, I go to the git repository every minute to check for any changes, and if there are any changes I just Invoque Gradle Script on the Build step and select Use Gradle Wrapper box and everything builds without a problem. The only custom part of this build task is that I'm using promoted builds plugin, which works great and have a very standard configuration as well.
Build Configuration
I'm happy with my Build task, but I have a problem with my Deploy task. In my deploy task I want to select which promoted build I want to deploy, but I can't deploy the selected promoted build.
In my Deploy task I tick the This project is parameterised box and I selected the Promoted Build Parameter.
Promoted Build Parameter Configuration
The configuration looks ok, when I run the Deploy task I can select which build I want to deploy.
Select build to be deployed
The problem that I have is when I select Copy artifacts from another project. In Which build I select Specified by a build parameter and for the Parameter Name I selected the same name I gave to the Promoted Build Parameter
Copy artifacts from another project Configuration
But when I run this Deploy task I get this error: ERROR: Unable to find a build for artifact copy from: Aurora.
BUT if I change the Which build part to Copy from WORKSPACE of latest completed build everything works fine.
Working Configuration
What am I doing wrong in this configuration?
I was able to solve this problem, I don't think it was the cleanest way of doing it but at the end it worked. In the Build task I left everything as it was, I only added a Post-Build Action to Archive the artifacts.
Post Build Action
In the Deploy task I needed to change a bit more stuff. In my Deploy task I tick the This project is parameterised box and I selected the Promoted Build Parameter, the configuration for this step is a very standard one, I just selected the Build project and the rest is automatic. This step enables me to select which promoted build I want to deploy, but this is where the big problem resides. The value that this "step" returns is something like this https://site.name.com/job/ProjectName/137/.
The problem that this create is in Copy artifacts from another project. I need a build number, but I only have that URL, so the solution that I found was to get the build number from that URL, inject that number as a local variable and use that local variable in the next steps.
Build steps
With this solution I'm able to deploy only the promoted build.
I could click Build Now to build a jenkins job again if the job is corresponded to a specific branch.
What if the job is related with multiple branches? That is, I utilized wildcard branch specifier.
When I click Build Now, it will rebuild the last build. I'm wondering if there is a way to rebuild those previous builds.
Yes you can rebuild any build with his own parameter.
1. Install rebuild plugin.
2. select the build that you want to rebuild and press rebuild.
enter image description here
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
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.