Open JoshMentzer opened 5 years ago
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
hello,
I try the following environment variables:
CROWD_<KEY>
(eg: CROWD_PASSWORD
): failSONAR_CROWD_<KEY>
(eg: SONAR_CROWD_PASSWORD
): fail tooI go trough mounted volume of SONARQUBE_HOME/conf/sonar.properties
, but env vars will be the best for docker instance :)
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()
Is it possible to configure the sonar-crowd plugin via the environment from a docker-compose file? Ie.:
sonarqube: image: sonarqube expose:
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!