I was able to configure the tekton task for sonar-scanner-cli to work with sonar.token instead of username/password. I had to realize that the task is quite aged and needed some retrofitting for my purpose.
Has anyone tried that before? How do you work with sonarqube (scanning) in tekton? i also learned about not killing a tekton pipline after unittest-failure step by applying onError: continue to the tekton-step-definition \o/
I see your question isn’t getting much traction. You may be the first tekton specialist pioneer to show up here, which is probably why no one has tekton-specific tips for you. But if there are specific things you want to figure out how to do, we may be able to help from that direction.
Hey Ann, thank you for your reply. I also perceive the missing traction. Thank you for the offer, too. (And the ^H^Hpioneer ) My answer got longer that i expected…
Personally, i am currently figuring out what i need to recreate to get an automation flow between my flavour of git repo software and tekton/kubernetes-flavour that resembles what we already have set up via use of jenkins and jenkins-plugins
so, i am dabbling pioneering in finding out what bb-repo-webhook-json-payload-content needs to go into which variable so that my triggertemplate can then pick those up to be used on the fitting commandline params that are needed to inform sonarqube-server that this is - for example - a pullrequest analysis and not a branch-analysis
and as i am not an expert in any of these fields, my approach might contain traces of suboptimal decisionmaking etc
As a Sidenote: Concerning Tekton:
a)
I think it would be beneficial if the “offical” tekton task would be able to support the announced future (token instead of username/password). Maybe you (sonarsource as a business entity) might find a business case worthy of pursuit which concerns open source effort (e.g. working with the tekton community and improvement of the task in said library in a way that you like best)
Concerning community-effort-ish stuff
b) My perception is, that this kind of community effort gets swamped away by the stream of incoming new messages. If one would try to work with “stickies” there, the next decision would probably be how to have a fair streamlining there as there can only be a small amount of stickies … difficult.
Where this works automatically, SonarScanner picks that up from the info left in the environment after the checkout.
And, just in case it’s not obvious, SonarQube isn’t going to trigger analysis. That’s what your CI is for - to notice the change in the repo and trigger your pipeline.
hi ann, that is quite clear to me, ty. the most uncharted territory is exactly in the event-triggering process and how to connect the git-repo-event to the tekton event-triggering and connect that to the actual call of the scanner.
in my “pioneeringprocess” my missing link is/was how to know what info SonarScanner expects to be left in the environment. currently i am manually setting the three parameters documented here in a commandline.
aaand these params need to be extracted from a webhook payload and this works with a trigger binding and a trigger template and an eventlistener and a route and a service (i think ) on tekton side. I think i have a rather clear vision of what i need to create to get going.
oh, did i mention that the git-repo-webhook-payload is different if it is a pull request vs a branch commit? so the beforementioned binding and template needs to differentiate too and the eventlistener needs to differentiate also.
so thats what my “made up mind” looks right now … i think i’ll get it working that way, we’ll see how it goes
btw. my take is a bit less diplomatic … i might be the first to show up here but i most probably am not the first having worked in the problem space.
not one should assume they do not exist just because not does one see them posting about it :yoda_face:
I suspect that with if you’re using Git, you’ll find the expected pieces are just automatically there in the env after checkout. Or, you could go at this from the other end. Since we pick this up automatically from several providers, you could see what they’ve got floating around in their envs. Sorry, but we don’t document the envvars because that’s the “just works” part (i.e. we don’t believe there should be a need for most people.)
That said, I’ve found a little bit in Jira (1)(2).
Hi, this is an ongoing effort … long story short: i am getting somewhere, which is nice.
Some feedback on the way:
it was a challenge to make the (tekton) sonarqube-scanning task work with a token instead of user credentials
it is challenging to get a baseline which is able to support checking java and python
it is equally challenging to find a nice default how to make that baseline work with branch commits && pull requests
figuring out the necessary parameters got more and more easy along the way
I will try to flesh out some details when im done but for now i am here to ask … why the versions differ between gradle plugin website and sonarqube docs:
That’s actually on purpose. We released, but then had to roll back because of an incompatibility. I forget the details, but it’s one that will resolve itself in the future.
Pls excuse my tone. I am sure, i am getting something wronk here … actually i would like to assure that i am assuming wrongfully. am i?
//edit: it is nice to know now, ty for mentioning it! … for me and everyone reading here. but … maybe not everyone does read here or on SonarScanner for Gradle but just takes what is supplied on Gradle - Plugin: org.sonarqube?
) My answer got longer that i expected…
… difficult.
