Chips-n-Salsa VS JaCoCo

name: docs on: push: branches: [ master ] paths: [ '**.java', '.github/workflows/docs.yml' ] pull_request: branches: [ master ] release: types: [created] workflow_dispatch: jobs: docs: runs-on: ubuntu-latest steps: - name: Checkout the repo uses: actions/checkout@v3 - name: Checkout the gh-pages branch uses: actions/checkout@v3 with: fetch-depth: 0 ref: gh-pages path: gh-pages - name: Set up JDK 17 uses: actions/setup-java@v3 with: distribution: 'adopt' java-version: '17' - name: Build docs with Maven run: mvn compile javadoc:javadoc - name: Copy to Documentation Website Location if: ${{ github.event_name == 'release' || github.event_name == 'workflow_dispatch' }} run: | rm -rf gh-pages/api cp -rf target/site/apidocs/. gh-pages/api - name: Tidy up the javadocs if: ${{ github.event_name == 'release' || github.event_name == 'workflow_dispatch' }} id: tidy uses: cicirello/javadoc-cleanup@v1 with: base-url-path: https://chips-n-salsa.cicirello.org/ path-to-root: gh-pages user-defined-block: | - name: Log javadoc-cleanup output if: ${{ github.event_name == 'release' || github.event_name == 'workflow_dispatch' }} run: | echo "modified-count = ${{ steps.tidy.outputs.modified-count }}" - name: Commit documentation changes without pushing yet if: ${{ github.event_name == 'release' || github.event_name == 'workflow_dispatch' }} run: | cd gh-pages if [[ `git status --porcelain` ]]; then git config --global user.name 'github-actions' git config --global user.email '41898282+github-actions[bot]@users.noreply.github.com' git add -A git commit -m "Automated API website updates." fi cd .. - name: Generate the sitemap if: ${{ github.event_name == 'release' || github.event_name == 'workflow_dispatch' }} id: sitemap uses: cicirello/generate-sitemap@v1 with: base-url-path: https://chips-n-salsa.cicirello.org/ path-to-root: gh-pages - name: Output stats if: ${{ github.event_name == 'release' || github.event_name == 'workflow_dispatch' }} run: | echo "sitemap-path = ${{ steps.sitemap.outputs.sitemap-path }}" echo "url-count = ${{ steps.sitemap.outputs.url-count }}" echo "excluded-count = ${{ steps.sitemap.outputs.excluded-count }}" - name: Commit documentation website sitemap and push all commits if: ${{ github.event_name == 'release' || github.event_name == 'workflow_dispatch' }} run: | cd gh-pages if [[ `git status --porcelain` ]]; then git config --global user.name 'github-actions' git config --global user.email '41898282+github-actions[bot]@users.noreply.github.com' git add -A git commit -m "Automated API website sitemap update." fi git push cd ..

Website: https://chips-n-salsa.cicirello.org/

The complete workflow file that this example is derived from is maven-publish.yml.

Let's look at a real example, again from Chips-n-Salsa, where I publish artifacts of the library on both Maven Central as well as to GitHub Packages. We'll build up to the full example. First, consider the configuration below:

To see a live example, you can consult the pom.xml of one of my projects. Here is the GitHub repository:

GitHub Language Chart From https://github.com/cicirello/Chips-n-Salsa

Website: https://chips-n-salsa.cicirello.org/

Important Note: Because of the way JitPack essentially builds a snapshot of your repository, even for release builds, the jitpack.yml must be present within the specific snapshot of your repository in order to apply. For example, for the library that this post is based upon, Chips-n-Salsa, the first release where the repository contains the configuration file is 5.0.1, so JitPack will fail to build any prior version, although earlier versions are available via Maven Central and GitHub Packages. Likewise, if you specify any commit hash prior to that of the commit where that configuration file was introduced, the JitPack build will also fail.

Chips-n-Salsa - A Java library of customizable, hybridizable, iterative, parallel, stochastic, and self-adaptive local search algorithms

I will use here JaCoCo, where also the JaCoCo-Maven-lugin exists for the usage in your Maven builds. This article will show how to configure the code coverage to finally get the results for unit- and integration-tests.

In protection rules, I added build workflow in Require status checks to pass before merging. This is to ensure that before merging code in master branch, build should run successfully. I also added Jacoco Code Coverage to make sure that enough unit tests are available in project and Detekt to make sure that code in project is readable. I added them in build configuration. Even if one of them gives error, build will fail. Whenever, someone push code in pull request, build action will run and check if build is running successfully or not.

Code coverage analysis tools quantify the amount of tested code, serving as a valuable tool to inform on code structure and testing related decisions. We will make use of JaCoCo, JaCoCo produces reports on multiple kinds of code coverage metrics including instructions, line and branch coverage.

One specific example where I regularly use a profile in this way is for configuring code coverage. In all of my Java projects, I use JaCoCo for generating code coverage reports. I use JaCoCo during the Maven test phase. However, while developing I find it useful at times to exclude coverage reporting to reduce the build time. But in my CI/CD workflows in GitHub Actions, I activate the code coverage profile during pull-requests and pushes to the default branch. For pull-requests, my GitHub Actions workflow comments the code coverage on the PR and uploads the coverage report as a workflow artifact, where I can inspect it as necessary. And during a push to the default branch, my workflow updates coverage badges to keep them up to date with the current state of the default branch. I can also activate the code coverage profile locally while developing, such as prior to submitting a pull-request, to ensure that I didn't miss testing something.

In Unit tests, individual software code components are checked if it is working as expected or not. Unit tests isolate a function or module of code and verify its correctness. We can use tools like JaCoCo for Java and Mocha, and Jasmine for NodeJS to generate unit test reports. We can also send these reports to SonarQube which shows us code coverage and the percentage of your code covered by your test cases.

And there is the original jacoco/jacoco: (0.8.7: released this on May 5, 2021), but it's for Java. I'm not sure if we can use it with multiple flavors on Android.

Make sure to also update to Jacoco 0.8.7 to avoid test issues: https://github.com/jacoco/jacoco/releases/tag/v0.8.7