In the SonarQube docs it says that componentKeys can be the following:
Comma-separated list of component keys. Retrieve issues associated to a specific list of components (and all its descendants). A component can be a portfolio, project, module, directory or file.
I want to get all the issues from components of a specific directory. I have tried to use the * wildcard like this:
http://localhost:9000/api/issues/search?componentKeys=projectkey:src/testcases/*
or
http://localhost:9000/api/issues/search?componentKeys=src/testcases/*
This doesn't seem to work, how can you search issues by a directory?
You can pass your projectKey name as ComponentKeys and pull all the issues from the project.
http://localhost:9000/api/issues/search?componentKeys=testproject
Related
I am using gradle 6.8 and MarkLogic version is 10.0-5.2,
My XQuery code is in directory \ml-gradle\src\main\common. When I run the command mlLoadModules to load XQuery into the modules database it loads with default URI /common/test.xqy.
I want to add some prefix to the URIs e.g. /rsc/common/test.xqy. How can I achieve that?
Note: I don't want to create an extra folder in my source for prefix "rsc".
It's not supported, though you could write a custom Gradle task to change the URI to whatever you like.
Why do you not want to create an "rsc" folder above "common"? I think other developers would find it much more intuitive that "rsc/common/test.xqy" becomes "/rsc/common/test.xqy" when loaded, rather than "common/test.xqy" becomes "rsc/common/test.xqy", which begs the question - where is "rsc" coming from? And then that developer would need to understand what property / custom code is adding that "rsc".
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
I am looking at using Swashbuckle/Swagger to document my WebAPI solution. The developer portal would be something like https://myapi.com/, while the versioned API is https://myapi.com/v1/users.
The version part of the URL maps to a virtual directory, containing the binaries and config files for v1. When version 2 ships, we create a new virtual directory under the root, so now we have https://myapi.com/v2/users/some_new_endpoint_not_in_v1. This means that save for bugfixes, there is no need for any of the binaries of older versions to be touched, which reduces the likelihood of some developer accidentally breaking backwards compatibility for our customers.
However, I can't see how to configure Swashbuckle to look at those virtual directories to get the controllers/actions and XML comments to parse. The MultipleApiVersions configuration option seems more targetted at people who throw all their supported versions into one set of binaries (either by namespaces or controller names), and not by separating them into separate processes.
Any suggestions as to how I can bend Swashbuckle to my will? Should I just install Swashbuckle into the individual virtual directories as single API versions, so the docs becomes something like https://myapi.com/v1/swagger? My portal would then do the necessary work to expose the different API versions.
Update
I did try the latter approach, and for the documentation at least, it works OK. The problem is then that the URL for the Swagger spec then becomes https://myapi.com/v1/swagger/docs/v1, and I would rather not have that second v1 in the URL. Unfortunately Swaashbuckle at least expects the version number to be in the relative path, not in the base URL.
Having those would work:
Swagger UI at the root of your API site (nothing to do with Swashbuckle),
multiple virtual directories for your versions ("v1", "v2"...)
To achieve this:
the custom discoveryPaths array in Swagger UI javascript would look like below, with added "/spec" suffix (or whatever suits you, as SwashBuckle is not handling the c.SingleApiVersion with an empty version value):
var currentUrl = 'https://myapi.com/';
window.swashbuckleConfig = {
rootUrl: currentUrl,
discoveryPaths: arrayFrom('v1/swagger/docs/spec|v2/swagger/docs/spec'),
booleanValues: arrayFrom('true|false'),
validatorUrl: stringOrNullFrom('null'),
// other settings ommitted for brevity.
oAuth2AdditionalQueryStringParams: JSON.parse('{}')
};
Removing c.EnableSwaggerUi from your Web API sub apps
Is there a way to see TeamCity configurations that override parameter defined in template?
I don't think so. What's worked for me in the past was to search through the project files on the filesystem. If you have many build configs, this will be faster than opening each of them in the GUI.
Search for something like this:
<param name="myParamInheritedFromTemplate" value="myOverrideValue" />
in <TeamCity data directory>/config/projects/**/*.xml. If it's absent in an XML file, that build config just inherits the value. If it's present, it overrides it.
It's hacky but it's quick.
There is a feature request https://youtrack.jetbrains.com/issue/TW-21212, please vote. Current workaround are to either search the raw XML files with the settings stored under TeamCity Data Directory on the server as #sferencik suggested, or use REST API to get settings of all the build configurations and search for the parameter there. Let me know if you need help on any of these.
I am using TeamCity's REST api to get the list of changed files for a specific change.
I do it like this:
http://teamcityserver:8111/httpAuth/app/rest/changes/id:
In the result, I am getting a bunch of "file" xml nodes. However, for each file, I would like to know the action done on it (was this file added? removed? edited?) and this information is not present in the file nodes.
Is there a way I can get this information from the api?
(I am using TeamCity 9, if that's relevant)
I just got a response from TeamCity support saying that it's not possible:
"Unfortunately it is not possible to get the file action via REST API".