The two keys are two different components, but the api/alm_integrations/search_gitlab_repos is listing the old (incorrect one).
After some more resource, I found out that there were in fact two components that had the same GitLab project id and the older one was the one showing up in search_gitlab_repos instead of the current one.
I consider this a bug. The API should show the information for the current GitLab projects.
Any updates? I had a meeting with PO Python ecosystem who said that there was something going on behind the scenes (from what she could see), but nothing has been communicated here.
It’s a blocker for us since you, as expected, don’t get the accurate (i.e. up-to-date) information.
Does this mean that the old one no longer exists? In the result, do you see just one component? Also, can you maybe share the full request/response? I can open personal messages for that.
But, components exists in JFrog for the particular GitLab project id. But, in GitLab one no longer exists as the group id and artifact id in pom.xml has changed.
I’m not sure if I can reproduce since I had to remove the old component in order to be able to continue.
To reproduce this should work,
create a minimal maven project, artifact id = artifact_org
Create the project in SonarQube (GitLab linked)
Run sonarscanner, confirm that there is data for the project in SonarQube
Change the artifact id (artifact_new) in pom.xml
Run sonarscanner
Now use the API (api/alm_integrations/search_gitlab_repos) and check which component the API returns. In our case it was artifact_org and not artifact_new.
I think I finally understand what might be the problem here, it’s sonar.projectKey, which isn’t explicitly specified. Your project key is a unique identifier for your project. If you are using Maven, ensure the key matches the “groupId:artifactId” format as it’s a default value for projectKey. When artifactId was changed, it created new SQ project, which isn’t bound to gitlab and won’t appear in api/alm_integrations/search_gitlab_repos results.
Please, let me know whether it makes sense.
As I explained to your colleague, we have created a system to auto-detect sonar key and token without the use of sonar-project.properties.
I could be wrong here, but I don’t think that you are right
The new project is bound to GitLab because it shows if I delete the original component.
The bug here is that there are two components that have a link to the same GitLab project and, for the given endpoint, SonarQube returns the original (non-current) one.
From the SQ side, we can’t be sure what the current project is for you. I’d suggest having one project under one Gitlab id and you can achieve it either by deleting the incorrect one or by unbinding it (Project Settings → DevOps Platform Integration).
I understand that you can’t be sure which is the current/correct project for the user, but your current “solution” is quite bad. Options are:
as a user it is not obvious that GitLab ID are reused by SonarQube
you are currently returning something whereas there are other BETTER options such as:
a. return the id for the last seen, seen as in last one that you received data for (makes a lot more sense than for the oldest one)
b. return all SonarQube projects linked to a GitLab project id (leave it to the user to decide which one is correct)
c. raise an error message
I think you’ll need to be logged out of the Atlassian cloud in order to view the ticket since you don’t belong to our Jira. I just opened the ticket in incognito mode so it’s definitely accessible to the public.
It’s not possible to track/watch the ticket without being a member of our Jira… and only we can be members of our Jira (licenses )
It might be an issue we can tackle before the upcoming LTA, but I can’t share any guarantee.
I understand the limitations on this one endpoint are frustrating for your automation, but the core functionality of SonarQube is still intact. This is something you’ll have to work around for now.
Ok. Fingers crossed it gets in before the upcoming LTA.
Well, define core and define intact…
And just to be clear, there is no workaround for this to my knowledge - I’ve spent hours trying out your APIs without any luck. If there is a workaround (e.g. internal API) then please advise.
But, I’ll go through the web interface again and see what API calls there is to sniff.