-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add GitHub action to run SonarQube for METveiwer pull requests and feature branches #521
Comments
Copied from dtcenter/METplus-Internal#35. How to run SonarQube report for METviewer
Steps:
|
…file since we're using the same project for all scans.
Ran the following steps to test.
And that produces this result: |
…onsistent use of an environment variable.
…onarqube.xml I'd added to use for testing.
…the workflow_dispatch option can become available via GitHub
…witch to building against the develop version of the dependencies.
…witch to building against the develop version of the dependencies.
* Per #521, add hooks for a SonarQube GHA workflow. * Per #521, fix cut/paste error configure_sonarqube.sh * Per #521, hard-code the Sonar Project key and name in the properties file since we're using the same project for all scans. * Per #521, setup build_sonar.xml configuration by referencing environment variables. * work in progress * Per #521, move docker directory into internal/scripts for consistency across METplus repos * Per #521, work in progress. * Per #521, switch to running the sonar-scanner. * Per #521, still working on the details * Whitespace changes * Per #521, try turning on the sonarqube workflow for this feature branch. * Per #521, try turning on the sonarqube workflow for this feature branch. * Per #521, try to save the logs * Per #521, print the environment for debugging * Per #521, define missing DOCKERHUB_REPO and SOURCE_BRANCH envvars * Per #521, working on Dockerfile.copy * Per #521, use hard-coded /METviewer directory instead of to avoid inconsistent use of an environment variable. * Per #521, METVIEWER_GIT_NAME is set as SOURCE_BRANCH rather than being a required envvar. * Per #521, syntax * Per #521, consistency of Dockerfiles. * Per #521, remove feature_521_develop_sonarqube_gha branch name from sonarqube.xml I'd added to use for testing. * Per #521, singularity is named apptainer, as of 2021 * Per #521, more work is needed in the DockerHub build hook. For now, switch to building against the develop version of the dependencies.
…cy versions as main_v2.1 rather than develop. Note that DockerHub already uses the hooks/build file to define the dependencies... but the SonarQube workflow actually uses the versions listed in the Dockerifle. Note that issue #527 will clean up and refine this version depedency logic.
* Per #521, migrate the changes over to a branch for main_v5.1 so that the workflow_dispatch option can become available via GitHub * Per #521, more work is needed in the DockerHub build hook. For now, switch to building against the develop version of the dependencies. * Per #521, for the main_v5.1 branch, set the METplus-Analysis dependency versions as main_v2.1 rather than develop. Note that DockerHub already uses the hooks/build file to define the dependencies... but the SonarQube workflow actually uses the versions listed in the Dockerifle. Note that issue #527 will clean up and refine this version depedency logic.
After merging these changes into the
Manually reran SonarQube with the following commands:
Used these settings in
This process fails with a Java version issue.
|
…directory from the scan and code coverage computations.
…directory from the scan and code coverage computations.
Describe the New Feature
This issue is to add a new SonarQube workflow to GitHub actions to automate the static code analysis for all pull requests. In addition, add a manual trigger workflow dispatch option where the reference branch can be manually specified.
Recommend adding this workflow to both the
develop
branch and the currentmain_v*
so that the workflow dispatch option can be made available.Recommend pushing results to a new SonarQube project named
METviewer GHA
at needham.rap.ucar.edu.Recommend having the workflow report bad status if the number of SonarQube findings are increased relative to the SonarQube reference.
See issue dtcenter/MET#2379 and corresponding PR's as an example. Scanning the METviewer software may be more complicated that scanning a python-only repo. We may need to do this inside a Docker container, as we've done for the MET C++ code.
See instructions from @TatianaBurek here:
https://github.com/dtcenter/METplus-Internal/issues/35#issuecomment-2047821434
Acceptance Testing
List input data types and sources.
Describe tests required for new functionality.
Time Estimate
Estimate the amount of work required here.
Issues should represent approximately 1 to 3 days of work.
Sub-Issues
Consider breaking the new feature down into sub-issues.
Relevant Deadlines
List relevant project deadlines here or state NONE.
Funding Source
Needed for the Air Force - 2771024
Define the Metadata
Assignee
Labels
Projects and Milestone
Define Related Issue(s)
Consider the impact to the other METplus components.
The following SonarQube issues are closely related:
New Feature Checklist
See the METplus Workflow for details.
Branch name:
feature_<Issue Number>_<Description>
Pull request:
feature <Issue Number> <Description>
Select: Reviewer(s) and Development issues
Select: Repository level development cycle Project for the next official release
Select: Milestone as the next official version
The text was updated successfully, but these errors were encountered: