We are using Hudson for our builds and deploys. Currently we have four main jobs: BUILD, DEPLOY-DEV, DEPLOY-TEST, and DEPLOY-PROD.
The BUILD job is parameterized, so we can assign new version numbers and augment them with the BUILD_NUMBER managed by Hudson. This works very well. We also have a "nightlybuild" parameter that defaults to false. Our intention is to only set this via another Hudson job.
We are trying to have an automated NIGHTLY-BUILD job that first calls our BUILD job with the "nightlybuild" parameter set and once that is successful, call the DEPLOY-DEV job. We also want to call out to a SONAR job to analyze the code, but for this question, the 2-step solution is sufficient.
For the NIGHTLY-BUILD job, the only way to call a parameterized job that I can figure out is the post-build action of "Trigger parameterized build on other projects". I can't trigger off of the BUILD job directly because the "nightlybuild" default is false and I also don't want to trigger off any manula builds. I also have a NIGHTLY-DEPLOY that has a build trigger of "Build after other projects are built" on NIGHTLY-BUILD. Since these are both ultimately post build actions they trigger at the same time instead of consecutively.
Started by user anonymous
Triggering a new build of BUILD #49
Triggering a new build of NIGHTLY-DEPLOY #3
Triggering a new build of NIGHTTY-SONAR #3
[DEBUG] Skipping watched dependency update; build not configured with trigger: NIGHTLY-BUILD #5
Finished: SUCCESS
When I start the build, it completes in a few seconds and starts the BUILD and DEPLOY concurrently, so as a new version is building, the old version is deploying. Not what I want.
I looked at and downloaded the "Build Pipeline Plugin", but it looks like it just relies on the same post build actions for the automatic transitions and adds new functionality for manual transitions.
Does anyone have any suggestions on how to resolve this issue?
Use Parameterized Trigger plugin as a build step, not post-build step. Then it has an option to wait for the downstream build to complete.
Note: this works with Jenkins, I can't guarantee that this option exists in the Hudson version of the plugin.
Related
In the hudson job configuration I only find the opportunity to trigger a time controlled build. But I am searching for a solution which enables me a time controlled release build.
Difference between "normal" build and Releasebuild in this case:
Build: Maven-Build, which generates artifacts
Releasebuild: Mavenbuild + pre-/post-build steps by ant
Has anybody an idea?
Since your "release" build does not follow CI principles, and actually performs another build (with pre/post steps, then why not create another job just for the release and set an appropriate timer?
My build project have 3 steps:
-file preparation
-deployment
-functional tests
I have set all the dependencies between them, but I really wish also to hook the deployment step to the functional test, so that if the functional test are running and new code is committed the deployment wait till the functional tests finish.
I know there are the build triggering, the dependencies and the artifact dependencies but each of them doesn't seem good for my case.
The first run a deployment every time the functional test step finish and obviously is not what I want.
The second force the deployment to use the same code as in the functional test instead it should use new freshly committed code and for the third is more or less the same situation.
Where I'm thinking wrong? I'm missing something or there's a shortcut to use to make this working?
You can create 2 build configurations:
"Functional tests" configuration with VCS trigger.
"Deployment" configuration with snapshot dependency on first configuration and also VCS trigger (or other trigger, e.g. Schedule trigger with 'Trigger build only if there are pending changes' option selected).
Files will be deployed only if functional tests not failed on same code base.
It is what you need?
The group that I work in has standardized on Jenkins for Continuous Integration builds. Code check-in triggers a standard build, Cobertura analysis and publish to an Artifactory SNAPSHOT repo. I've just finished adding a new target to the master build file that'll kick off a Sonar run but I don't want that running on every check-in.
Is there a way to schedule a nightly build of a specific build target in Jenkins? Jenkins obviously facilitates scheduled builds but it'll run the project's regular build every time. I'd like to be able to schedule the Sonar build target to run nightly.
I could, of course, create a separate Jenkins project just to run the Sonar target on a schedule but I'm trying to avoid that if I can. Our Jenkins server already has several hundred builds on it; doubling that for the sake of scheduling nightly builds isn't very desirable. I looked for a Jenkins plug-in that might facilitate this but I couldn't find anything. Any suggestions?
Here's one way to do it, if you are ok with triggering the build using cron or some other scheduling tool:
Make the build parameterized, and use a parameter in your build file to decide if the Sonar build target should run or not.
Trigger the build remotely by HTTP POST:ing the parameter values as a form to http://[jenkins-host]/jobs/[jobname]/buildWithParameters. Depending on your Jenkins version and configuration, you might need to add an Authentication Token and include this in your url.
Authenticate your POST using a username and password.
wget --auth-no-challenge --http-user=USERNAME --http-password=PASSWORD "https://[jenkins-host]/job/[jobname]/buildWithParameters?token=<token defined in job configuration>&<param>=<value>&<param2>=<value2>"
I am also looking for a solution for this. My current solution in my mind is to create 2 triggers in the regular build, one is the nightly build, another one is Polling SCM
In the sonar plugin configuration, it has the options to skip the builds triggered by the SCM change. Therefore, only the nightly build will start a sonar analysis.
I didn't get a chance to test it now, but I suppose this will work.
Updated on 12/19/2011
The above solution doesn't work if the sonar analysis is invoked as a standalone build step. To make the sonar analysis run conditionally, you could use the following 2 plugins:
Conditional BuildStep Plugin - this allows the sonar analysis to be run conditionally
Jenkins Environment Injector Plug-in - this allows you to inject the variables to indicate how the build is triggered.
I have created many build configurations in Hudson for a single solution (eg. Release, Debug, Test)
When I commit something wrong, I receive 1 build failed e-mail for every build configuration.
I would like to receive a single e-mail.
I think if I could to make one build dependent on the success or failure of another, I could receive less e-mails.
How to do that?
BTW: I use MsBuild, Subversion and NAnt
It sounds like you have multiple jobs (build configurations) for the same set of source code that are configured to always build. You could, as someone else suggested, use build triggers to chain these jobs together. However, if all the jobs run on each commit, I suggest combining the jobs into a single job with multiple steps. That way when one step fails, the entire build will fail, no unnecessary Hudson cycles will be spent, and you will not receive redundant emails. To add steps to a build, click "Add build step" and select "Invoke Ant" (or whatever other action you want it to take).
You can use the build trigger "build after other projects are build" to put projects up- or downstream from one another. Then you typically let the lighter builds go first (like simple compile).
We are using TeamCity Enterprise v.9.1.1
Is there a way to trigger some action after build is complete?
I have tried adding last build step but it executed before artifacts are published.
Update: I am not looking for deployment solution. I need a way to specify generic action on build completion.
There's no generic solution at the moment.
You might want vote for the Post build task feature.
Possible workarounds include:
adding dependent build configuration (using Trigger)
creating new TeamCity plugin (e.g. custom notifier plugin, such as teamcity-slack-integration one)