Code coverage with github action - final

[caleb-sitton-inl]

---

Pull Request Description

What issue does this change request address? (Use "#" before the issue to link it, i.e., #42.)

#23

What are the significant changes in functionality due to this change request?

The run_tests shell script has been updated with a new feature. It now accepts a command line argument specifying which tests the user would like to run (unit, integration, or both). It defaults to running all tests. This feature is particularly useful when the user wishes to check the code coverage provided by a single test type.

A code coverage script named check_py_coverage.sh has been added. This script checks code coverage for all python files within the FORCE/src directory when run_tests is executed, and it returns the results in HTML format. It passes all command line arguments on to run_tests, thus preserving the functionality of arguments supported by run_tests. It is based on a similar script of the same name in the github.com/idaholab/raven repository. A config file for coverage.py has also been added.

The run_tests.yml script in the github action has been updated to run the above mentioned check_py_coverage.sh instead of the run_tests shell script. The coverage script serves as a wrapper around run_tests, so all tests are still run, albeit with some overhead time attributable to the coverage tracking. The coverage results are specifically exported to an artifact, where details regarding coverage can be found. A "notice" annotation has been added that alerts the user of the overall coverage of the tests in a more obvious manner than the artifact. The attached message also directs the user to the coverage artifact for more detailed coverage information.

---

For Change Control Board: Change Request Review

The following review must be completed by an authorized member of the Change Control Board.

• 1. Review all computer code.
• 2. Make sure the Python code and commenting standards are respected (camelBack, etc.) - See on the wiki for details.
• 3. Automated Tests should pass, including run_tests, pylint, and manual building tests.
• 4. If significant functionality is added, there must be tests added to check this. Tests should cover all possible options. Multiple short tests are preferred over one large test.
• 5. If the change modifies or adds a requirement or a requirement based test case, the Change Control Board's Chair or designee also needs to approve the change. The requirements and the requirements test shall be in sync.
• 6. The merge request must reference an issue. If the issue is closed, the issue close checklist shall be done.

[GabrielSoto-INL]

Minor changes requested, otherwise great work so far!

[GabrielSoto-INL]

Changes LGTM

[GabrielSoto-INL]

@caleb-sitton-inl would you be able to raise an issue for a code coverage feature request? I realize there is no linked issue within this PR