Ive set up deployment in hudson. SVN > Build > copy to production. I need to set up a schedule build to test for build error which is running every hour or so. What I dont want is the schedules builds to deploy to production.
Is it posible to detect, in nant, if the current build is a scheduled build or a manually started build. Or should I create a seperate project for the schedule build?
The cleanest option is to create a separate job for your scheduled build; you can then keep other artifacts like test results separated (since I assume your scheduled job will be running a different set of tests).
If you're just running the scheduled job to look for build errors, this will also keep the checked-out code that you're building separate from the triggered builds, which will minimize the risk of the production builds getting polluted with artifacts created by the test build.
Related
I have implemented Hudson master, slave job configuration and it is working fine. In which i have to run 2 scripts in a job from hudson master. can you help me is there possibility to run 2 scripts? as well both scripts are dependencies like the second should run after the first script executed.
Thanks in advance - sri
All you need to do is include the script as a build step in your current build for example.
Pull down source
Build it
Run the script, as part of the build step.
This option is only available for Free Style Jobs.
Here is where the scripts would go or path to script to execute.
Goodluck.
I have a job in Hudson server A which builds an artifact and deploys it to Nexus. I have another job in a completely separate Hudson server B which needs to download the artifact and deploy it. This job is normally run manually, and the person running it needs to indicate which version of the artifact to deploy - they may not always want to deploy the latest version (e.g. to roll back to a previous known good version).
Currently, I achieve this by using a parameterized build, and require the user to pass in the artifact version number; the job then uses the Execute shell build step to run wget on a URL constructed using the parameter. This is error prone.
Ideally I'd like a plugin that lets the user browse the artifact versions in the Nexus repository and pick and choose the one to deploy, but I'm open to other suggestions. A plugin that also handles the download would be nice, but I can live without it as long as I can still get a string that I can use in shell commands.
I've looked through the available Hudson & Jenkins plugins around Maven style artifact repositories, but they all seem more concerned with pushing artifacts into repos rather than getting them back down.
I'm using Hudson's "Copy Artifact" in other jobs, to get artifacts from other Hudson jobs on the same server, but this doesn't work across different Hudson servers, which is why I've turned to Nexus (which we're already using anyway).
Does anyone have any suggestions?
I recommend using rundeck to execute your deployments.
There is a rundeck plugin for Nexus that enables rundeck to display a pull down menu of available versions in Nexus.
There is a rundeck plugin for Jenkins that can be used to invoke deployments using rundeck and kick-off post deployment jobs (like integration testing) inn Jenkins.
Oure teamcity server (6.5) configured to checkout sources from SVN. For some build proceess cases I need checkout previous successfully builded version(revision). Can teamcity do this? And if can, how to configure checkout?
It sounds like you're looking for TeamCity Snapshot Dependencies, with the "Only use successful builds from suitable ones" option.
You'd end up with two build configurations:
Performs initial builds on commit to SVN
Has a snapshot dependency on #1, so when this build runs (either automatically - via a trigger - or manually), it grabs the same sources as the last successful build of #1.
Both of the build configurations would use the same VCS root.
I have a bunch of Maven projects building in Hudson with Sonar sitting in the side-lines. Sonar gives me Sonar stats, FindBugs stats, and code-coverage.
I've noticed that regardless of if I use Sonar or if I use EMMA via Maven directly, the entire build cycle runs twice. This includes init (which in my case, reinitializes the database -- expensive) and unit tests (a few hundred -- also expensive).
How can I prevent this? I did a lot of reading, and it seems like this is due to the design of code-coverage plugins -- to keep uninstrumented classes separated from instrumented ones.
I've tried configurations like:
Maven runs: deploy, EMMA
Maven runs: deploy; deploy to Sonar on completion
The sonar documentation recommends running the sonar plugin in 2 stages:-
mvn clean install -Dtest=false -DfailIfNoTests=false
mvn sonar:sonar
The tests are bypassed in the first phase and run implicitly in the second stage.
A one line alternative is to run the following command:-
mvn clean install sonar:sonar -Dmaven.test.failure.ignore=true
but this will run the tests twice - as you have found.
To add to #Strawberry's answer, you could reuse the unit test reports instead of running them again. Refer to the section Reuse existing unit test reports in the sonar documentation
Once this is done, you can configure the following in Hudson
clean deploy sonar:sonar
I can't find where I can configure the parameters that hudson uses in CVS checkout and update.
I have a situation where I modify build properties file locally before I kick off a hudson build. However because the cvs update contains a '-C' it overwrites my local changes. Do you know of a way where I can remove this?
Any help much appreciated,
Paul
You are confusing me. How do you change the build properties locally before kicking off the build? If I need to do something like that, I first get the code from my SCM and then run a script to make changes (like changing the build properties) and than start the actual build process (usually by kicking off maven or ant). The whole purpose of a CI (what Hudson is supposed to be used for) is to have a reproducible build. Manual steps during a build usually do not count as reproducible.