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!
Related
I would like to search for a project's line coverage using the SonarQube Web API.
The entrypoint to my search is the github repository uri.
So something like this: git#github.com:user/my-project.git.
Currently, I am cutting out the repo name and try to find the project using /api/projects/index?search=my-project - assuming that the github repo name should be contained in the sonarqube project name.
I pick up the project key from the response and use it with /api/measures/component to retrieve the overall_line_coverage.
We are using the SonarQube gradle plugin to create the SonarQube project. We also set the sonar.branch property. So we end up with project keys like <groupId>:<artifactId>:<sonar.branch>.
Is there a better/more robust way to do this search - especially I would like to add the sonar.branch to the query the narrow down the search result.
go to your project homepage to get the project key OR use the internal (made public in 6.3) WS api/components/search with the q parameter
use the WS api/measures/component to retrieve your project measure
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
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
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
I am using the hudson "Publish artifacts to FTP" task after a build to put an installer up to a web site.
I would like to automatically add that link to my email.
unfortunately hudson makes up a directory name based on time and date and places the tile there.
Is there a way to get that value and put it in the build success email or otherwise automatically create the full url?
Hopefully you are using the "Hudson Email Extension" Plugin. This gives you many more customization options over the email support built into the core.
If you are, you might consider putting the token:
${ENV, var} - Displays an environment variable
...into the email. You could set an environment variable in your build script to the FTP link and then insert it into the email. I'm sorry I don't use the Publish Artifacts to FTP plugin myself, but you should be able to mimic the way that plugin sets the FTP destination, and then stick it into an environment variable, which the Email Extension Plugin can then use.