[action][sonar] replace deprecated sonar.login parameter with sonar.token

[Panajev]

Checklist

• I've run bundle exec rspec from the root directory to see all new and existing tests pass
• I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
• I see several green ci/circleci builds in the "All checks have passed" section of my PR (connect CircleCI to GitHub if not)
• I've read the Contribution Guidelines
• I've updated the documentation if necessary.
• I've added or updated relevant unit tests.

Motivation and Context

Addresses #21436, for more information see SonarQube deprecation notice of the login property here: https://community.sonarsource.com/t/deprecating-sonar-login-and-sonar-password-in-favor-of-sonar-token/95829

Description

SonarQube has deprecated the login parameters and requires the token passed as -Dsonar.token. Warnings appear in fastlane

Testing Steps

Test changes when submitting data to sonarqube using a recent (5.0.x+) version of the sonar-scanner CLI too.

[lacostej]

Hello @Panajev Thanks for your first contribution :)

Could you look into the comment and see if it makes sense? Thanks

[Panajev]

Hello @lacostej no worries, I checked your comment and took a stab at it. Added a couple of commits to sort it. Will squash them together to make the delta from my original commit easier.

[Panajev]

The 2 options should conflict each other --> this means that the script should break if they are both set at the same time right?

[Panajev]

I think the conflicting_options array should do the trick in terms of ensuring we cannot pass both options:

          FastlaneCore::ConfigItem.new(key: :sonar_login,
                                       env_name: "FL_SONAR_LOGIN",
                                       description: "Pass the Sonar Login Token (e.g: xxxxxxprivate_token_XXXXbXX7e)",
                                       deprecated: "Deprecated in sonar-scanner >= 5.0.x",
                                       optional: true,
                                       sensitive: true,
                                       conflicting_options: [:sonar_token]),
          FastlaneCore::ConfigItem.new(key: :sonar_token,
                                       env_name: "FL_SONAR_TOKEN",
                                       description: "Pass the Sonar Token (e.g: xxxxxxprivate_token_XXXXbXX7e)",
                                       optional: true,
                                       sensitive: true,
                                       conflicting_options: [:sonar_login]),

What do you think?

[Panajev]

Tested a local project on the local fastlane fork after the changes above:

---

Using the deprecated option (quick test and I did not re-gress the variable I passed to the old option, but it is just a local var):

---

Trying to use the deprecated option as well as the old option:

---

Using the new option only:

[Panajev]

This could still affect people on an old version of SonarQube though (not sure when the sonar.token property was added... I guess we could still use the old option if the user has an older SonarQube instance?).

Edit: This parameter was added to SonarQube (not the client) in March 2023 and SonarCloud should have updated in July ( https://community.sonarsource.com/t/deprecating-sonar-login-and-sonar-password-in-favor-of-sonar-token/95829 ) so it is reasonable to assume it is the default option.

Updated deprecation notice:

[lacostej]

LGTM. Anyone else wants to review?

[rogerluan]

Hi @Panajev 👋

Thanks for your PR!

Would you mind merging latest master into this branch? There was a recent fix in CI that needs to be merged into this PR so we can move it forward 🙏

I also left some comments in the PR 🙇

Thank you!

[Panajev]

Thanks for your comments, I shall action them and report back :)!

[Panajev]

@rogerluan implemented the suggestions. Resolved most of the conversation, left open the one I still had a question for you on (sorry if I should have closed none of them). Please let me know what you think :).

[rogerluan]

Thanks @Panajev ! I've replied to the open discussion 😊 No apologies needed, all good with closing the resolved ones 🤗

[Panajev]

@rogerluan thanks again for the kind feedback. Addressed by implementing your suggestion :)!

[rogerluan]

Looks good @Panajev ! Thank you for your contribution! 🤗