I am new to teamcity and need some help in setting up the parameterized build.We are using jenkins to run regression project written in SoapUI and through paramiterized build options we are able to pass parameter(such as test environment,mercurial banch it has to pool the changes from, test suites in case we have executes only selected ones and tags) to the batch script that executes the testrunnner.bat on command line. How can I do the same stuff in teamcity?
I can see teamcity allows three types of parameters env,system and config.Out of which system parameters are passed to the build script.Can I specify all these required parameters as system parameter?
Also I need to supply these parameters for every build but the values may differ.Does teamcity provides facility same as jenkins that would provide a GUI where I can change these values?
Yes, you can use system properties for required parameters that should be passed inside build script.
To specify what mercurial branches to monitor you can configure Feature Branches.
You can run a build manually in TeamCity and customize needed parameters, see how to Trigger Custom Build.
Related
I am using Specflow and firing the nunit-console.exe in TeamCity to run tests as follows:
"C:\Program Files (x86)\NUnit 2.6.4\bin\nunit-console.exe" /labels /include:regression out=TestResultRegression.txt /xml=TestResultRegression.xml /framework=net-4.0 .\MyTests.dll
How can I access the NUnit include tag (/include:regression) so that I can call certain methods or properties for test setup (ex. If include = regression, then run this certain pull these certain test case ids from the app.config file where the key is "regression")
There is no way in NUnit for you to know what runner is running you or how it is doing it. This separation of concerns is by design. You could, of course, access the command line that ran the tests and examine it, but I think that again forces the tests to know too much about their environment.
Best solution is to organize tests hierarchically so that all tests requiring a certain setup are in a namespace or fixture where that type of setup is performed.
I have a TeamCity build which uses msbuildbootstrap to run msbuild. I want to run the same msbuild command on my local machine, but I don't know what parameters TeamCity is passing it. The logs don't say.
[Step 1/3] Starting: D:\BuildAgent\plugins\dotnetPlugin\bin\JetBrains.BuildServer.MsBuildBootstrap.exe /workdir:D:\BuildAgent\work\e8f57dfa2eca8e8c /msbuildPath:C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe
[14:10:12][Step 1/3] in directory: D:\BuildAgent\work\e8f57dfa2eca8e8c
[14:10:14][Step 1/3] depot\Build\Scripts\release.build.teamcity: Build target: PublishRelease (1m:10s)
[14:10:14][depot\Build\Scripts\release.build.teamcity] PublishRelease (1m:10s)
[14:10:14][PublishRelease] CreateCustomBuildLabelTask (1s)
[14:10:15][CreateCustomBuildLabelTask] Creating custom build label from TeamCity build number 7375.
[14:10:15][CreateCustomBuildLabelTask] Generated build label is 2016.02.01.ReleaseCandidate
[14:10:15][PublishRelease] CopyBuildArtifactsTask (5s)
How can I exactly replicate the parameters TeamCity passes to msbuild? Is there any documentation for msbuildbootstrap?
That's a tough question, because TeamCity does not only send a list of properties as an input for the MsBuild command. It creates a list of environment variables that will be taken into account by MsBuild itself as properties.
You can find the defined environment parameters in the "Parameter"s section of your build configuration in TeamCity. They are referenced as "System Properties (system.)".
Once a build has been executed, you can find again the list of system properties in the build result tab named "Parameters" under "System properties".
As a build manager, I don't like this situation, as it can be pretty hard to reproduce a build on a local machine. We use too many system properties today, only specified in TeamCity. I want to shift us to a clear API for executing our builds.
I'd like to write one suite of SpecFlow tests that test my web application (using Selenium) in various environments.
so I have a test written like this
Given that I am on the login page
which in turn leads to a step definition that boils down to
driver.Navigate().GoToUrl("http://www.myapp.com/login.aspx");
However, I want my test to be able to run against "http://localhost" or `"http://test.myapp.com" as well, without having to recompile. The best idea I've come up with is to place these sorts of settings in the App.config file, but that has its problems as well.
Does anyone have suggestions on how best to achieve this? Basically I want to pass in environment settings for my tests at runtime.
You can do this by changing the config file through the build process using transforms and there are tools that will let you run the transform outwith the build process (so you don't have to manually change it and you avoid a build) using the command line. This has been talked about already on SO:
Web.Config transforms outside of Microsoft MSBuild?
For example using PowerShell.
I would still question whether you might be better and starting a local instance of the service that you wish to test, rather than connecting to something which is out of the tests explicit control. You could instead use a method similar to self hosting a web api or host a wcf service to do this for you. This way you can inject mocks, modify and reset the database, or perform any other action you want.
If that still isn't what you need, an alternative to config files would be to setup environment variables that can be read at run time, see How to pass Command line argument to specflow test scenario
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 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).