You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

GitHub is a well-known platform hosting thousands of source-code repositories.

Besides, it also provides issue tracking and basic project management capabilities.

More recently, GitHub provided the ability to automate workflows using GitHub Actions.

With GitHub Actions, it's possible to implement CI/CD directly in GitHub and reuse already available actions from GitHub Marketplace to automate steps .

An introduction to GitHub actions can be seen here.

Main concepts

In a nutshell, workflows are automated processes described as YAML files, stored under .github/workflows.  These are usually triggered by events (e.g. code-commit, pull-request) or can also be scheduled.

One or more workflows can be defined. Each workflow is in turn composed by one or more jobs, that can run sequentially or in parallel. A job performs a set of sequential steps to achieve a certain goal. A step is an individual automation task; it can be either an action or simply a shell command. 

An action abstracts some automation task; it can be named and versioned. Actions can be implemented directly in Javascript or as Docker containers. GitHub also supports composite actions built of multiple inner steps.

Actions and workflows can be stored in the local repository; actions can also be published in the GitHub Marketplace.


Each time a workflow is triggered, a workflow run is created; it contains a specific context.  Each job in the workflow uses a fresh virtual environment (e.g. ubuntu-latest) sharing the same virtual file system.

Accessing and sharing data

A job can generate output variables that can be used by another job that depends on it.

There are also typical environment variables available at workflow, job or step level. GitHub fills out some environment variables by default.

It's also possible to access secrets, defined in GitHub project settings, as environment variables or as a step input.

Another way of sharing data, especially between jobs, would be to produce and store artifact(s) in a job and obtain them in another job.

Examples

Basic JUnit example

We’ll use the actions/checkout action to checkout the code from our repository to the virtual environment.

This action is one of the "standard" actions provided by GitHub; full list here. The same for actions/setup-java.


basic maven project
name: example4a
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
        
    steps:
    - uses: actions/checkout@v1
    - name: Set up Java
      uses: actions/setup-java@v1
      with:
        java-version: '1.8+
    - name: Build with Maven
      run: mvn clean compile test --file java-junit-calc/pom.xml


References

  • No labels