SonarQube: Enterprise Edition Version 9.2.4 (build 50792)
Sonar client: 4.7.0.2747
Scan is launched for merge request in gitlab. I am requesting coverage for pull request.
Imidietly after scan (using scanner client) is finished I try to get coverage by following call:
http:///api/measures/component?metricKeys=coverage&component=&pullRequest=
I am getting:
404 : “{“errors”:[{“msg”:“Component \u0027u0027 of pull request \u0027\u0027 not found”}]}”
Interestingly if I put some sleep (1 second) after scan is finished and before i do a call to get coverage everything is fine.
It seems it has to do something with the fact that it’s a new pull request and regardless scan is finished and it generates link with results, it still requires some time before it will be possible for the api call i mentioned to be able to return coverage. Also, if i retry the operation(scan and get results) on already existing pull request there are no issues like this.
Could you please elaborate on this issue, is such behavior is expected or maybe there are some other ways I can get coverage right away after the scan is finished without adding any sleeps…
As a side observation under same circumstances if i do scan on new pull request and call another api (/issues/search?) to get list of detected issues and it successfully works without any additional sleeps,
Thank you.
After the call from the scanner client completes, SonarQube executes a "background task" in the project that finalizes the computations of measures. When the background task is complete, your measures will be available. This is why adding a "sleep" appears to work for you. In reality, it's just luck that you're sleeping long enough. The proper way to do this is to either manually check the status of the background task, or use tools that check for the background task completion under the covers.
If you're using Jenkins pipelines, and you have the "webhook" properly configured in SonarQube to notify completion of the background task, then the "waitForQualityGate" pipeline step does this, first checking to see if the task is already complete, and if not, going into a polling loop waiting for it to complete.
The machinery uses the "report-task.txt" file that should be written by the scanner. This is in the form of a Java properties file, but there's only one property in the file that you care about, which is the "ceTaskId" property. That is the id of the background task. You can then make an api call to "/api/ce/task?id=", which returns a block that tells you whether the background task is complete or not.
Related
I am using karate for automating the things in my project and I am so much exited to say that the way karate gives solutions on API testing. I have a requirement in my project where I need to check the effect on the system when multiple users are performing the same task at the same time(exactly same time including fraction of seconds). I want to identify the issues like deadlock, increased response time, application crashes etc... using this testing. Give me a glint that how can I get concurrent testing solution in karate?
There is something called karate-gatling, please read: https://github.com/intuit/karate/tree/master/karate-gatling
Is there a way to check if Elasticsearch has finished processing my request?
I want to perform integration tests for my application checking if a record can be found after insertion.
For example if I make a following request:
POST /_all/_bulk
{
"update":{
"_id":419,
"_index":"popc",
"_type":"offers"
}
}
{
"doc":{
"id":"419",
"author":"foo bar",
"number":"642-00419"
},
"doc_as_upsert":true
}
And I check immediately, the test fails, because it takes some time for Elasticsearch to complete my request. If I sleep for 1 second before the assertion it works most of the time, but not always. I could extend the sleep time to eg. 3 seconds, but it makes the tests very slow, hence my question.
I have tried using cat pending tasks and pending cluster tasks endpoints, but the responses are always empty.
If any of this is relevant, I'm using Elasticsearch 5.4, Laravel Scout 3.0.5 and tamayo/laravel-scout-elastic 3.0.3
I found this PR: https://github.com/elastic/elasticsearch/pull/17986
You can use refresh: wait_for and Elasticsearch will only respond once your data is available for search.
You can wait for the response; when you receive the response to the update request, it's done (and you won't see it in pending or current tasks). I think the problem you're having is probably with the refresh interval (see dynamic settings). Indexed documents are not available for search right away, and this is the (maximum) amount of time before they will be available. (You can change this setting for what makes sense for your use case, or use this setting to let you know how long you need to sleep before searching for the integration tests.)
If you want to see at in-progress tasks, you can use the tasks api.
Actually, I am creating automation testing for an e-commerce website. Actually, the website have function lazy load or something. I am testing it on UAT server. So, it will load the page slowly because the specification of the server. It takes more than 60 sec or more to load all the resources from the webpage. So, when I am trying to create selenium automation, it always waiting more than 60 sec to continue the next step (because waiting the page fully loaded). Please, someone give me tips how to continue run the test step after 10 seconds wait the page to load. It won't throw an exception, just continue the test step.
Not possible.
If you find some element and try execute some action while loading you will get stale element error + due loading issue you will have a lot of failed tests and it will take a lot more time to debug.
Automation means to execute fast and have reliable results.
It seems that this environment is not built for automation, you should request more resources.
As an alternative maybe you can use a headless driver or see if you can put the same build on a VM.
Why this is an issue: Selenium needs to wait for each request to be complete.For example when you request a page, if the page is not received entirely and the server still sending info then the request is not done, it is logical that you need a complete request in order to continue.
You should address this to your Project Manager/QA Lead and ask for advice/option on how to handle this.
Please note that these costs should be included/added in the automation price.You need to address this in a simple way:
good server -> automation runs smoothly and fast and the testing is
done faster
bad server -> unable to run automation since is not reliable and each
test has a high rate of failure => alternative X day(s) of
manual testing for each build
If this would be a coding issue like some delayed ajax request then you would have some solutions, devs could help, but if is an infrastructure/resources issue then if not depending on you, and you cannot solve it.
You could use try any type of wait implicit/explicit, explicit would throw some exception, but this is not a solution for poor resources.
I have Jenkins project that perform some sort of sanity check on couple of independent documents. Check result is written in JUnit XML format.
When one document test fails, entire build fails. Jenkins can be simply configured to send email to commiter in this situation. But I want to notify commiters only when new test failed or any failed test was fixed with the commit. They are not interested in failed tests for documents they have not edited. Email should contain only information of changes in tests, not full test report. Is it possible to send this kind of notification with any currently available Jenkins plugins? What could be the simplest way to achieve this?
I had the same question today. I wanted to configure Jenkins sending notifications only when new tests fail.
What I did was to install email-ext plugin.
You can find there a special trigger that is called Regression (An email will be sent any time there is a regression. A build is considered to regress whenever it hasmore failures than the previous build.)
Regarding fixed tests, there is Improvement trigger (An email will be sent any time there is an improvement. A build is considered to have improved wheneverit has fewer failures than the previous build.)
I guess that this is what you are looking for.
Hope it helps
There's the email-ext plugin. I don't think it does exactly what you want (e.g. sending only emails to committers who have changed a file that is responsible for a failure). You might be able to work around that/extend the plugin though.
Also have a look at the new Emailer, which talks about new email functionality in core hudson that is based on aforementioned plugin.
I was wondering if there was a way to do this in Hudson (or with any of the various plugins). My IDEAL scenario:
I want to trigger a build based on a job through a REST-like API, and on that build, I want it to return me a job ID. After-wards, I would like to poll this ID to see its status. When it is done, I would like to see the status, and the build number.
Now, since I can't seem to get that working, here is my current solution that I have yet to implement:
When you do a REST call to do a build, its not very REST-ful. It simply returns HTML, and I would have to do a kind of parsing to get the job ID. Alternatively, I can do a REST call for all the history listing all the jobs, and the latest one would be the one I just built. Once I have that, I can poll the console output for the output of the build.
Anyone know a way I can implement my "ideal" solution?
Yes, you can use the Hudson Remote API for this (as #Dan mentioned). Specifically, you need to configure your job to accept Remote Triggers (Job Configuration -> Build Triggers -> Trigger builds remotely) and then you can fire off a build with a simple HTTP GET to the right url.
(You may need to jump through a couple additional hoops if your Hudson requires authentication.)
I'm able to start a Hudson job with wget:
wget --auth-no-challenge --http-user=test --http-password=test "http://localhost:8080/job/My job/build?TOKEN=test"
This returns a bunch of HTML with a build number #20 that you could parse. The build number can then be used to query whether the job is done / successful.
You can examine the Hudson Remote API right from your browser for most of the Hudson web pages that you normally access by appending /api (or /api/xml to see the actual XML output), e.g. http://your-hudson/job/My job/api/.
Update: I see from your question that you probably know much of what I wrote. It is worth exploring the built-in Hudson API documentation a bit. I just discovered this tidbit that might help.
You can get the build number of the latest build (as plain text) from the URL: http://your-hudson/job/My job/lastBuild/buildNumber
Once you have the build number, I think the polling and job status is straightforward once you understand the API.
And what if you don't want the latest build number, but you want the build number of the build that was triggered by hitting the build URL ?
As far as I can tell, hitting that URL returns a 302 that redirects you to the job's mainpage, with no indication whatsoever of what the build number is of the one that you triggered.