GitHub Actions key points

GitHub Actions is one of the fastest-growing CI/CD platforms. It allows for easy automation of your build, test, and deployment pipeline all within the space of your repository with little or no overhead of maintaining plugins and servers. It can be accessed from the GitHub Actions tab.

After a workflow is created, a .github/workflows path will exist in the repository. This is the path where the GitHub Action file is stored. The GitHub Action is YAML-based, and when triggered, it runs one or more jobs that consist of a set of steps.

GitHub Action terms

1. Workflow: The YAML file found in the .github/workflows directory in a repository. A repository can have more than one workflow file.
2. Event: An action that triggers the workflow to run, e.g., on pull request, push.
3. Runner: Workflows need to run on machines. Runners are machines or containers that execute the workflow.
4. Job: A set of steps that run on a specified runner. By default, the jobs run parallel with each other unless specified in the workflow.
5. Secrets: Generally encrypted variables that are called during the execution of a workflow. They ensure that passwords or sensitive credentials are not hard-coded.

6. Marketplace: This is like the Apple Store for GitHub Actions, where you can find actions that you can incorporate into your custom script.

The script below is an example of a GitHub Action script. Custom scripts on the marketplace help increase automation, thereby reducing build time.

name: Java Build

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Set up JDK 17
        uses: actions/setup-java@v3
        with:
          java-version: '17'
          distribution: 'temurin'
      - name: Build with Maven
        run: mvn --batch-mode --update-snapshots package

Some use cases of GitHub Action are listed below:

1. Building Java and Node.js packages.
2. Adding semantic version tags and releases to your packages based on the commit message. Click here to find out more information about the Conventional Commits specification.
3. Building Docker images and pushing them to Docker Hub.
4. Checking your code for errors and running static code analysis using GitHub linter and SonarQube integration.
5. Deploying to Kubernetes clusters.