Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SonarQube quality gate always report from default project branch #1016

Closed
gerardcl opened this issue Jul 7, 2023 · 3 comments · Fixed by #1018
Closed

SonarQube quality gate always report from default project branch #1016

gerardcl opened this issue Jul 7, 2023 · 3 comments · Fixed by #1018
Assignees
Labels
bug Something isn't working

Comments

@gerardcl
Copy link
Member

gerardcl commented Jul 7, 2023

Describe the bug
We have detected when enabling the enforcement of quality gate for sonarqube that it always gets, from whatever branch you are scanning, the default branch (usually master).

To Reproduce
Steps to reproduce the behavior:

  1. Create a branch on your repo and enable the quality gate
  2. Check the report is returning the info from default branch, not the one in scope
  3. Pipeline might fail or not as false info is back

Expected behavior
To get the quality gate info from the right branch in scope of that pipeline.

Screenshots
N/A

Affected version (please complete the following information):

  • OpenShift: all
  • OpenDevStack all

Log Output (ensure to remove any confidential information like tokens, project names, etc.
API call does not use the branch query parameter:

script: "curl -s -u ${authToken}: ${hostUrl}/api/qualitygates/project_status?projectKey=${projectKey}",

Additional context
Must be fixed

@gerardcl gerardcl added the bug Something isn't working label Jul 7, 2023
@braisvq1996 braisvq1996 added this to To Do in ODS Maintenance via automation Jul 7, 2023
@gerardcl gerardcl self-assigned this Jul 7, 2023
@michaelsauter
Copy link
Member

Haha, just noticed the same issue a few weeks back: https://github.com/opendevstack/ods-pipeline/pull/704/files#diff-819a83bd48fb2fe12110e0b2b9b1ccd1c927fc30fa7fd8f14a983aefbf36f6c2

@gerardcl
Copy link
Member Author

Ok @braisvq1996 we found out that the & parameter in the URL was a problem so we need to provide a fix by using the full cURL CLI with flags for url encodings.
I would recommend to go full on flags anywhere we use cURL CLI in the lib.

@braisvq1996
Copy link
Contributor

closed by #1020

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
3 participants