Workflows with Github actions allow uncomplicated build workflows and thus a quick start into continuous deployment of containerized software.
The first part of this tutorial described a workflow with GitHub Actions that builds the Java build artifact and packages it into a container image on each push to a GitHub repository. This makes it possible to verify with each push whether a change to the code base breaks this build process.
This is especially useful when automated unit and integration testing is part of this process. However, this build workflow is not yet sufficient to continue working with the created container image and thus the tested revision of our application code.
- Software development: Getting started with GitHub Actions
- Workflows with GitHub Actions and container registries
- GitHub Actions: Automate repositories with just a few lines of code
- Getting started with Git and GitHub: How to implement your first projects
- GitHub CLI: How to use GitHub on the command line
Because GitHub Actions works by default with temporary runners, i.e. virtual machines that execute the workflow commands. These runners only have temporary memory where they store the built container image. Since no external sources can access it for security reasons, the container image must be temporarily stored in a different storage.