Skip to content
This repository has been archived by the owner on Aug 21, 2021. It is now read-only.

Sonarqube in Docker #30

Open
JoshMentzer opened this issue Sep 23, 2019 · 3 comments
Open

Sonarqube in Docker #30

JoshMentzer opened this issue Sep 23, 2019 · 3 comments

Comments

@JoshMentzer
Copy link

Is it possible to configure the sonar-crowd plugin via the environment from a docker-compose file? Ie.:

sonarqube:
image: sonarqube
expose:
- '9000'
environment:
- sonar.jdbc.url=jdbc:postgresql://sonardb:5432/sonar
- crowd.url=${CROWD_URL}
- crowd.application=${CROWD_APPNAME}
- crowd.password=${CROWD_PASSWORD}
- sonar.security.realm=Crowd
- sonar.security.localUsers=admin,sonar

In this case whether hardcoded or using an environment variable to keep this info out of our repo sonarqube service can't start with error:

sonarqube_1 | 2019.09.23 21:02:07 INFO web[][org.sonar.INFO] Security realm: Crowd
sonarqube_1 | 2019.09.23 21:02:07 ERROR web[][o.s.s.p.Platform] Background initialization failed. Stopping SonarQube
sonarqube_1 | org.sonar.api.utils.SonarException: Security realm fails to start: crowd.password is not set

Wondering if this is just not a capability, or if something crazy is happening,
thanks!

@deepy
Copy link
Owner

deepy commented Sep 24, 2019

Hmm, if you're lucky sonar.crowd.password might work otherwise you'll have to use bind-mounted persistent volumes or custom docker images.

But I like the idea of this, I'll have a look and see how it's done in sonarqube, though really it feels like this should be done upstreams

@bchatard
Copy link

hello,

I try the following environment variables:

  • CROWD_<KEY> (eg: CROWD_PASSWORD): fail
  • SONAR_CROWD_<KEY> (eg: SONAR_CROWD_PASSWORD): fail too

I go trough mounted volume of SONARQUBE_HOME/conf/sonar.properties, but env vars will be the best for docker instance :)

@deepy
Copy link
Owner

deepy commented Apr 29, 2020

I guess it'd be pretty easy to implement this using System.getenv(), if someone submits a PR I'll accept it and create a release, but I think this is something that should be pushed upstreams, to me it makes sense that sonarqube would have some mechanism to accept any properties through environment variables (and there is some support already: see link.

Especially since we're using org.sonar.api.config.Configuration and Configuration.get()

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants