Teamcity Rest Api PATCHED Download Build Log
John Cortez
I found out that even though you did not get any information about the custom build properties using the "/builds/?locator=buildType:x" call, you could extract the build ID for each one of the builds in that list and then do another REST call to get more details about one specific build. The rest call looks like this:
If you send a request to /app/rest/agents/$help, or /app/rest/agents/aaa:bbb (supplying unsupported locator dimension), you will get the list of the supported dimensions to find an agent via the agent's locator.
Most of the attributes of the returned agent data (name, connected, authorized) can be used as the in the app/rest/agents// request. Moreover, if you issue a request to the app/rest/agents/id:10/test URL, you will get a list of the supported fields in the error message.
? is the REST API part of the URL.
A typical way to get multiple items is to use in the form of .../app/rest/ (for example, .../app/rest/builds). These URLs regularly accept the locator parameter which can filter the items returned. Individual items can regularly be addressed by a URL in the form of .../app/rest//. This URL always returns a single item. If the locator matches several items, the first one is returned. Both multiple and single items requests regularly support the fields parameter.
POST: creates the entity from the payload submitted. To create a new entity, one regularly needs to post a single entity data (i.e. as retrieved via GET) to the .../app/rest/entities URL. When posting XML, be sure to specify the Content-Type: application/xml HTTP header.
Use the /app/rest/latest URL for the requests. Do not use /app/rest, do not use the httpAuth prefix. If that does not help, enable debug logging and look for related messages. If there are none, capture the browser traffic and messages to investigate the case.
Do not abuse the ability to execute automated requests for TeamCity API: do not query the API too frequently and restrict the data requested to only that necessary (using due locators and specifying necessary fields). Check the server behavior under load from your requests. Make sure not to repeat the request frequently if it takes time to process the request.
POST: creates the entity from the submitted payload. To create a new entity, one regularly needs to post a single entity data (that is as retrieved via GET) to the .../app/rest/entities URL. When posting XML, be sure to specify the Content-Type: application/xml HTTP header.
But now I want to see only the test info from this build, so my first step would be to check for all fields to see what I needed like so:
GET :8111/app/rest/builds?locator=id:308&fields=build($long)
From the response I was able to manually refine down the fields I needed and adjusted the URL:
:8111/app/rest/builds?locator=id:308&fields=build(testOccurrences(count,passed,ignored)) and this response would look like this:
Presenting a selection of useful requests - not every single one, and please note for readability purposes (and less page noise) I've reduced some of the responses but tried including the 'main' bits if that makes sense! The following examples assumes the base URL is :8111/app/rest for simplicity.
Teamcity does not provide automatic agent authorization other than UI but if you are using same server/host names you can try by backing-up and restoring of agent.properties file as specified by Marcel. this file will have the authorization key of the agent
I am not aware of anyone that has done this previously, but you could try to pass the following TC build parameter teamcity.build.changedFiles.file (bottom of this page +Build+Parameters) to the Octopus Team City plugin using the --releasenotesfile parameter in the Additional command line arguments field (Please Note: that the Octopus server would have to have access to the location of the changed files file though, so some fiddling to either get the file to a location that is available to the Octopus server or if the contents of the file could be read into a string variable that could then be passed to the Octopus TeamCity plugin using the --releasenotes parameter).
Use case:I am creating build configurations from a template and need each build configuration to only run on a single, specific machine. I wanted to do teamcity.agent.name equals %buildAgentName% in the template to have TeamCity prompt me to fill in the parameter when I create the build configuration from template.
Solution:Instead of using a parameter I just put in a string that would not match any agent names, e.g. teamcity.agent.name equals replaceThisWithActualAgentName in the template. I am not prompted for the parameter but this prevents the build configuration from accidentally running on the wrong machine until I override the agent requirement.
TeamCity provides a REST API for integrating external applications. The available endpoints are documented here. One of these endpoints allows the creation of a user authentication token via the route /app/rest/users//tokens. Since this endpoint route ends with the static suffix "/tokens", it cannot be used to bypass the authentication.
Another sensitive aspect from a security point of view is the usage of wildcard expressions. These are used in scenarios where a static value is not sufficient to represent all acceptable inputs. The downside of this is that an expression chosen too unrestrictively allows more than actually intended. In this case, the "/**/RPC2" wildcard was never supposed to also include the REST API endpoints. To prevent these kinds of issues a generally good approach is to be as restrictive as possible.
Took more than expected to figure out this : some examples would be helpful. Note that the build needs to be finished to be able to pin it/tag it so we have to put this ugly sleep to postpone operations on the rest api when the build is finished.
This powershell-based meta runner has a very interesting feature. All parameters of this runner are passed as a string parameters to powershell cmdlet, hence the string interpolation should work. Simply speaking, any powershell expression wrapped in $() should be evaluated. Somebody can say that this can be used to Powershell Injection attacks but I think this is not the case as long as you control the environment. For me this is a really nice point of extensions which gives me a lot of possibilities. For example, if we want content of given file embedded in our message, we can achieve this by adding the following code in our message field:
I am trying to use self-hosted agent in Azure DevOps to run Postman tests. Due some restrictions to use extra tools, I am using command prompt to install and run newman under Microsoft Windows server based private agent.
To collect OpenMetrics-compliant histogram and summary metrics (available starting in TeamCity Server 2022.10+), add the internal property, teamcity.metrics.followOpenMetricsSpec=true. See, TeamCity Internal Properties.
Uncomment the following configuration block in your teamcity.d/conf.yaml file. Change the path parameter value based on your environment. See the sample teamcity.d/conf.yaml for all available configuration options.
teamcity.build.status
Returns CRITICAL if the finished build has a status of FAILURE. Returns OK otherwise. Only emitted by the TeamCity REST instance.
Statuses: ok, critical
teamcity.build.problems
Returns WARNING if the finished build has encountered a problem. Returns OK otherwise. Only emitted by the TeamCity REST instance.
Statuses: ok, warning
teamcity.test.results
Returns CRITICAL if the finished build test has encountered a problem, WARNING if it has encountered a warning, or UNKNOWN if it has encountered an unknown problem. Returns OK otherwise. Only emitted by the TeamCity REST instance.
Statuses: ok, warning, critical, unknown
TeamCity is extremely powerful. It exposes a REST API that allows you to obtain all the data about your builds. The exposure of artifacts is really interesting and you can actually host a website from your project artifacts if you want!
Five weeks ago our CI/CD infrastructure stopped working. The Team City server for building our BizTalk solutions was deleted and the backups could not be restored. Now it gets worse, the Team city configurations were not saved anywhere either. It was a perfect storm for two other reasons. Firstly Alastair who had set up our build and deploy process had left that week. Secondly I became very ill and had an emergency operation. Returning to work after a week on sick leave i was all at sea because I was so reliant on on this to do any BizTalk development. The take home point is never rely on any DR plan unless it has been tested.
After deciding to pursue GitHub Actions, it was time to evangelize it to the rest of the engineering team. With the help of many adventurous colleagues, several projects showcased GitHub Actions as a CI solution. We also demonstrated how to handle secrets in CI to get the support of our security team. The portfolio of success stories provided the evidence needed to get organizational buy-in to make the transition from TeamCity to GitHub Actions. It was time to write up a migration strategy and design a new CI pipeline, or as it will now be called, a Workflow, using GitHub Actions.
df19127ead