If I understand correctly I can make a build step conditional using this plugin: https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin
First does this plugin work the Post-Build steps?
Second is there a way to make Post-Build steps conditional without a plugin?
The scenario I have is I am supporting both WebDriver and Selenium IDE tests with one universal Jenkins Job setup. If they have checked in either type of test it runs them. I then want it to conditionally look if any results files show up and if so then do the publish results Post-Build step, otherwise skip that step.
Currently if no results show up it simply marks the build as a failure since no test results were found.
Any suggestions would help!
You can make any Build step execute as Post-build step.
Install Flexible Publish plugin
Install Any Build Step plugin
Under Configure System, look for "Flexible publish", and choose Any build step from drop-down.
The configure Job.
In your Job configuration, add Post-build action called "Flexible Publish".
Select condition.
Select action.
It is posssible but it is a bit messy and can not be done with ui only.
Create the the conditional build step in the build block and save the konfiguration. Edit the xml file and move the whole conditional build step it to the post build block. Reload the jenkins configuration and it works like intended.
Related
I'm running a maven build in Jenkins and my builds are failing because Jenkins isn't smart enough to clean up after my build - it just tries to delete the entire workspace and the builds fails immediatly. Is there a way to NOT have jenkins fail because of this (or even try to do it), but instead let my "mvn clean" script run first? If I can do this then I can do the specialized cleanup that is required.
I suspect that you are using Workspace Cleanup Plugin. First thing to do is to check what happens if you do it as a pre-build step, not post-build.
Alternatively there is a custom step in the build that tries to wipe out the workspace. See what happens if you invoke it as the first build step, not the last. Or try using the aforementioned plugin.
If it does not help, here are other general clenup strategies you may employ:
Start another job as a post-build step that will cleanup for the upstream job.
Have a regularly scheduled (say, nightly) job that will do the cleanup. In this case you'll probably need to 'partition' your workspace by builds - i.e. create a separate subdirectory in the workspace for every build instance (keyed by BUILD_ID) so that builds do not accidentally use leftover files from previous builds.
Have a cleanup build step in your job. In this case you do not need to create extra jobs. However, as it runs before the build is over it may not be able to cleanup completely (say, it won't be able to delete the artifacts that need to be archived in a post-build step).
To summarize: Yes, you can run you script first, just make sure it does not delete things prematurely. Also examine your job configuration for where that cleanup of yours is called and set it up as a pre-build step or remove it.
I have a C++ Builder 2010 project that's being built using TeamCity. I noticed some strange errors and after reading up on them I understand that I have to set a few variables located in rsvars.bat. I would like the build script to execute the bat file to set up the environment before performing the actual build. How do I best accomplish this?
Can I just use a <exec /> command at the very beginning of the file or is there a better way?
One way would be to run wrap the build in a script that calls rsvars.bat AND build commands. That would make the variables survive during the execution of the build.
But since I use TeamCity I like it to be a real msbuild step and not msbuild wrapped in something else. I was thinking of having the buildscript setting the variables from rsvars.bat into Machine or User at the start of the build and then remove them at the end, not nice though.
I finally just went with just adding the configurations to the Build Agents environment configuration in TeamCity and keeping installation paths identical between agents.
You can create a new build step and then specify a custom build step order so a new build step will be the first one.
See Configuring Build Steps
Add them as Build Parameters -> Environment Variables (in the build configuration), straight forward and generally works. The build parameter/environment variables will be setup automatically as environment variables on the build agent running the job.
You can then make a template of the build and reuse it.
Assumes that the 'paths' are the same on all build agents, which is generally the case. If not your suggestion of doing it by build agent is the way to go.
I am using MSBuild for CI. I was looking recently to psake as an additional tool for creating scripts for daily builds as I need to do some updates to our builds which will be easier in psake. For the moment I’m not looking to replace our existing scripts as it requires a lot of work but keep the existing ones and add new using psake.
My question is - when I create a build in TFS how can I run the psake scripts after the solution is built? My understanding is that I need to add a new target after the build is executed and execute the psake/powershell. Is this the right way to do it?
Yes that is how you would do it. It is best to separate different parts of your build script so that if you want to change something, you can proceed with ease.
So, Ideally, you should have a task for compiling your solution, another for running the tests, another for packaging the source and so on ... I recently started using psake, and this is a good reference in case you want to look up something.
The right way to do this is to use TeamCity to run your psake build scripts. In your psake scripts you would create a psake Task that calls msbuild via exec { msbuild yourSolution.sln }.
I have a Hudson job that runs a maven goal. Before this maven goal is executed I have added a step to run before the build starts, it is a shell script that obtains the version number that I want to use in the 'Goals and options' field.
So in my job configuration, under Build Environment I have checked the Configure M2 Extra Build Steps box and added a shell script before the build. The script looks like this:
export RELEASE={command to extract release version}
echo $RELEASE
And then under the Build section I point to my 'root pom'. In the Goals and options I then want to be able to do something like this:
-Dbuild.release.version=${RELEASE} deploy
Where build.release.version is a maven property referenced in the POM. However since the shell doesn't seem to make its variables global it doesn't work. Any ideas?
The only one I have is to install the Envfile plugin and get the shell script to write out the RELEASE property to a file and then get the plugin to read the file, but the order in which everything is run may cause problems and it seems like there must be simpler way...is there?
Thanks in advance.
I recently wanted to do the same, but AFAIK it's not possible to export values from a pre-build shell to the job environment. If there is a Hudson Plugin for this I've missed it.
What did work, however, was a setup similar to what you were suggesting: having the pre-build shell script write the desired value(s) to a property-file in the workspace, and then using the Parametrized Trigger Plugin to trigger another job that actually does the work (in your case, invoke the Maven job). The plugin can be configured to read the parameters it passes from the property file. So the first job has just the shell script and the post-build triggers, and the second one does the actual work, having the correct parameters available as environment variables.
General idea of the shell script:
echo "foo=bar
baz=`somecmd`" > build.properties
And for your Goals and options, something like:
-Dbuild.release.version=${foo} deploy
Granted, this isn't as elegant as one might want but worked really well for us, since our build was broken into several jobs to begin with, and we can actually reuse the other jobs that the first one triggers (that is, invoke them with different parameters).
When you say it doesn't work, do you mean that your RELEASE variable is not passed to the maven command? I believe the problem is that by default, each line of the shell script is executed separately, so environment variables get lost.
If you want the entire shell script to execute as if it was one script file, make the first line:
#!/bin/sh
I think this is described in the Help information alongside the shell script build step (and if I'm wrong, that's a good place to look for the right syntax).
I was hoping to know if there is a way to run a particular script, if and only if the build is successful. So if the build fails the script doesn't run.
Please and thank you.
You have several options.
Easiest: you have a free-style software project -- just create an addition build step at the end of your build. The step will not be executed if one of your previous step fails. I don't know how it behaves if your build is unstable.
Also easy: You have a Maven project: create a post build step (Steps to run after mvn build). You have the options to let these post build steps run on successful, successful + unstable, or always.
Create another job for your script and trigger it with the parametrized trigger plugin. This plugin gives you the most flexibility.
Hope that helps.