How to Config GitHub ALM integration via

Must-share information (formatted with Markdown):

  • which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension)
    • SonarQube v8.8
  • what are you trying to achieve
    • Automate the GitHub ALM integration
  • what have you tried so far to achieve this
    • Search docs, Google, Code Base. Found mentions to deprecated properties in the code.

I’m trying to automate the configuration of SonarQube. Most configuration options have helpful keys with the exception of the ALM integration for GitHub. I can’t seem to find the keys required for configuring this; only seems do-able from the UI.


Welcome to the community!

First, it’s worth noting that 8.8 is now past EOL. SonarQube 8.9 is the LTS and also currently the Latest version. You should upgrade at your earliest convenience.

Second, there are values that are set via and values that are set via the UI. The fact that some UI values are currently settable via is unintended and for you a happy accident. If you need to automate setting those values, you should take a look at the API.


So setting configurations via the file is now considered “legacy” and going forward, it is expected to use the API?

If so, that makes it tough to build repeatable deployments that are checked into SCM. This is especially true with Kubernetes and creating Stateful workloads.


Can you please tell me more about your use-case?
The configuration of your GitHub integration should be stored into the database. Why are automating the restart from a fresh SonarQube instance?


Hi @Chris ,

Sure. We’re deploying SonarQube via Kubernetes. Our deployments are built in a fashion that eliminates any manual steps to deploy a clean environment. To that end, we store everything in code (SCM) with the exception of secrets. Secrets are pulled from a vault (ie. HashiCorp Vault) and subsequently injected into the Pod/App utilizing Terraform for this orchestration.

For this particular use-case with GitHub, we’d like to set all the GitHub configs in and/or ENV Vars. For secret values like Client Secret and Private Key, we’d use settings encryption or Env Vars.

Hopefully this helps explain our use case. Let me know if I can provide any more color. Thanks.

Thanks a lot for the explanation.
Is your policy motivated by a wish to track changes in the SCM, or would you have an other motivation (ex: disaster recovery…)?

All of the above really; including the speed at which we can bring up new environments on-demand.

Thanks for sharing.