My project uses ANT build system. Currently, I am giving build via shell command for my project. Say when I give "ant dev deploy" from cmd prompt(see below image for a successful build via cmd prompt) the build starts and in between it stops for confirmation from user. In the below image, I have highlighted the runtime value passed "dev", which is passed as a confirmation variable, then the build continues based on the value passed.
This is how it should be and it was working correctly till now.
![Successful ANT build via cmd prompt][1]
Currently I am automating this build via hudson. I have given the value "ant dev deploy" in the targets of the Build properties in hudson. But, now I dont know how to configure to get the value "dev" in between the build progress. During my trial, I was getting error for that. Below, I have given the logs from Hudson.
Is there anyway I can pass the value on runtime.?
Sorry I am not able post images. Can clarify if any questions.
Oops! Your question couldn't be submitted because:
•We're sorry, but as a spam prevention mechanism, new users aren't allowed to post images. Earn more than 10 reputation to post images
You cannot pass a value to Hudson in the middle of the build. You need to supply that at the time of triggering the build. Hudson is not interactive, so anything in your current process that requires user prompting half way through needs to be redesigned.
All your user prompting needs to be done through build parameters at the beginning of the build. In the job configuration, check mark This build is parameterized. If you want to restrict the possible values, a "Choice" parameter is best. Give it a name, for example CHOICE1, give it a list of possible choices. When the build is manually triggered, the user could choose one of the choices from a drop-down, and then start the build. Note that this will not work with builds that are automatically triggered.
Next, you need to pass this value to your ANT script. In your Invoke Ant build step, click "Advanced" button, and under "Properties" you can pass variables to your ANT script:
antScriptVar=$CHOICE1
Above, $CHOICE1 is the reference to the Hudson build parameter, it will contain the value the user selected from the drop-down when starting the build. The antScriptVar is your variable in ANT script that will have this value. You can define the empty variable in ANT script with
<property name="antScriptVar" value="" />
When Hudson triggers the ANT script, it will populate this variable with the build variable. From then onwards, use it like you would any other variable in ANT
Related
This seems simple enough, but I can't find a solution for this online.
I am integrating SonarQube into our build definitions that get triggered on check in. I want the version SonarQube uses to be tied back to the project number defined by the business side of things.
Ideally, I would like to be able to prompt the user for input. When you go to check in and it kicks off the build, it would ask you for the project number to be used as the version for SonarQube. Is this something TFS 2015 supports?
User input for build definitions
As far as I know, build definitions that are not manually triggered do not prompt for user input. A prompt allowing users to set build variables is shown for manually triggered builds from the VSTS web page.
SonarQube project version
I would recommend against you using the build or assembly version in your build tasks. This is because the SonarQube concept of version is quite different from the build concept. SonarQube uses versions as a baselining mechanism / to determine the leak period. If you up the version number often, the leak period is going to be too short to be actionable.
I'd recommend keeping the SonarQube project version in sync with your release schedule instead.
The short answer to this question is no, there is no way to prompt for input on a non-manually triggered CI build.
Here's what we did to work around this:
I wrote a Powershell script to read a config file and set the values to environment variables exposed to later build steps. Those variables are then what are specified in the Sonar Begin Analysis build task. I packaged that script up as a custom build task that will read a "sonar.config" file. This means all we have to do is add a "sonar.config" file to each solution we want to run Sonar analysis for, defining the key, name and version for the project, and then this build task will populate all necessary environment variables as the first step in the build.
So not a perfect solution, but it gets the job done without us having to add a lot of extra code to our solutions.
I am using TFS 2010 and have a build machine that contains a single build controller running 2 agents.
I have worked out that I can assign a tag of "Nightly" to my 2nd agent and then edit the Build Definition for my Nightly Builds in TFS to only use an agent that has the tag of "Nightly".
Easy enough.
However, the issue here is that if a normal build (Such as dev/CI) came along, it could - in theory- use my nightly agent, which I don't want to happen.
I could go around all our development builds (20+) and add in a tags=normal and tag my primary build agent with normal, but this then relies on people remembering to tag up new builds in the future.
Is there a way to set up my build agent in TFS's Server Admin, so that it will ONLY run items with specific tags? Or is my "go around the houses" approach the only logical way?
Edit
I got around this in the end by making all my builds look for "matchExactly" on empty tags, which means my "nightly" tagged agent will never be used for CI.
I believe the default for build definitions says MatchExactly and has an empty Tags Filter field. This means that by default build definitions will only run on Build Agents that have ZERO tags. So the behavior you desire should be the default, when you tag your build agent with the Nightly tag, no builds will run on that agent unless somebody explicitly goes in and changes the default Agent settings for that build def.
I expect that this agent is already running on it's own server, otherwise there'd be no reason to single it out.
You could give this specific build agent it's own build controller, that way chances of a build associated to the "CI" build controller are zero. unless people chose the incorrect Build Controller for their build definition.
This way you also won't have to go about changing the current build definitions.
I have a single code based being used to build an application for multiple platforms.
Locally I have setup a main build-env.properties file, and a series of additional *.properties files that I use to switch settings for the different platforms I am publishing to.
Doing my build on the command line I simply use the command:
ant build -propertyfile dev-build.properties
How can I do this in Jenkins?
I currently use the "Invoke Ant" Build Step with the target set to build, but am at a loss for how to specify the secondary propertyfile?
Although not exactly the same, you can take the contents of those properties and put them into the Jenkins Invoke Ant build step, utilizing the properties advanced field.
The most basic way:
You will need to create a new task for each different set of sub properties you wish to utilize.
In your "Invoke Ant" build step, if you press Advanced..., this reveals a "Properties" field, you can copy the properties from one of your *.properties files into that field.
Repeat for each different properties file you wish to utilize.
Parametrized build plugin might help you. This is assuming the number of properties you are changing is one or two. So when you run a job, you get a drop-down to select you OS and go.
Though, as I have mentioned here , what goes against this plugin is that it makes the process manual
On this thread Hudson / Jenkins: share parameters between several jobs you can read the 2nd option in Anders's answer as an alternate approach.
A better approach for this is using a parameterised job with file parameter(refer to doc for creating the builds). Mentioning the file location as "propertyfile" would help. This would be better than reconfiguring the job again and again to run a build (To copy the properties file to the input location).
I have a Jenkins build that can either be triggered via scheduling, by a user requesting it, or by being called as a build step from other builds. If this build is called as part of another build, it needs to save some information for the larger build to use. I want to pass this information back up by writing to a file. The only problem is having the builds agree on a location to write to.
One approach is to write it to a well known location, but this does not allow several builds to be run in parallel since one will clobber the other.
Another is to add a build parameter to the build that other builds will fill in with a file location to write to. This, to me, seems like a bit of a hack since it means that whenever the build is run, it will need to have a parameter passed in, even if it is just starting with the default value.
The final approach that I considered was having the parent build set an environment variable in the build and having the child check for the existence and content of the variable and act appropriately. Unfortunately, I cannot find a way to set this up in Jenkins.
It seems to me that a combination of archiving artifacts in post build and the Copy Artifact Plugin would do the job.
It sounds like you need the Parameterized Trigger Plugin.
There's too much routine with building next project version using ant. The routine is in several properties files that must be edited before running ant task. I took a look at Jenkins as a system to make builds (including night ones) but I have a problem with changing properties.
Is it possible (if yes, how can I do it) to type parameters in Jenkins configuration before build in order they will be passed to ant?
What I really mean is the following schema (I used in manual builds):
there're 2 properties files that contain data about build version, src destination, emails to notify about new build and so on.
corresponding properties' keys are used in Ant tasks and these properties are changed manually before build.
some properties are read by Java util and used for their own part during build.
there're also 3 or 4 ant XMLs that a imported in build.xml, and these xmls also read properties from mentioned files.
What I want to do is:
change key properties in Jenkins
press build project
my data will overwrite data in properties files OR will be passed as ant vars values straight to the ant's task(s).
as a result I receive new build with corresponding notifications (they're made through ant)
Are there mechanisms that allow one to make such schema work via Jenkins?
Thank you in advance.
In Jenkins, you can use the parameterised build feature to specify those parameters you need to substitute into your build.
For example, if specify a parameter called server and, when clicking "Build Now", you enter test, the build will be executed with an environment variable you can access called ${server}.
Then, in your "Invoke Ant" build step, if you press Advanced..., this reveals a "Properties" field. Here you can enter my.ant.property=${server}.
That's equivalent to calling ant -Dmy.ant.property=${server}, and will be expanded to ant -Dmy.ant.property=test.
Another option : Set environment variables for the scope of the build using this Env plugin. So if the properties you are using are environment variables or can be set as them then you want to use this one. Though it might involve some effort in changing the build scripts, but it can be a good option :
Q : Why would I use this one as I already have parametrized build plugin
A : Because the parametrized build plugin requires human interaction if there is more than 1 choice. For example building for Release 1 or Release 2 or Test branch.
While in the Env plugin, you can set the property once for each choice and then create a respective job for each. Then just schedule the job(s) thereby eliminating the human factor.