Coffee break #102. Packaging Java Applications with Maven and GitHub Actions

Source: Dev.to This post shows how to create workflows that package a Java application using Maven and then save it as an artifact or publish it to GitHub Packages.

Development environment

You can find the source code repository at the link provided here . This is a simple Spring Boot application that retrieves student names from a database. The application bootstraps using Spring Initializr. For dependencies, we have added Spring Web, which is used to build web applications using Spring MVC. This package also uses Apache Tomcat as the default built-in container. We also used Spring Data JDBC to persist data to SQL using simple JDBC, and the PostgreSQL Driver, which allows Java applications to connect to a Postgres database using standard, database-independent Java code. For local development, we can start a Postgres instance with Docker using the following command: Spring Boot follows a layered architecture where each layer interacts with a layer directly below or above it. We followed this practice and implemented the Controller, Service and Repository inside our application and demonstrated the principles of dependency injection. The source code also contains the StudentConfig class, which simply inserts the student into the database. After successfully setting up the development environment and writing some code, we decided to move our work to a source code control system, in this case GitHub. Now we need to build the code and publish it as a Maven package. This process can be done manually, but we would like it to be done automatically when changes are made to the main branch. This way we avoid manual tasks when publishing a new version. Like most other things, this problem can be solved in several ways, and we will use two different approaches. First, we will publish our package as a build artifact and make it available for download, and in the second approach, we will publish the package to the GitHub Packages Maven repository .

Storing workflow data as artifacts

In the main.yaml file , the first few lines tell us which events trigger the workflow. In addition to the push and pull requests on the master branch, we've also added the workflow_dispatch tag , which allows you to start the workflow manually. In the Jobs section, we have defined a build job that will run in the Ubuntu runtime. The first two steps check out the master branch from GitHub and set up the JDK (Java Development Kit). Next, we create a project and set up a cache for Maven: After the build is complete, the staging directory will contain the generated .jar file. Each job in the workflow runs in a new virtual environment, which means that once we run the build job , we can't access that environment and our .jar file will be gone. That's where our final step comes in, which loads the artifacts from your workflow, allowing you to share data between jobs and save data after the workflow completes. By default, artifacts generated by workflows are kept for 90 days and then automatically deleted. You can set the retention period depending on the repository type. When you set a retention period, it only applies to new artifacts and is not retroactive to existing items. Artifacts can be found under the Actions tab by clicking on the desired workflow start.

Publishing to GitHub packages

You can configure Apache Maven to publish packages to GitHub Packages and use packages stored in GitHub Packages as dependencies in a Java project. In addition to Maven, GitHub Packages offers various package registries for commonly used package managers such as npm, NuGet, Gradle, and RubyGems. You can also store Docker and other OCI images. With all these features, you can build end-to-end DevOps solutions and centralize software development on GitHub. In the maven-publish.yaml file , you can find the workflow details for publishing a package to GitHub Packages. As in the previous solution, we specify the name and events that will start the workflow. Then, in the jobs section, we selected Ubuntu runner as the environment for the publish joband defined permissions to read content and write packages. In the following steps, we check out the master branch and configure the JDK with the java-version option . The last step is to publish the package, for this he needs a personal access token for authentication. PAT is sensitive information and we don't want to store it in plain text, so we defined the secret at the repository level and accessed it as an environment variable. For simplicity, we skipped tests during deployment. Before running the workflow, we also need one configuration change in the application's source code. Inside the pom.xml file , we need to pass information about package distribution management. After making changes to the master branch, the workflow starts automatically and we can monitor the log output in the Actions tab of the repository page. When all the steps are completed, we will see a ready-to-use Maven package in our code repository under the Packages section. Using these two approaches, we successfully solved the problem of automatically publishing Java applications as Maven packages and demonstrated how to use GitHub Actions and GitHub Packages to create a complete end-to-end development solution in one place.