jacoco-badge-generator
setup-java
Our great sponsors
jacoco-badge-generator | setup-java | |
---|---|---|
16 | 10 | |
88 | 1,394 | |
- | 3.7% | |
7.8 | 7.3 | |
23 days ago | 6 days ago | |
Python | TypeScript | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
jacoco-badge-generator
-
Automate Updating Major Release Tag on New Releases of a GitHub Action
I maintain several GitHub Actions, such as jacoco-badge-generator, generate-sitemap, javadoc-cleanup, and user-statistician. I've also written posts here on DEV about each of these if you'd like more information. GitHub's documentation for GitHub Action developers recommends maintaining a major release tag for the Action so that users can either reference the Action by its specific release tag, such as v1.2.3, or simply by the major release with v1. In fact, it is so commonplace that users will likely assume that your Action supports specifying full version tag or major tag only. Note that some Actions use major release branches (e.g., branch named v1) instead of tags. My intention in this post is not to discuss the advantages/disadvantages of each of these alternative approaches. In the Actions that I maintain, I use major release tags for the simple reason that it is what GitHub's documentation recommends.
Vincent Cicirello - Open source GitHub Actions for workflow automation
-
Bonus Tip: How to Use GitHub Actions to Test a GitHub Action Whose Output Must be Visually Inspected
Check out all of our GitHub Actions: https://actions.cicirello.org/
-
How to Test a GitHub Action with GitHub Actions
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.
We now need a way to detect if the results of the above integration tests are correct. The various actions that I maintain produce files (e.g., jacoco-badge-generator produces coverage badges, and generate-sitemap produces an XML sitemap) or edits existing files (e.g., javadoc-cleanup inserts canonical links and a few other things into the head of javadoc pages). In cases like these, I use Python's unittest module to validate the results. In this case, I define unit test cases in tests/integration.py that verify that the files produced by the action are correct. If any of those tests fail, then Python will exit with a non-zero exit code which will cause the workflow to fail.
-
How to Patch the Deprecated set-output in GitHub Workflows and in Container Actions
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.
-
The user-statistician GitHub Action mentioned in Awesome-README
Vincent Cicirello - Open source GitHub Actions for workflow automation
-
Badges - TL;DR for your repository's README
In some cases, there may be tools that you can run yourself as part of your CI/CD workflows. For example, last week I posted about the jacoco-badge-generator, which can be used as either a GitHub Action or as a local CLI tool to parse a JaCoCo coverage report, generate coverage badges, as well as for performing PR checks. Here is a link to that DEV.to post:
-
The jacoco-badge-generator GitHub Action is now also available as a CLI tool from PyPI
Check out all of our GitHub Actions: https://actions.cicirello.org/
The following example workflows demonstrate how to use some of the functionality. See the GitHub repository for complete documentation.
setup-java
- Disable Annotations in Github Actions
-
Using Github Actions to publish your Flutter APP to Firebase App Distribution
Then, we have two important initial steps to define. The first one is an official GitHub Action used to check-out a repository so a workflow can access it. The second one it's pretty more complex but, briefly, downloads and set up a requested version of Java.
-
Top 10 GitHub Actions You Should Use to set up your CI/CD Pipeline
The most popular ones are Node.js, Python, Java JDK, Go, .Net Core SDK.
-
My summary of jPrime 2022
Finally, note that the v2 of setup-java GitHub Action limits the possible JDK distributions to four options. If you need to use one that is not listed, use foojayio/setup-java instead to configure any distribution.
-
Github action to download and install Oracle JDK and OpenJDK (including EA) builds.
Why can't Oracle just integrate with https://github.com/actions/setup-java like everyone else?
-
Deploying to GitHub Pages using GitHub Actions
Next up we'll need to add a step to compile our production ready build. For this we can add two new steps, one which configures our Node version to ensure it matches our application, followed by another that runs the necessary commands with npm. Depending on how your application is built you may need to add another step between these to install any sort of required environments such as Python or Java.
-
JaCoCo coverage badges, PR coverage checks, and PR coverage comments, from GitHub Actions
Set up the JDK with the actions/setup-java GitHub Action.
-
Hosting Kotlin/JS on GitHub Pages via GitHub Actions
The Kotlin compiler needs Java to be present, so we use a predefined GitHub Action to install Java 1.8.
What are some alternatives?
upload-artifact
checkout - Action for checking out a repo
Chips-n-Salsa - A Java library of Customizable, Hybridizable, Iterative, Parallel, Stochastic, and Self-Adaptive Local Search Algorithms
cicirello - My GitHub Profile
gcovr - generate code coverage reports with gcc/gcov
aoc-badges-action - Github Action to update the badges of your Readme to show your current Advent of Code stats
fetch-api-data-action - 🚚 GitHub action for handling authenticated API requests, allowing you to save the data from the request into your workspace as an environment variable and a .json file.
generate-sitemap - Generate an XML sitemap for a GitHub Pages site using GitHub Actions
Firebase-Distribution-Github-Action - This action uploads artifacts (.apk or .ipa) to Firebase App Distribution.