<div><div><div><div>Hello,<br></div><div><br></div><div><div>Following up on my previous email, I forgot to mention that I am currently an intern doing this as part of my summer project, with an end week of August 30th. With this in mind, I do have a limited amount of time to work with, so I would appreciate any help maintainers can provide to get code reviewed quickly. Thank you. <br></div><div><br></div><div>Jose Iciano<br></div></div></div><div><br></div></div></div><div><br></div><div><br></div><div class="protonmail_quote">
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br>
On Wednesday, June 23rd, 2021 at 7:11 PM, Jose Iciano <joseiciano@protonmail.com> wrote:<br>
<blockquote class="protonmail_quote" type="cite">
<div>Hello,<br><br>My name is Jose Iciano and I currently working on an implementation of per-build code coverage for OBMC as part as an internship project. The draft of the current system's description will be available at the end of the email. Currently, I have been able to develop the required functions and am getting them checked by code reviews on Gerrit. <br><b><br>Draft of the Current System: </b><a href="https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/44409/1/code-coverage.md" target="_blank" rel="noreferrer nofollow noopener">https://gerrit.openbmc-project.xyz/c/openbmc/docs/+/44409/1/code-coverage.md</a><br><b><br>Machine Per-Build Code Coverage</b></div><div><br></div><div>The following report details the code coverage system implemented for OpenBMC builds.<br></div><div><br></div><div>OpenBMC currently relies on a manual system for detailing code coverage of any repositories used for image building. With each machine, there is a repo combination unique to it. This means that currently, if one wants to view the status and changes of those repositories, they would have to manually clone it and run unit tests on the correct version. This system automates the process and allows the aggregation of code coverage for the selected build.<br></div><div><br></div><div>This process is done through a modified version of OBMC’s `get_unit_test_report.py` script, adding per-build capabilities and improving lcov data generation.<br></div><div><br></div><div><b>Running Files</b><br></div><div><br></div><div>Start by creating a repository for CI and CI scripts to be stored.<br></div><div><br></div><div>```<br></div><div>mkdir ci_test_area<br></div><div>cd ci_test_area<br></div><div>git clone [<a href="https://github.com/openbmc/openbmc-build-scripts.git](https://github.com/openbmc/openbmc-build-scripts.git)" target="_blank" rel="noreferrer nofollow noopener">https://github.com/openbmc/openbmc-build-scripts.git](https://github.com/openbmc/openbmc-build-scripts.git)</a><br></div><div>```<br></div><div><br></div><div>To run with specified , image config files have to be modified to inherit the new file.<br></div><div>```<br></div><div>${BUILDDIR}/conf/local.conf<br></div><div>```<br></div><div><br></div><div>Add<br></div><div>```<br></div><div>INHERIT += “buildhistory”<br></div><div>BUILDHISTORY_COMMIT = “1”<br></div><div>```<br></div><div><br></div><div>Run the following command to run without a specified url_file or buildhistory path.<br></div><div><br></div><div>```<br></div><div>python3 openbmc-build-scripts/scripts/get_unit_test_report <target_dir><br></div><div>```<br></div><div><br></div><div>Running with a buildhistory path<br></div><div><br></div><div>```<br></div><div>python3 openbmc-build-scripts/scripts/get_unit_test_report <target_dir> -build_history <build_history_path><br></div><div>```<br></div><div><br></div><div><b>Source File and Revision Generation</b><br></div><div><br></div><div>The file `code_coverage.sh` generates a repositories.txt file, which stores the src_url and src_rev of repositories used during image creation. The format is stored in the following format:<br></div><div><br></div><div>```<br></div><div><src_url> <src_rev><br></div><div>```<br></div><div><br></div><div>The resulting file is intended to be used for any automated test suite runner, such as OBMC’s `get_unit_test_report.py`’s url_file parameter.<br></div><div><br></div><div><b>Automated Test Cases</b><br></div><div><br></div><div>Test case is automated through the use of `get_unit_test_report.py`, which takes care of cloning the specific repositories and running unit tests on it. This file was pre-existing in the codebase, but was slightly modified to work with the new files, as well as implementing optional source revision.<br></div><div><br></div><div>Optional parameters were modified to allow for more variables. The extra parameters added were<br></div><div><br></div><div>```<br></div><div>-build_history - Path to buildhistory that was created during image generation.<br></div><div>```<br></div><div><br></div><div><b>LCOV Aggregation</b><br></div><div><br></div><div>LCOV data is freely available after running the `get_unit_test_report.py` script. `code_coverage.py` works by taking all the available data and aggregating it into an easy to access file. This simplifies the process of lcov analysis, as the necessary data/files can be found from one simplified file.<br></div><div><br></div><div>Code_coverage.py works by taking in the path of directories leading to `<repo>/build/<coveragereport_path>/index.html.` It sifts through each file and reads the resulting lcov data from the index.html file.<br></div>
</blockquote><br>
</div>