Is it possible to grab the build number from TeamCity and use that as a build number in BuildMaster?
This could be done by triggering the BuildMaster API's Builds_CreateBuild method from TeamCity which accepts a numeric build number. It should be fairly straightforward to make a GET request to the BuildMaster JSON API from TeamCity, see this question for a simple way to do so: TeamCity Call Url Build Step
In order to create a new build including the build number you need to firstly enable the api under settings. There is no 'enable' button as such, you just need to provide an arbitrary key for the api authentication (any literal will do, but presumably make it complex for best security!).
The JSON syntax for the creating a build is as follows:
http://buildmaster-server/api/json/Builds_CreateBuild?API_Key=abcde12345&Build_Number=123&Release_Number=0.0
This will actually create a new build on your build master server. This can then be triggered via Team City using Powershell with the powershell script inline such as:
Invoke-WebRequest "http://buildmaster-server/api/json/Builds_CreateBuild?API_Key=abcde12345&Build_Number=%build.number%&Release_Number=0.0&Application_Id=2" -UseBasicParsing
You can add further variables and call hundreds of BuildMaster API's using the above method. Full API documentation can be found here: http://inedo.com/support/documentation/buildmaster/reference/api-methods
Related
Postman collection and it's folder arrangement
I want to run this ITEM-API postman collection in jenkins. I have exported it with github repo. I have also done configuration. But here when will I run test, it will give result for all ITEM-API collection. But inside ITEM-API collection, there are different folders of API, for eg. CHARTS, IAMGES, SYNDICATION, INTEREST, etc. SO how can use newman command to run test for particular api. Let's say, I want to run test for CHARTS api, then how can I use newman command for that in jenkins or groovy file in github repo.
please please help.
I'm using SonarQube 8.1 (Developer Edition) and Jenkins to analyse Maven projects which source code is hosted on Bitbucket.
I'm using the "Pull Request Decoration" functionality and it's working well. However, to configure this functionality, I had to set these parameters manually (through the GUI, in project page : Administration > General Settings > Pull Request Decoration) :
Configuration name
Project key
Repository SLUG
Is it possible to set these parameters through command line (e.g in mvn command, I'd expect something like mvn clean -Psonar $SONAR_MAVEN_GOAL -Dsonar.pullrequest.decoration.configurationname=<my-conf-name> -Dsonar.pullrequest.decoration.projectkey=<my-project-key> -Dsonar.pullrequest.decoration.repositoryslug=<my-repository-slug>) or throught REST API ?
Get an answer here : https://community.sonarsource.com/t/sonarqube-configure-pull-request-decoration-with-parameters/18999
No, this is not possible to define this from the scanner. Thoses are
project-level parameters, they won’t change from one analysis to the
next one, so better not pollute your scanner with static parameters.
You can indeed define them with the rest API. Have a look at the
api/alm_settings/set_bitbucket_binding entry in your web api
documentation!
The Docs show this
/repository/downloadAll/BUILD_TYPE_ID/BUILD_SPECIFICATION
for getting all of your artifacts as a zip file, but that isn't using the REST API. Is there a way in the REST API do do the same thing? The Docs seem to indicate that the repository links are only there for backwards compatibility.
You can use this URL, it works for me:
http://<TeamcityUrl>/httpAuth/app/rest/builds/id:<BuildId>/artifacts/archived
I use TeamCity 9.
From the documentation: http://confluence.jetbrains.net/display/TW/REST+API+Plugin#RESTAPIPlugin-buildartifacts
Artifacts:
GET <TeamcityUrl>/httpAuth/app/rest/builds/<buildLocator>/artifacts/files/<artifact relative name>
If you download the artifacts from within a TeamCity build, consider using teamcity.auth.userId/teamcity.auth.password system properties as credentials for the download artifacts request: this way TeamCity will have a way to record that one build used artifacts of another and will display that on build's Dependencies tab.
have you tried this?
I'm not sure it's documented, but it works.
http://teamcity-url/downloadArtifacts.html?buildId=216886
If you are using it from .NET you may use the following code:
List<string> downloadedFiles = new RemoteTc()
.Connect(a => a.ToHost("tc").AsGuest())
.DownloadArtifacts(123, #"C:\DownloadedArtifacts");
The above code uses FluentTc library
A continuation on the answer to this question:
Is it possible to add a free text note to a team city build?
In TeamCity custom build dialog there is a field for "Build comments".
Is there a way to access this from within the build?
Either as a system property or environment variable?
As far as I know, the Build Comments are not exposed or accessible from your build script, however you can create custom build parameters that are accessible. You can create system properties or environment variables, either of which can be accessed in your build script. See the TeamCity docs on custom parameters for full details.
Maybe this question is outdated, but I'll answer just in case somebody else is interested.
Comments can be retrieved using TeamCity REST API:
http://teamcity.codebetter.com/guestAuth/app/rest/changes?locator=build:id:216886&fields=change(id,version,href,username,date,webUrl,comment)
If you need it from C# project, you may consider using FluentTc library:
IBuild build = new RemoteTc()
.Connect(_ => _.ToHost("teamcity.codebetter.com").AsGuest())
.GetLastBuild(
having => having.Id(216886),
with => with.IncludeChanges(and => and.IncludeComment()));
One way of achieving it is as follows:
http://[host]:[port]/httpAuth/app/rest/builds/id:<internal build id>
This will return xml with build Parameters, comments will be one of child nodes.
I'm looking for a way to attach some specific build parameter to a scheduled trigger.
The idea is that we are continuously building debug versions of our products. Our nightly build has to be a release build, though. The build configurations for most of our projects is absolutely the same. It even has a configuration parameter, already. So all I would need is a trigger which allows for specifying an override for a single build parameter. That would cut the build configurations to maintain by half.
Is there a way to achieve this?
Not right now, you can follow this issue.
The approach I use is to create a "Deploy :: Dev D1 :: Run all integration tests" build. I then create a build trigger on each integration service build.
I create a parameter called "env:OctopusEnvironment" for integration service build. Set the value to be empty. I like to use prompt and display:
select display='prompt' label='OctopusEnvironment' data_13='Production' data_12='CI' data_11='Local - Hassan' data_10='Local - Mustafa' description='OctopusEnvironment' data_02='Test T1' data_01='Dev D1' data_04='Local - Taliesin' data_03='Continuous Deployment CI 1' data_06='Local - Paulius' data_05='Local - Ravi' data_08='Local - Venkata' data_07='Local - Marko' data_09='Local - Ivan'
In each integration service build I add this powershell step:
$octopusEnvironment = ($env:OctopusEnvironment).Trim()
Write-Host "Octopus environment = '$octopusEnvironment'"
if ($octopusEnvironment.Length -lt 1) {
Write-Host "Auto detecting octopus environment"
$trigger = '%teamcity.build.triggeredBy%' -split '::'
if ($trigger.Length -gt 2){
$environment = $trigger[1].Trim()
Write-Host "##teamcity[setParameter name='env.OctopusEnvironment' value='$environment']"
}
}
So now I can run the integration test via a trigger and when I run it directly it will prompt me on which environment to run integration test against.
I was stuck with the same problem and voted for the issue mentioned by Evgeny. One solution we thought, as mentioned sergiussergius, was to add a final step in the build-steps sequence to trigger manually the next build-configuration by passing custom-build parameters using the REST API. But in this case, we are loosing the build-chain information.
Using TeamCity 9.x, trying some stuff on the REST API, I could implement a solution who makes it possible to retrieve the triggering (ancestor) build and its parameters from the triggered (child) build.
The first thing we do is getting the current build using the environment variables set by TeamCity:
https://<host>/httpAuth/app/rest/builds/number:<env.BUILD_NUMBER>,buildType:(name:<env.TEAMCITY_BUILDCONF_NAME>,project:<env.TEAMCITY_PROJECT_NAME>)
In the response from the REST API, we have a /build/triggered tag which contains information about the trigger. It looks like this
<triggered type="unknown" details="##triggeredByBuildType='<triggering-build-configuration-internalId>' triggeredByBuild='<triggering-build-number>'" date="20160105T190642+0700"/>
The looks like btxxx for us.
From it, we can access the triggering-build (ancestor) using the following request to the REST API:
https://<host>/httpAuth/app/rest/builds/number:<triggering-build-number>'4,buildType:(internalId:<triggering-build-configuration-internalId>1,project:name:<env.TEAMCITY_PROJECT_NAME>)
from the response, we can get the ancestor-build's parameters values, and set it in the current build using:
echo "##teamcity[setParameter name='env.ENV_AAA' value='aaaaaaaaaa']")
Notes:
this post reference TeamCity version 7.X. I did this using TeamCity version 9.X, and could not try it with a previous version. I don't know if the REST API calls mentioned in my post are similar in the previous versions.
In this solution, the ancestor's build-configuration (the one who trigger the build) and the child's build-configuration (the one triggered) are in the same project. I did not do the test using build-configurations in 2 different projects: I would expect the "trigger" tag to provide information about the ancestor's project. It would be nice if someone could do the test.
I hope this solution may help!
This is not a general solution, but in certain cases (for example if you want to determine whether the build was started by a schedule trigger or some other method), a workaround is to examine the predefined parameter teamcity.build.triggeredBy.
This parameter is set to the same string that is shown on the build's overview page next to the label "Triggered by:". For example, "Schedule Trigger", "Git", or a user's full name. (There is also a teamcity.build.triggeredBy.username parameter, but it is only set in the latter case).
The limitation of this approach is that you cannot, for example, distinguish between two separate schedule triggers defined for the same build configuration. But in that case you could resort to examining the current time as well.
I added request to last build step
curl -i -u "%login%:%pass%" -H "Content-type: text/plain" -X PUT -d "v1" http://tc.server/httpAuth/app/rest/buildTypes/id:%buildConfigurationId%/parameters/env.%SOME_PARAMETER%
http://confluence.jetbrains.com/display/TCD8/REST+API