fix: make sonar_token_variable_name parameter work

[YaraslauZhylko]

Problem

The sonar_token_variable_name parameter is declared in the docs but is not actually used by the orb. The script still strictly requires the token to be stored in SONAR_TOKEN variable.

Solution

Make the script use SONAR_TOKEN_VARIABLE_NAME all the time.
If the user does not provide the value, it defaults to SONAR_TOKEN as planned.

[antoine-vinot-sonarsource]

Hi @YaraslauZhylko ,

Thank you very much for this fix 🚀

I have a question regarding the usage of this parameter. We are wondering how useful it is, like what is your test case? Could you name your variable SONAR_TOKEN or do you have a specific reason not to?
We are thinking about deprecating and removing this parameter if it appears unneeded.

In the meantime, I have open another PR where I cherry picked your fix and added a test for the param as well as a couple of minor fixes to your change.

[YaraslauZhylko]

Hi @antoine-vinot-sonarsource!

I have a question regarding the usage of this parameter. We are wondering how useful it is, like what is your test case? Could you name your variable SONAR_TOKEN or do you have a specific reason not to?

We have a single CircelCI context called sonarcloud that contains tokens for different projects. Like PROJECT_1_SONAR_TOKEN, PROJECT_2_SONAR_TOKEN, etc.

So we need an extra step to pass the token to the scanner like this:

- run:
  name: Export PROJECT_SONAR_TOKEN as SONAR_TOKEN
  command: echo "export SONAR_TOKEN=${PROJECT_SONAR_TOKEN}" >> "$BASH_ENV"

Instead of doing:

- sonarcloud/scan
  sonar_token_environment_variable: PROJECT_SONAR_TOKEN

---

If you remove the parameter, we'll just keep doing this or split this particular context ito project-oriented ones.
The PR was mainly created to fix the discrepancy between the docs and the actual behaviour.

[antoine-vinot-sonarsource]

@YaraslauZhylko Thank you for the clarification.
Given what you said it's most likely that we will drop this parameter because:

1. It never worked previously
2. For consistency: Other similar CI tool we provide, like our GitHub action for example, don't have this capability.

So, all in all, we don't believe the use case for this parameter is worth maintaining it.
I am going to close both Pull Request, and I created a ticket on our side to drop the parameter.