In Teamcity 9.0.1 I have several builds, which ends up on similar steps, but with different parameters.
In fact, those are servicing steps, not needed by a build to conclude, that build is ok, but they are needed for service, so, currently, they are just running and consuming time.
What I am trying to reach - is move those steps to completely separate build, and invoke it on successful build end trigger. However, I could not figure out - how to pass changes parameters to these newly created build?
Snapshot dependency does not give me level of control I would like to have, as it requires me to define dependency parameters from specific build id, instead of reading them from build, which just ends.
Using artifact dependency by downloading .teamcity/properties/build.finish.gz!** fails with error:
Unknown archive type
and, actually, will oblige me to create additional xml parser
There's nothing built in to trigger builds with custom parameters on a finish-build trigger.
You will have to use the TeamCity REST API / HTTP endpoint to trigger the servicing build with custom parameters - you can pass them as key/value pairs using the following syntax (preferably use HTTPS of course):
http://testuser:testpassword#teamcity.jetbrains.com:8111/httpAuth/action.html?add2Queue=MyBuildConf&name=<full property name1>&value=<value1>&name=<full property name2>&value=<value2>
For further information see the docs.
Implementation-wise you should be able to do what you want in a few lines of powershell as a last step in the triggering build configs - they would have to pass the build parameters you want. If you use this in multiple build configurations I'd move this step into a common template or use a meta-runner.
Related
Normally (when used with Maven), in order to get the number of failed/passed test we can check TestOccurrences element in Teamcity REST API.
What would be the way to report and fetch test stats for non-maven steps (e.g. custom shell script)?
Is it possible to manually set TestOccurrences somehow, so all step types would report stats in the similar way? If not, how can we make custom stats available with Teamcity REST API?
I am creating CI/CD pipelines in VSTS using GIT repository.
I need to use the same steps from UI while creating build definition and release configuration for projects so i want to get off this repeating manual steps and create some automation around it so I don't have to do the same steps every time.
Can anyone tell me how it is possible using scripts or any other things?
To create build definitions you have two options:
Use the new YAML builds, which allows you to specify the whole build in a YAML file instead of UI elements.
Use the Build Definition REST API create the definition locally in json form and submit it to VSTS in a single transaction. There is a nice PowerShell library called "VSTeam" which wraps the REST API functions in powershell cmd-lets.
Another thing to look at would be the use of Task Groups, these allow you to abstract away a sequence of tasks and turn those into a single reusable task.
I have a Build & Deploy Pipeline in Bluemix, I would like to create a condition where, if the build fails, it will automatically assign a defect (i.e., work item in the "Track & Plan" page) to whoever delivered the very latest change (or just assign to the main owner of the App/Project), also, if the build is completed successfully, I would like to tag it.
Tagging is ok, that's general GIT knowledge, I just wanted to solve 2 Problems with that plan:
How do we trigger a specific subsequent Stage in the pipeline if the current build fails/passes?
How do I create a work item from the pipeline? Do I need to create a separate GIT repo and build some sort of API package that allows me to invoke a mechanism that creates the ticket?
I guess I'm going too maverick with this Pipeline, please share your thoughts.
As of right now you can not create a work item from the pipeline. That is a great feature improvement and I can take it back to the team.
For your question about triggering a stage if something passes or fails... The way it works now only the next stage will be triggered if the previous is successful. The pipeline is based on Jenkins and Jenkins doesn't allow you to trigger a specific job if a job passes or fails. You would want to detect the pass or fail in your stage and do your logic based on that.
I want to get the build parameters of a running build, how can i do that via rest?
I know the following link gets me the current running builds
but how can i get the build parameters for them?
> http://teamcityserver/httpAuth/app/rest/builds?locator=running:true
Once you have the list of running builds you will need to make a call to the URL shown below for each build supplying the relevant ID.
http://teamcityserver/httpAuth/app/rest/builds/id:<BuildIdGoesHere>
This will retrieve the details of the build including the build parameters which you will find in the <properties> node.
I don't want Build Config A and Build Config B to run at the same time. This is because they share the same resource which cannot be accessed simultaneously. However each build config is run by a separate agent so it is possible for them to run simultaneously.
Instead I would like one build config, when triggered, to wait for the other to finish if it is running. For example if Build Config B begins to run but Build Config A is already running, then B would wait until A finishes and then B would run.
I don't think a snapshot dependency will work because that assumes one config has a dependency on the other which is not true in my case.
Keith, there are two plugins that can help you:
The first one is Groovy plugin. It has functionality of creating name locks over all projects.
The second one is TeamCity.SharedResources. It has functionality of definig shared resources and locking them with read and write locks. However, resources defined in this plugin, are are defined per-project. We are actively developing this plugin, so you are welcome to watch its page in our tracker
For a quick and dirty, just make a rule on the compatible agents tab for the project. That they have to run on the agent name containing xxx ( whatever that is ) then those builds can only run on that agent and will never run at the same time.
In the newest version of TeamCity, you can configure this parameter. Go to the Edit Configuration Settings -> Edit Configuration Settings and set parametr:
Limit the number of simultaneously running builds (0 — unlimited)