Skip to content

Latest commit

 

History

History
125 lines (84 loc) · 4.77 KB

build-app.md

File metadata and controls

125 lines (84 loc) · 4.77 KB
Raw

Building the application

Github Actions is configured through the YAML files.

💡 The trickiest part of writing the configuration files is typically getting the indentation right.

learning goals

  • Understand the basic structure of a workflow file
  • Understand the basic structure of a job
  • Understand the basic structure of a step

Building a CI pipeline in GitHub Actions

In this workshop we will be using a small java service which uses Gradle to build the application.

The application is found in the app directory, though the details of the implementation are not interesting for the purposes of these katas. There are a number of shell scripts that help with building the application, these are located in the ci directory.

The purpose of these katas is to use the small java application to exemplify how to use Github Actions to build, test and package your applications.

We ultimately want a pipeline that has the following jobs:

We are not going to do it all in one go, but rather step by step.

A basic example:

Now we want to diver a bit more into a pipeline.

Examine the following example, that makes the agent running the pipeline echo out "hello world":

name: Main workflow
on: push
jobs:
  Build:
    runs-on: ubuntu-latest
    container: gradle:6-jdk11
    steps:
      - name: Clone down repository
        uses: actions/checkout@v4       
      - run: ci/build-app.sh

A line-by-line explanation of the above:

  • Line 1: Specifies the name of the workflow, in this case, "Main workflow".
  • Line 2: Specifies that the workflow should be triggered on a push event.
  • Line 3: Introduces the jobs section where all job definitions reside.
  • Line 4-5: Defines a job named Build that runs on an Ubuntu VM.
  • Line 6: Specifies that the job should run in a container with the image gradle:6-jdk11.
  • Line 7: Defines the steps that should be executed in the job.
  • Line 8: A step named Clone down repository
  • Line 9: Uses the action actions/checkout@v4, to clone down the repository's content to the runner, enabling subsequent steps to access it.
  • Line 10: Runs the build-app.sh script found in the ci directory of the repository.

This workflow is a basic example that provides insights into the event type, branch reference, and repository structure when code is pushed to it.

If you want to see what build-app.sh is doing, look into the script.

Task

  • Replace the workflow you created in .github/workflows/main.yml with the above example.
  • Add and commit the file and push it to Github.
💡 Git commands to do it if you are using the terminal 
git add .github/workflows/hello-world.yml
git commit -m "Add hello world workflow"
git push
  • Go to Github Actions tab of the repository and check the action status.

Results

See that the build runs green and outputs this in the step log:

Run ./ci/build-app.sh

Welcome to Gradle 6.9!

Here are the highlights of this release:
 - This is a small backport release.
 - Java 16 can be used to compile when used with Java toolchains
 - Dynamic versions can be used within plugin declarations
 - Native support for Apple Silicon processors

For more details see https://docs.gradle.org/6.9/release-notes.html

Starting a Gradle Daemon (subsequent builds will be faster)
> Task :clean UP-TO-DATE

> Task :compileJava
Note: Creating bean classes for 3 type elements

> Task :processResources
> Task :classes
> Task :shadowJar

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.9/userguide/command_line_interface.html#sec:command_line_warnings

BUILD SUCCESSFUL in 28s
4 actionable tasks: 3 executed, 1 up-to-date

Summary

Congratulations, you have now build the java application!

But we have some way to go yet, we want to build a docker image, and run some tests on it as well.