Access to old documentation for 9.2.x regarding scan success return values

SonarQube
1

We are currently running enterprise version 9.2 and have a ticket to upgrade to 9.9 LTS. In the meantime, we have CI/CD pipelines that incorporate SonarQube scanning.

I found a bug in our pipelines (not Sonar’s, ours) where we’re requesting and parsing the result of SonarQube’s scans, namely that the code “passed” or “failed”. As part of our quality assurance, we need to provide a link to something that says those two are the only values returned by SonarQube and there are no other potential values that we need to account for, such as “error”.

Bonus points if said documents imply whether the return values are case sensitive.

Is there…

  1. a link to the quality gates page of the 9.2 documentation or…

  2. is someone willing to state for the record that “passed” and “failed” are the only return values? In other words, SonarQube did not retain “error” in 9.2 only to remove it from later versions such that it doesn’t show up in 9.9’s docs?

For us, the ideal scenario is knowing that nothing will change in this regard when we do upgrade from 9.2 to 9.9.

UPDATE:

After doing more research and testing of our pipeline, we realized that what we’re really looking for is a list of all the possible values that the SonarQube jenkins extension returns as the result of a waitForQualityGate() call. See Jenkins extension for SonarQube.

Specifically, if the code itself failed a scan, does qq.status result in ‘OK’ or does it result in ‘FAILED’?

2

Hi,

Welcome to the community!

Thanks for this clarity. The intent is appreciated. :sweat_smile:

In 9.2 you have embedded documentation in your instance. To be clear, it’s a subset since once the instance is up and running to serve those docs, you no longer need all the docs on getting the instance up and running. But anything relevant to your question will be in there.

Ehm… no. You could always get an error back from invalid parameters, E.G.:

{
  "errors": [
    {
      "msg": "Either 'analysisId', 'projectId' or 'projectKey' must be provided"
    }
  ]
}

Further the docs for that call (this links to our public instance, but you can get the same docs on your own instance) are explicit that:

The different statuses returned are: OK, WARN, ERROR, NONE.

Ehm… I’m not sure. I’m also not sure there’s a distinction to be made. waitFroQualityGate can timeout - not sure what the return value would be there: -1? Otherwise it would be success/failure, or based on the web service I suppose OK OR ERROR (which is a failing QG).

 
HTH,
Ann

3

Thank you Ann. I’m still confused but I think I’m now a lot closer to the truth.

Would it be fair to say that references to quality gate status values of “passed” and “failed” as described in these documents are merely for the web based report UI and are not at all relevant when asking a Jenkins pipeline to process the result of a scan via API?

I admit to being a little anal retentive because we thought SonarQube decided to settle the age old question of whether a report with conditions that are either OK or WARNING (but not ERROR), collectively are considered a passing score or a failing score, by ultimately dropping that category.

Is there anything to suggest how projectStatus.status is calculated from the conditions? I’m hoping it’s something as simple as…

  • status is ERROR if at least one condition is ERROR
  • status is WARN if at least one condition is WARN and there are no conditions are ERROR
  • status is OK if there is at least one condition, there are no WARN conditions and no ERROR conditions
  • and status is NONE if there are no conditions to process at all?
4

Hi,

Ehm…

I’ll be honest & say I wasn’t really focused on that when I copy/pasted what the API docs say. I think it’s probably an error that WARN is still included in the list. We did indeed drop the warning status on Quality Gates.

Correct

N/A. I’m going to bring it up internally that those docs still include WARN as a possible status

I honestly don’t know how it would be possible to get a NONE status since every new instance has a default Quality Gate that - like default Quality Profiles - will be applied automatically to every project that hasn’t explicitly selected another Quality Gate. I suspect that this is vestigial and/or an unneeded default that should probably also be purged from the docs.

So, you should expect to see ERROR and OK, and I would probably code it as

if OK{
  // handle success
} else {
  // handle fail
}

 
HTH,
Ann

P.S. After some internal discussion, I’ve learned that NONE is returned when the project hasn’t been analyzed yet. Which probably isn’t relevant in a Jenkins pipelines context, but the API docs wording still needs an update (which I’m pursing).

5

Thank you again. :smile:

I summarized all this for our team - and our QA rep in particular - and we’re satisfied we can proceed with the if OK else paradigm, secure in the knowledge we’ve accounted for every case.

1 Like