Developer license for testing

This is a follow up from SQ Developer License in automated tests.

While there are container images on Docker Hub for the developer edition, those images cannot be used to test the integration of CI tooling with SonarQube in public repositories (e.g. using GitHub Actions). The problem is that there is no license which can be used for that case. So to make this clear: I do not want to use SQ to analyse some source code, instead I want to test that my CI pipeline works well with SQ (especially the PR decoration).

For this purpose, one would need a license which can be public. This license can be very restricted, e.g. it might only work for a couple of hours or it might be limited to e.g. 500 lines of code.

As an example, Atlassian provides something like this for their server products: https://developer.atlassian.com/platform/marketplace/timebomb-licenses-for-testing-server-apps/.

Could you provide such a license?

Hi @michaelsauter,

Is your concern about making your license publicly accessible, or about eating up LOC against the license while doing testing?

If the concern is about public access: The idea is to use GitHub secrets to store a token tied to a user in your licensed instance so that nobody looking at your public repo is able to get credentials to your SonarQube instance. The GitHub actions run on this repo will contact your SonarQube, but it doesn’t mean you’ve given the whole internet access to it.

If the concern is about eating LOCs from your license to do testing, there are some options to consider:

  • We offer additional test/staging to customers who buy support contracts (contact your Sales rep to discuss). You could use such a licensed instance for dedicated tests to confirm your infrastructure works.
  • You can simply delete the test projects from your instance once you’ve validated they work. They’ll temporarily eat LOC off your license while they exist but it will be “given back” once you delete them.

My concern is about making the license publicly accessible.

LOC will not be an issue as I’m testing the integration. For this purpose I have a dummy app that has 50 lines of code or so, so a very low limit on LOC will not be an issue.

I know that GitHub actions allows to store secrets that way, but those secrets are (obviously) not shared with forks. However, the typical contribution flow on GitHub is via pull requests from forks. I would like to run the integration tests on the PRs before merging them.