Skip to content

formation.md

Latest commit

 

History

History
206 lines (132 loc) · 7.4 KB

formation.md

File metadata and controls

206 lines (132 loc) · 7.4 KB

Github Actions

Introduction

General concepts

GitHub Actions is a continuous integration (CI) platform for GitHub-hosted projects, launched on 16 October 2018.

About continuous integration

Continuous integration (CI) is the practice of short-lived development cycles, automatically tested and shared regularly between developers involved in a project.

Continuous integration platforms, such as Github Actions (among many others; for instance, at Inria, we have ci.inria.fr) have been developed to help automating testing.

Automating testing (and CI in general) relies on version control and automated builds. Together, these technics speed up development process, ease collaboration and allow programmers to be more confident for not introducing regression and bugs.

This is a step towards broader goals such as reproducible builds and reproducible research.

Once the infrastructure is here for automating build and tests, the same infrastructure can be used for automating release process (continuous delivery, CD) and deployment (continuous deployment, also abbreviated CD: the nuance is that continuous delivery automatically ensures that a release is always ready to be deployed, and continuous deployment automatically deploys the release). The whole approach is abbreviated CI/CD.

About version control

Version control systems are software dedicated for managing history and collaborative edition of source code or any other kind of documents. The prominent software for version control is now git, initially developed in 2005 by Linus Torvalds to manage the Linux source code.

Even if git was initially thought, and can still be used as a decentralized tool (where versions are directly exchanged between peers), most uses of it now rely on software forges, like [GitHub] or gitlab.inria.fr for instance, which provide a central place, against which the programmers synchronize their code. Software forges provide other services related to version control, such as CI/CD facilities.

Keeping the history of a code is central to make change in the code without losing information and to identify where regressions have been introduced (in particular, automated tests enable automatic bisection). Moreover, version control systems like git allow code to be modified concurrently by offering merging facilities (three-way merge).

GitHub actions platform

Self-hosted runners

machines fournies/self-hosted runners, dépendances entre jobs (graphe), status (commit, PR), artéfacts

Comparison with GitLab Pipelines

(introduced in GitLab 8.8.0, on 22 May 2016)

  • Continuous integration system integrated in GitLab. gitlab.inria.fr provides shared docker runners, ci.inria.fr can host user-maintained VMs, and self-hosted GitLab runners can be registered.

  • File-based workflow specification: .gitlab.yml. A command-line tool, gitlab-ci-local is available for running workflows locally (or from other continuous integration platforms): https://github.com/firecow/gitlab-ci-local

  • The supported YAML syntax is richer than GitHub Actions (support for anchors, extends and file inclusion to reuse parts of code), but there is no built-in supports for reusable actions comparable with what GitHub Actions proposes.

Docker and registry

About docker

Running jobs in a container

Build environments can be prepared once for all in a Docker image to reduce build times:

  • docker build -t ghcr.io/‹user›/‹image name› .

  • create a personal access token with scope write:packages, save it in a file

  • docker login ghcr.io -u ‹user› --password-stdin < ‹token path›

  • docker push ghcr.io/‹user›/‹image name›

  • create a personal access token with scope read:packages, store it in a secret (using gh secret set)

  • reference the container in the job

    container:
      image: ghcr.io/‹user›/‹image name›
      credentials:
        username: ${{ github.actor }}
        password: ${{ secrets.‹secret name› }}
  • to run the workflow locally, use act --secret-file ‹file name›

Use a job to build the environment

  • Store a personal access token with scope write:packages in a secret.

  • Check out the repository! Add the following action

      - name: Checkout
        uses: actions/checkout@v3
  • Steps for docker build and docker push.

⚠️ checkout action wipes out the current directory! Should be run before any actions writing useful things in it (local setup, etc.).

Continuous Delivery/Continuous Deployment

Continuous Delivery: Preparing new releases

Continuous Deployment: Pushing on pypi

Publishing documentation

      - name: Deploy
        uses: JamesIves/github-pages-deploy-action@v4
        with:
          folder: build

https://github.com/actions/toolkit/blob/main/docs/commands.md

https://github.com/actions/toolkit/blob/main/docs/problem-matchers.md ::add-matcher::

https://github.com/marketplace/actions/gcc-problem-matcher