Proposing that we start pushing SonarQube scans to a single project, named MET rather than using separate ones for GitHub actions and the nightly build. I've renamed the existing MET_NB project as simply MET to keep the long nightly build scan history. Once this PR is merged, I'll delete the unneeded MET_GHA project.
These scans are for the same branches of the same code and therefore should be comparable. The only potential issue I foresee is for different versions of the scanner being using by GitHub actions and the nightly build. Hopefully that's not an issue, but we can always adjust as needed.
Pushing to single project should make it easier for us to track/address findings directly with the SonarQube server. It simplifies the SonarQube results into a single spot rather than having duplicate information in 2 projects. And it cuts our LOC usage in half from 400K down to 200K.
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:
Ran SonarQube scan as the met_test user on seneca for this feature branch:
runas met_test
cd /d1/projects/MET/MET_pull_requests/met-12.0.0/beta5/MET-feature_2379_develop_single_sq_project
source internal/scripts/environment/development.seneca
internal/scripts/sonarqube/run_sonarqube.sh develop >& run_sonarqube.log
[x] Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions:
Review the proposed changes.
[x] Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes]
None needed.
[x] Do these changes include sufficient testing updates? [Yes]
None 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 TruthMETplus issue to describe them.
[x] Do these changes introduce new SonarQube findings? [No]
If yes, please describe:
[x] Please complete this pull request review by [Thurs 4/18/24].
[ ] Review the source issue metadata (required labels, projects, and milestone).
[ ] Complete the PR definition above.
[ ] Ensure the PR title matches the feature or bugfix branch name.
[ ] 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
[ ] 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.
Proposing that we start pushing SonarQube scans to a single project, named MET rather than using separate ones for GitHub actions and the nightly build. I've renamed the existing MET_NB project as simply MET to keep the long nightly build scan history. Once this PR is merged, I'll delete the unneeded MET_GHA project.
These scans are for the same branches of the same code and therefore should be comparable. The only potential issue I foresee is for different versions of the scanner being using by GitHub actions and the nightly build. Hopefully that's not an issue, but we can always adjust as needed.
Pushing to single project should make it easier for us to track/address findings directly with the SonarQube server. It simplifies the SonarQube results into a single spot rather than having duplicate information in 2 projects. And it cuts our LOC usage in half from 400K down to 200K.
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: Ran SonarQube scan as the
met_testuser onsenecafor this feature branch:See the resulting scan here.
[x] Recommend testing for the reviewer(s) to perform, including the location of input datasets, and any additional instructions: Review the proposed changes.
[x] Do these changes include sufficient documentation updates, ensuring that no errors or warnings exist in the build of the documentation? [Yes] None needed.
[x] Do these changes include sufficient testing updates? [Yes] None 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] Do these changes introduce new SonarQube findings? [No] If yes, please describe:
[x] Please complete this pull request review by [Thurs 4/18/24].
Pull Request Checklist
See the METplus Workflow for details.