This part run with no problem, and the value of CI_MERGE_REQUEST_IID is correct according to the Merge Request that is created. Once this script run, it will trigger the webhook in the SonarQube and it will send the result to the Gitlab MR page as comment, which is also a success.
The problem Im having right now is that, why is the value of CI_MERGE_REQUEST_IID is -1 from its value? For instance if the MR ID when sonar-scanner command is running is 33, the webhook will pass 32 instead of 33.
One more thing to note, the SonarQube webhook received by the GCP Cloud Run, and the GCP Cloud Run will write to the Gitlab’s MR comment. It’s designed this way because our Gitlab instance is behind firewall.
What project name is created? I would expect it to also be 32 instead of 33. Nothing on the Sonar side is doing that interpolation. SonarQube is just using what was passed in.
Yes, the project name is correct as I passed from Gitlab, as you can see the project that i pass from gitlab ci is formatted as api:4508:35(project_name:project_id:mr_id), where 35 is the correct MR id.
Are you sure that your two screenshots go together? Where does the URL in the payload take you? Is it to project 35 or 34?
I believe you can check the webhook payload that was sent via the UI. Can you double-check api:4508:35’s first webhook payload to verify the project:name in it?
Because by the time webhooks are processed, the analysis context has been discarded, I believe, and SonarQube is reading from the project itself to assemble these values.
Yes, the 2 screenshots go together as I only have 1 gitlab ci pipeline for testing at the moment. Just to be clear the number 34/35 will change based on which MR ID provided in the gitlab ci.
After doing some digging on the interweb, i’ve found that i can use the sonar.analysis.[key]=[value] parameters where I can send out custom parameter to the Cloud Run, which produce more consistent output.
