Feature #2379 sonarqube gha

[JohnHalleyGotway]

Please read through this issue comment for a description of the changes and logic as well as a list of future items. Recommend proceeding with these changes for now and considering how we can refine our use of SonarQube in the future.

Once this PR is approved, I'll submit another PR to make the same changes in the main_v11.1 primarily so that the manual triggers will become available which would be very convenient for development of feature branches.

Expected Differences

• [x] Do these changes introduce new tools, command line arguments, or configuration file options? [No]
  If yes, please describe:
  

• [x] Do these changes modify the structure of existing or add new output data types (e.g. statistic line types or NetCDF variables)? [No]
  If yes, please describe:
  

Pull Request Testing

• [x] Describe testing already performed for these changes:
  Did lots of testing on my laptop and confirmed that the GHA tests all pass.

• [x] Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:
  

  • @hsoh-u please review these changes to the GHA automation, consider my use of Docker in particular. Please also consider my use of SonarQube and project naming conventions at needham.rap.ucar.edu. Are there any changes you'd recommend?
  • @jprestop please see the update to the PR template to make a generic reference to SonarQube. Should I include any other changes to the documentation at this time? Or just wait for our automated use of SonarQube to mature more?

• [x] Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [No] I made no documentation updates at this time.

• [x] Do these changes include sufficient testing updates? [Yes] No new unit tests are needed.

• [x] Will this PR result in changes to the MET test suite? [No]
  If yes, describe the new output and/or changes to the existing output:
  

• [x] Will this PR result in changes to existing METplus Use Cases? [No]
  If yes, create a new Update Truth METplus issue to describe them.

• [x] Please complete this pull request review by [Wed 4/3/24].
  

Pull Request Checklist

See the METplus Workflow for details.

• [x] Review the source issue metadata (required labels, projects, and milestone).
• [x] Complete the PR definition above.
• [x] Ensure the PR title matches the feature or bugfix branch name.
• [x] Define the PR metadata, as permissions allow. Select: Reviewer(s) and Development issue Select: Milestone as the version that will include these changes Select: Coordinated METplus-X.Y Support project for bugfix releases or MET-X.Y.Z Development project for official releases
• [x] After submitting the PR, select the :gear: icon in the Development section of the right hand sidebar. Search for the issue that this PR will close and select it, if it is not already selected.
• [ ] After the PR is approved, merge your changes. If permissions do not allow this, request that the reviewer do the merge.
• [ ] Close the linked issue and delete your feature or bugfix branch from GitHub.

[JohnHalleyGotway]

@hsoh-u and @jprestop these changes are now ready for your review. And they are working just how we'd like.

On my feature branch, I did intentionally introduce a SonarQube finding in the C++ code. And in this GHA run the SonarQube CXX Quality Gate check step fails just like we'd want it to! Here's a screenshot of what those new findings look like in the SonarQube server:

In general, the SonarQube scan is compared between the code for the PR and the reference branch. If the "new code" introduces new findings, the quality gate check fails. Since I removed that intentional breakage, the final run of the SonarQube GHA workflow should pass.

The only other thing we could consider is splitting out the logic for the Python and C++ scans into separate steps. The C++ scan is WAY more complex than the Python one. If I could make a simple Python one, it'd be easier to apply it to the other Python-based METplus repos.

Should I pursue that now? Or just be happy that this setup works well?

[JohnHalleyGotway]

I've decided to proceed with the logic as-is. The logic for doing this in the other METplus repos will be similar but not identical. But doing both the Python and CXX in the same Docker container for MET makes a lot of sense. I'll proceed with merging this PR and will then propose the same changes for the main_v11.1 branch.

[jprestop]

Sounds good! Thanks!