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?
Related
At the moment, we are generating Jenkins jobs using the Job DSL plugin. Typically, we have the following jobs per project:
CI build (SNAPSHOT build)
Deployment, one per stage
Integration test (nightly build)
Creation of a release
Reports (Maven site, during the night)
Am I right that there can be only one Jenkins file in the project's repository? How could I map our requirements to the new Jenkins pipeline?
I'm asking because we're going to install version 2 of Jenkins, and I'm not sure whether we should abandon our Jenkins job generation and use Jenkins files.
There are a couple of options, which might help you to migrate over to Jenkins pipelines. But you don't have to, especially not all at once.
You can use a shared library to define functions that can be used in multiple jobs, e.g. a buildOurThing function.
You can trigger an existing job (of whatever kind) using the build step. So you could model your new pipeline around existing jobs.
You can still use parameterized builds, if you want to use the deployment job with different targets.
Jenkins pipeline is really worth using, but maybe don't force you to an immediate switch. If JobDSL works for you, keep it. If you have new jobs (pipelines) to create, get familiar with pipelines.
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.
we're trying to improve our Jenkins setup. So far we have two directories: /plugins and /tests.
Our project is a multi-module project of Eclipse Plugins. The test plugins in the /tests folder are fragment projects dependent on their corresponding productive code plugins in /plugins.
Until now, we had just one Jenkins job which checked out both /plugins and /tests, built all of them and produced the Surefire results etc.
We're now thinking about splitting the project into smaller jobs corresponding to features we provide. It seems that the way we tried to do it is suboptimal.
We tried the following:
We created a job for the core feature. This job checks out the whole /plugins and /tests directories and only builds the plugins the feature is comprised of. This job has a separate pom.xml which defines the core artifact and tells about the modules contained in the feature.
We created a separate job for the tests that should be run on the feature plugins. This job uses the cloned workspace from the core job. This job is to be run after the core feature is built.
I somehow think this is less than optimal.
For instance, only the core job can update the checked out files. If only the tests are updated, the core feature does not need to be built again, but it will be.
As soon as I have a feature which is dependent on the core feature, this feature would either need to use a clone of the core feature workspace or check out its own copy of /plugins and /tests, which would lead to bloat.
Using a cloned workspace, I can't update my sources. So when I have a feature depending on another feature, I can only do the job if the core feature is updated and built.
I think I'm missing some basic stuff here. Can someone help? There definitely is an easier way for this.
EDIT: I'll try to formulate what I think would ideally happen if everything works:
check if the feature components have changed (i.e. an update on them is possible)
if changed, build the feature
Build the dependent features, if necessary (i.e. check ob corresponding job)
Build the feature itself
if build successful, start feature test job
let me see the results of the test job in the feature job
Finally, the project job should
do a nightly build
check out all sources from /plugins and /tests
build all, test all, send results to Sonar
Additionally, it would be neat if the nightly build was unnecessary because the builds and test results of the projects' features would be combined in the project job results.
Is something like this possible?
Starting from the end of the question. I would keep a separate nightly job that does a clean check-out (gets rid of any generated stuff before check-out), builds everything from scratch, and runs all tests. If you aren't doing a clean build, you can't guarantee that what is checked into your repository really builds.
check if the feature components have changed (i.e. an update on them is possible)
if changed, build the feature
Build the dependent features, if necessary (i.e. check ob corresponding job)
Build the feature itself
if build successful, start feature test job
let me see the results of the test job in the feature job
[I am assuming that by "dependent features" in 1 you mean the things needed by the "feature" in 2.]
To do this, I would say that you have multiple jobs.
a job for every individual feature and every dependent feature that simply builds that feature. The jobs should be started by SCM changes for the (dependent) feature.
I wouldn't keep separate test jobs from compile jobs. It allows the possibility that successfully compiled code is never tested. Instead, I would rely on the fact that wen a build step fails in Jenkins, it normally aborts further build steps.
The trick is going to be in how you thread all of these together.
Let's say we have a feature and it's build job called F1 that is built on 2 dependent features DF1.1 and DF1.2, each with their own build jobs.
Both DF1.1 and DF1.2 should be configured to trigger the build of F1.
F1 should be configured to get the artifacts it needs from the latest successful DF1.1 and DF1.2 builds. Unfortunately, the very nice "Clone SCM" plugin is not going to be of much help here as it only pulls from one previous job. Perhaps one of the artifact publisher plugins might be useful, or you may need to add some custom build steps to put/get artifacts.
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.