Jx: Add sonarqube addon

Created on 1 Apr 2018  路  21Comments  路  Source: jenkins-x/jx

So that pipelines invoke sonarqube - either via the SaaS service or a sonarqube chart

areaddon areapps kinenhancement lifecyclrotten prioritimportant-soon

Most helpful comment

After a lot of fiddling, I finally got the ingress working with the existing NLB

Create custom values for stable/sonarqube in sonarqube.yml

service:
  type: ClusterIP
  annotations:
    fabric8.io/expose: "true"
    fabric8.io/ingress.annotations: "kubernetes.io/ingress.class: nginx"

Install the chart using jx:

jx step helm install --set-file sonarqube.yml --name <releaseName> stable/sonarqube

Create the Ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: sonarqube
  annotations:
    # use the shared ingress-nginx
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: sonarqube.jx.<customDomain>
    http:
      paths:
      - path: /
        backend:
          serviceName: <releaseName>-sonarqube
          servicePort: 9000

All 21 comments

Please add this

There is a chart for SonarQube in https://github.com/helm/charts/tree/master/stable/sonarqube that could be useful for this task.

Super useful for us!

I think the SonarQube can be installed now as an application.

cc @pmuir

@deanesmith is still working on it

@deanesmith: any update soonish? Inquiring minds wish to know :-) Would be happy to help test and maybe tweak at it a bit

@Cervator we have been addressing other jx related matters specific to addons (we refer to them as apps), but I may have some bandwidth to pick this back up. The case of invoking SonarQube from a pipeline is straightforward

I tried setting up sonarqube using helm. And it works quite well. Only problem I have is that Jenkins X sets up a network load balancer in AWS for itself and other apps like Nexus. But the helm chart for sonarqube sets up an additional load balancer; a classic load balancer. Is there any way to tweak the helm chart configuration for sonarqube to use the existing NLB?

been avoiding doing this via helm due to the fact the load balancer stuff would come up as @gazal-k mentioned.. but also on top of that.. the integration become a bit ad-hoc and require some possible manual nonsense to integrate automatically in a jxified way

I tried setting up sonarqube using helm. And it works quite well. Only problem I have is that Jenkins X sets up a network load balancer in AWS for itself and other apps like Nexus. But the helm chart for sonarqube sets up an additional load balancer; a classic load balancer. Is there any way to tweak the helm chart configuration for sonarqube to use the existing NLB?

Also curious about this too... I know the helm sonarqube has some ingress options that could be passed/ignored

ping

I tried setting up sonarqube using helm. And it works quite well. Only problem I have is that Jenkins X sets up a network load balancer in AWS for itself and other apps like Nexus. But the helm chart for sonarqube sets up an additional load balancer; a classic load balancer. Is there any way to tweak the helm chart configuration for sonarqube to use the existing NLB?

Also curious about this too... I know the helm sonarqube has some ingress options that could be passed/ignored

Sorry, I haven't tried tweaking it yet.

I tried setting up sonarqube using helm. And it works quite well. Only problem I have is that Jenkins X sets up a network load balancer in AWS for itself and other apps like Nexus. But the helm chart for sonarqube sets up an additional load balancer; a classic load balancer. Is there any way to tweak the helm chart configuration for sonarqube to use the existing NLB?

It seems the helm chart supports setting service.type. If you set this to ClusterIP and make sure your ingress controller picks it up (by ingress.class for example) you should be able to add it to the existing LB.

I tried setting up sonarqube using helm. And it works quite well. Only problem I have is that Jenkins X sets up a network load balancer in AWS for itself and other apps like Nexus. But the helm chart for sonarqube sets up an additional load balancer; a classic load balancer. Is there any way to tweak the helm chart configuration for sonarqube to use the existing NLB?

It seems the helm chart supports setting service.type. If you set this to ClusterIP and make sure your ingress controller picks it up (by ingress.class for example) you should be able to add it to the existing LB.

Thanks for the tip. I'll give it a go

After a lot of fiddling, I finally got the ingress working with the existing NLB

Create custom values for stable/sonarqube in sonarqube.yml

service:
  type: ClusterIP
  annotations:
    fabric8.io/expose: "true"
    fabric8.io/ingress.annotations: "kubernetes.io/ingress.class: nginx"

Install the chart using jx:

jx step helm install --set-file sonarqube.yml --name <releaseName> stable/sonarqube

Create the Ingress:

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: sonarqube
  annotations:
    # use the shared ingress-nginx
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: sonarqube.jx.<customDomain>
    http:
      paths:
      - path: /
        backend:
          serviceName: <releaseName>-sonarqube
          servicePort: 9000

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale

/remove-lifecycle stale

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close.
Provide feedback via https://jenkins-x.io/community.
/lifecycle rotten

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://jenkins-x.io/community.
/close

@jenkins-x-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.
Provide feedback via https://jenkins-x.io/community.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository.

Was this page helpful?
0 / 5 - 0 ratings