jacoco-badge-generator VS Chips-n-Salsa

jacoco-badge-generator - Coverage badges, and pull request coverage checks, from JaCoCo reports in GitHub Actions

I just released jacoco-badge-generator 2.10.0, which can be run as a GitHub Action or as a command-line utility as part of CI/CD workflows for Java projects, as well as for projects in other JVM languages such as Kotlin, to parse JaCoCo test coverage reports, generate instructions coverage and branches coverage badges for project READMEs, serve as pull-request checks (e.g., validate minimum coverage thresholds), among other functionality.

I just release version v2.9.0, which enhanced the existing functionality associated with using the jacoco-badge-generator GitHub Action with multi-module projects. Specifically, prior to this release, for a multi-module project, the paths to all of the JaCoCo csv reports had to be listed in the inputs to the action. Now, as of v2.9.0, you can use a glob pattern to specify the paths to the JaCoCo csv reports. This can actually now also work for the more common single module project, but the glob functionality is likely most useful in the multi-module case. Note that the CLI mode already implicitly supported globs since your shell will expand any globs you specify on the command line. But as a GitHub Action this previously was not the case as GitHub Actions doesn't expand globs in the inputs to an Action. The jacoco-badge-generator v2.9.0 now handles glob expansion internally.

Vincent Cicirello - Open source GitHub Actions for workflow automation

I maintain several GitHub Actions implemented in Python as container actions. One of these, jacoco-badge-generator, produces coverage badges from JaCoCo test coverage reports. Additionally, it outputs the test coverage percentages to the workflow job summary. This example is based upon the approach I use in jacoco-badge-generator.

Check out all of our GitHub Actions: https://actions.cicirello.org/

I maintain several GitHub Actions, all of which are implemented in Python as container actions. This post explains how to test a GitHub Action using a GitHub Actions workflow, including using the workflow as a required check on Pull Requests. Although some of this post is specific to testing an action that is implemented in Python, much of the post is more generally applicable to testing actions regardless of implementation language.

The jacoco-badge-generator generates badges, but does not commit them. In this step, I just use a simple shell script to commit and push the badges. This step is conditional and runs only if the event that started the workflow is not a pull request (see the if: ${{ github.event_name != 'pull_request' }}). In other words, it runs on push and workflow_dispatch events. The coverage badges should be consistent with the state of the default branch, so committing badges that correspond to the coverage of a pull request that may or may not be merged doesn't make sense. If it is merged, the push event will then cause the workflow to run again, at which point the coverage badges will be committed. This step begins by changing the current directory to the directory where the badges branch was checked out. And it commits and pushes only if an svg or json file changed. The badges are SVGs, and recall the earlier step where I configured the jacoco-badge-generator to additionally generate a simple JSON file containing the coverage percentages.

There are two primary ways of implementing a GitHub Action: JavaScript Actions and Container Actions. The latter of which enables implementing Actions in any language via a Docker container. My language of choice for implementing GitHub Actions is Python. The purpose of most of these actions is to produce files (e.g., jacoco-badge-generator produces test coverage badges as SVGs, and generate-sitemap produces an XML sitemap) or to edit files in some way (e.g., javadoc-cleanup can insert canonical links and other user-defined elements into the head of javadoc pages). However, all of these also produce workflow step outputs. For example, generate-sitemap has outputs for the number of pages in the sitemap, and the number of pages excluded from the sitemap due to noindex or robots.txt exclusions; and jacoco-badge-generator has workflow step outputs for the coverage and branches coverage percentages if a user had some reason to use those in later steps of their workflow.

Vincent Cicirello - Open source GitHub Actions for workflow automation

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