once the token fixed first calls were succesfull but then projects/search api still have http 401 error…
I have noticed there is “Requires ‘System Administrator’ permission” …which was not before…
… again, lot’s of our azure devops pipelines stopped working, lot’s of man/hours already spent investigating what the heck is broken again
I can only guess, that:
someone/something has revoked our tokens
API authorization has changed
Is my guess right? If yes, how can we update our pipeline to be “compliant”?
Is there any public information about such changes and why those are being introduced?
We are reallly, really, really, really (did I mention how much?) some public information about current version of SonarCloud, API, release notes, history of changes…
PS: why we are calling projects/search? There is simply no GET project api and we want to crate a project if it does not exist during our pipeline…
SonarCloud tokens do not end up revoked without user action (SonarSource isn’t revoking any tokens on behalf of users), and there have been no deployments related to API authorization or these API endpoints.
GET api/projects/search requires Administer Organization permissions on the organization. This has always been the case. If the permissions are assigned to specific groups instead of individual users, it may be worth checking that group membership has not changed.
Oh, make sense. I have had worries this was changed somehow.
Yep. I am able to navigate (with correct organization parameter) and get results from that API call via browser.
Yep, sure, thanks. Since this worked fine for several moths (in fact since 2021/03) and just today it starts failing even the connection was OK/fixed, I kind of suspected some server side change…
I think the best debugging steps you could do would be printing the full URL that is being queried (to make sure it’s expected) as well as the value used for sonar.login (to make sure it’s the one you expect – the new token).
Thanks Colin to pointing me to a right direction. Indeed the tocken was a different one… after digging through tons of audit logs (btw. for azure devops the link is Azure DevOps Services | Sign In & it can be exported to Azure Monitor and more…) I have found out the connection was modified by one of my colleague in parallel… that’s what has confused me tbh.
So sorry for filling up this bug & wasting your time while the issue was on our side. And really thanks a lot for helping me.
Anyway one question is still valid: is there any public information about a version (and release date/when it was deployed, release notes…) so we can eliminate server side changes/updates in the future?
It’s a valid question and also valid feedback which I’m happy to pass along. Here’s my honest take on it right now:
We don’t deploy “versions” of SonarCloud — we continuously merge and deploy changes to SonarCloud. When there are big changes (new features, deprecations, requirements changes, etc.) we announce them. Our general issue tracker (bugs/improvements/deployments) is internal.
This works pretty well as is. Can you honestly tell me that if such detailed notes were available, and something went wrong without a good explanation, the question wouldn’t become “what’s missing from the release notes”?
Personally (taking my SonarSourcer hat off), I wish we had a way of helping users know what changed on SonarCloud since yesterday, even if it’s the small stuff (as a user of other cloud services, I know I care about the small stuff sometimes!)
To be honest I believe it would at least point us in the right direction. Pipelines stops working: first thing we try to figure out is “what the hell was changed”…
Not sure, if this is something “built-in” in Azure DevOps or if this is something you as SonarSource as author of the service connection type can fix maybe?
Context: SonarCloud is shared service connection. Unfortunatelly it can not be shared “for all projects”, you need to assign it project per project. So yesterday colleague of mine was sharing the connection to some newly created project. Nother unfortunate thing is that the name of the connection is changed to “SonarCloud - NewProject” …while my colleague was trying to fix this (actually only changing the name of the connection) and saving it in the scope of the new project, he fails to “verify it”…so he saved it without verification… this process changed the token from real token to ‘****’ which was ofc not valid…