IvanBoychevMarinov
commented
11 months ago After the initial overview we identified at least two approaches to provide meaningful information about the unit test code coverage.
- Add builds to the current release procedure to build the suggested artifacts and include them in the release.
- Add additional workflows for each of the repositories to provide some overview of the current working branch.
Both of the approaches have some advantages on their own. Right now I think we will go will both of them.
k-gostev
The proposal is to execute unit tests for each Kanto component when a release is done, to generate code coverage reports (maybe both text and HTML output formats) and store all these reports as release assets in each component's repository.
This can be easily achieved by adding to each repository a release workflow that is triggered upon a release creation - it needs to setup the environment with Go enabled, checkout the source code, execute the unit test cases (preferably enabling -v (verbose), -race flags), store the execution output as unit test report, generate code coverage reports as text and HTML output and make an archive of these. Finally, the unit test report file and the archive with text/HTML code coverage reports are to be uploaded as release assets.
This will be somehow a guaranty for quality of the released component.