This lesson is still being designed and assembled (Pre-Alpha version)

Continuous Integration and Continuous Delivery

Introduction

Overview

Teaching: 3 min
Exercises: 0 min
Questions

  • What is CI/CD?

  • Why is CI/CD useful for me?

Objectives

  • Know what CI/CD is

  • Understand the benefits of using CI/CD.

CI/CD

Leaving documentation and testing for a ‘finished’ product is generally a bad idea. Development could be seen more as gardening than creating a building; it is never finished. This means development should be done in small increments; develop small features, document and test them and commit these small changes each time. In most cases it is also beneficial to release code many times and allow users to work with and give feedback to your changes often. Developing in such a way would be time consuming if we had to manually test, build and deploy the application each time. This is why CI/CD is important. CI/CD stands for Continuous Integration / Continuous Deployment (or Delivery depending on who you ask). The goal of CI/CD is to automate all these processes so that apps can be continuously tested, built and deployed without any manual effort. This ensures that the code is constantly in a state where it is documented, tested and available for others to review and use.

Key Points

  • CI/CD automates as much as possible outside of core development tasks.

  • CI/CD allows for a more iterative way of testing, using and working on your application.

Setup Git repository

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • What do I need to think about when creating a new repository on GitHub?

Objectives

  • Know how to setup a GitHub repository according to IDS standards.

  • Understand which license to add to your repository.

  • Understand the benifits of templates and how they differ from forking/cloning.

  • Understand how to allow the different levels of access to your repository.

Introduction

Setting up a GIT repository should always be the first step for any software related project. For the many advantages of using GIT check here. While there are many options for hosting your repository, the default choice at IDS is GitHub. Some of the advantages of using GitHub are features like free processing power, free artifact hosting, a large community and having all IDS repositories searchable under the same organisation. When first setting up a GitHub repository, there are a number of things to consider:

GitHub templates

GitHub templates are a quick way to start your application with the scaffolding already in place. This can save a lot of time as you don’t have to worry about setting everything up. This could also be achieved by forking a repository. However forking is meant more for collaborating on the original repository. In the case of using a template you will not include the entire commit history of the original project for example. It’s a fresh start as if you had simply copy pasted the code into a fresh repository. At IDS we are developing a number of templates ready to use for Python, Java and React websites.

Note that there are many generic solutions to ‘scaffold’ your application when starting a new project. For Python, https://github.com/cookiecutter/cookiecutter is a popular solution.

Create a repository from template

  • In GitHub, Use the + icon to create a new repository. Creating a Repository
  • Choose the MaastrichtU-IDS/workshop-ci-template from the repository template dropdown. Selecting a Template
  • Select MaastrichtU-IDS as the owner of the repository.
  • Add a name and description to your repository and set the access to private.

Repository permissions

GitHub differentiates between 5 different types of access:

Check here for a detailed overview. In almost all cases, using the read or write permissions will suffice and should be considered first. To save time, GitHub allows organizations to create teams of usersfor which permissions can be handled in one go.

Configure repository permissions

  • Under settings for your repository, go to Manage access.
  • Click Invite teams or people.
  • Add the MaastrichtU-IDS/developers team and provide them with Write access.
  • Add the MaastrichtU-IDS/admins team and provide them with Admin access.

Adding a license

Adding a license is mandatory as no one is allowed to legally use your code if no license is included.

It is therefore customary to add a LICENSE or LICENSE.txt file to the root of your repository. There are many different existing licenses that can be reused. Unless you are a lawyer, you should never write your own license. Check https://choosealicense.com to see which license fits your project best.

Of course this decision should be made together with all collaborators if the project spans multiple institutions.

As a default at IDS we advise using the MIT license 📜, which allows anyone to use the code in any way they see fit (even selling it or making their version closed source), but also makes clear you are not responsible for any damages that may be incurred by using the code.

Configure repository permissions

Solution

Apart from the MIT license, other popular Open Sources licenses includes:

  • Apache 2: similar to the MIT license, but more detailed, it requires to list changes made to the original software, and introduce restrictions related to trademark use. You might want to consider this license for bigger and more structured projects.
  • GNU GPL v3: a “copyleft” license, it includes restrictions about which license you should use when using a GPL licensed code. Typically, a GPL licensed project requires other projects using their code to be open source.

Using SSH

SSH keys provide an easy way to access your GitHub repositories without having supplying your username and password every time. This is done by generating a keypair, publishing the public key on GitHub and storing the private key locally on your machine.

Clone repository using SSH

  • Follow the instructions to generate a keypair for your operating system.
  • Follow the instructions to upload the public key to GitHub.
  • In your repository, click Clone or Download and make sure Clone with SSH is selected.
  • Copy the url to your clipboard and in a terminal perform git clone URL in the path of your choice. The name will be set to the repository name by default.

Key Points

  • When creating a GitHub repository keep permissions in mind.

  • Templates are a quick way to scaffold your application.

  • Don’t create your own license.

Run application locally

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • How do I develop my application locally before starting with CI/CD?

Objectives

  • Testing the application before trying to run it in Docker.

  • Continuous improvement of the readme.md

Running the Python application

Before starting with CI/CD we will first check the application works correctly locally. The Python template comes with a setup.py file which allows an easy pip install of our application. Since performing pip3 install . each time we make a change can be tiresome, the -e argument can be added to pip install, to automatically reflect any change you make to the application directly in the environment.

In our setup.py, a good practice is to use requirements.txt to keep track of the dependencies of our application that need to be installed. These can then be installed using the setup.py or manually running pip3 install -r requirements.txt.

Running the application

  • Run pip3 install -e .
  • Run workshop_ci hello-world --help to see how to run your application.
  • Run the application with the correct inputs.

Writing and running tests

There are many different kinds of tests which can be run for your application. Two of the most important are functional testing and unit testing. Functional testing is relatively straightforward. The application is assumed to be a black box, and the desired output is checked based on various inputs. Unit testing tests whether a ‘unit’ of code behaves as expected. When the code is divided up functionally into small methods, we can test these individually to see if they output the correct values for a number of inputs. Whenever someone makes a change to the method (or anything the method relies on), the unit test can be run to check everything is still as expected.

It is important to realize that no amount of testing or covering your code with unit tests will guarantee that it works. It is only possible to get some degree of confidence. How many tests you write is dependent on the required quality, the number of people working on your project and how much long term development you expect will be done. A large enterprise application developed by a company will require much more testing than a prototype created by a single developer.

In almost all cases, tests are run automatically during the CI/CD process. If you should want them locally you can do so by performing the following steps.

Testing the application

  • pip3 install pytest
  • pytest tests/

Adding documentation

Continuousy adding documentation is vital for others to make sense of your code. At IDS, we prefer to use the README.md for development related documentation. Open features and bugs can be added to GitHub issues. For more general information on the software the GitHub wiki can be utilized. Project documentation is done in the IDS teams folder on Google Drive.

Adding documentation

  • Add the steps to run and test the application to the README.md.

Updating the repository

Commit and push changes

  • Use GIT to commit and push your local changes.

Key Points

  • Write an appropriate amount of tests for your purpose.

  • Make sure to update your readme.md intermittently during development.

Create a container image with Docker

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • What are the advantages of using Docker?

  • How do I use Docker to package my application?

  • How do I share my Docker Images with my colleagues?

Objectives

  • Know how to run Docker containers locally.

  • Understand how Docker images are shared and reused.

  • Know how to push images to a Docker repository.

  • Understand why Docker container orchestration is useful.

`

Introduction

Docker is the foundation of most modern CI/CD solutions. Your application can be added to a Docker container which acts as a kind of super-lightweight virtual machine. Any further build steps can then be performed inside this container. For more in-depth information on Docker see this workshop.

Creating a Docker image

A Docker image is a blueprint for the container you want to create. Images can stored locally or on any Docker repository such as DockerHub. Images can then be pulled by different actors to run code in the exact same environment. In order to use the image, the actor creates a container from the image, which is an instantiation of the image.

In order to create a Docker image, a Dockerfile is used to provide build instructions for the image (Check the d2s documentation for more information). One such instruction for example is adding environment variables to your container.

#ARG variables are only used during the building process. They will not be available in the container. ```
#ENV sets an environment variable in the container.
ARG APP_NAME=ci_workshop
ENV APP_NAME=${APP_NAME}
ARG HOME="/app"
ENV HOME=${HOME}

Ofcourse we also need some way to add our application to the container. By using ADD, files can be copied from your machine into the image. There are some conventions to keep in mind when doing this. The app itself should be copied to the /app directory in a subfolder with its name. Data for the app should be added to .. FIXME: fix / add more conventions? Configuration should be by mounted using a volume. A volume is shared between the host machine and the container, so that when the configuration is changed on the host it takes effect in the container. For more information on volumes, see here and here. For now we will not be using any configuration.

#The binary folder is added to the path variable, so that any command in it can be run without specifying the path.
ENV PATH $PATH:${HOME}/${APP_NAME}/bin

#Sets the working directory to the folder mentioned. All further commands will be run from this path.
WORKDIR ${HOME}

#ADD adds everything in the folder mentioned first to the path in the container specified as the second parameter.
ADD requirements.txt requirements.txt
ADD . ${HOME}/${APP_NAME}

Lastly we need some way to run commands in our container. This is done by using RUN. For a Python container, we can use this to install some dependencies and the module itself.

#RUN runs a command in the Docker container.
RUN pip install --upgrade pip
RUN pip install -r requirements.txt
RUN pip install -e ${HOME}/${APP_NAME}

FIXME: add some comments on good practices for order of dockerfile contents.

Create a Docker Image

  • In the root of your repository, open Dockerfile.
  • Start your Image from an existing image with Python already included by adding dockerfile FROM python:3to your Dockerfile.
  • Add the first code snippet above to your Dockerfile to setup the image environment.
  • Add the second code snippet above to your Dockerfile to add contents from your repository to the image.
  • Add the third code snippet above to your Dockerfile to install your Python modules in the image.
  • Create your image by running docker build . -t ci-workshop.
  • Confirm the creation of your image with docker image ls.
  • Add the build instructions to the README.md.

Running a Docker Container

After the image is created we can create a container from it and run a command inside it. While docker create [OPTIONS] IMAGE [COMMAND] [ARG...] creates the container, we can also use docker run [OPTIONS] IMAGE[:TAG|@DIGEST] [COMMAND] [ARG...] to create the container just as the create command, and afterwards runs it. It then performs the specified command inside the container.

Run a Docker Container

  • Create and run your application inside a container based on the image created earlier.

Sharing Docker images

When a Docker image is created, it is at first stored locally. To share images with others, Docker Repositories can be hosted on dockerhub. After pushing an image, others will be able to pull from the same repository. Note that with a free organization plan all docker repositories are public. Images are stored by supplying a repository id and a tag. If no tag is supplied, the image will default to the latest tag. latest does not have any special meaning, but the convention is to use this tag for the latest version of the image. In a build process for example, you may decide to tag the image twice; once with a specific version number and once with latest to overwrite the current latest image.

Push Docker image to dockerhub

  • Sign up for a Docker ID
  • Ask an administrator (t.hendriks@maastrichtuniversity.nl for example) to be added to the IDS organization developers team on dockerhub.
  • Under the Repositories tab, select the umids organization and Create Repository. Creating a Docker Repository
  • Provide a Repository name (name should be equal to the repository id of your created image) and description while leaving the other values on their defaults. Create the repository.
  • In a terminal, use docker login to login to your docker account.
  • Use docker push umids/REPOSITORY_NAME:TAG_NAME to push your image to dockerhub.
  • Check your repository on dockerhub to see your hosted image.

Orchestrating Containers

One of the strengths of using Docker containers is using containers created by others and combining them with your own containers. For example, for most applications rather than manually installing a database and multiple applications you can simply pull and run a couple of containers created by the third party. In such cases (or ofcourse when you’ve created many images yourself) the need arises to configure for multiple images at a time, and ‘link’ them by having them share networks and expose ports. There are a large number of solutions of varying complexity to handle things such as container networking and configuration. At IDS, for simple solutions Docker Compose is used. For more complex and/or production ready solutions IDS hosts an Openshift cluster, which leverages kubernetes. We will explore these concepts in later workshops.

Update the README.md

  • Add the docker commands to the README.md

Updating the repository

Commit and push changes

  • Use GIT to commit and push your local changes.

Key Points

  • Docker solves ‘it only runs on my laptop’ issues.

  • Docker images can be reused to share container blueprints.

  • Sharing Docker images saves time recreating work and environments

Automate tests using GitHub Actions

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • How do I make sure I do not package and publish broken code?

  • How can I run my tests automatically without even realizing it, for free, on someone else machine?

  • How do I keep track of the tests results?

Objectives

  • Create a GitHub Actions workflow to run your package tests at each push to the master branch.

  • Add a badge to the README file to notify if the last test run passed.

Now that your application can be run locally and built as a Docker image we will want to automate running the tests, so that the test suite that has been defined is run at every push to the master branch on GitHub. This will allow you to automatically know if the last changes you did broke features for which you wrote tests.

GitHub Actions limitations and billing

GitHub Actions workflows will be run on a GitHub-hosted runner (on their servers). Note that you can also define an action to run on a server or on your local machine by installing a self-hosted runner. In this workshop we will only use the GitHub-hosted runner for convenience, but feel free to install a self-hosted runner to overcome GitHub limitations.

The following limitations apply to GitHub-hosted runner (they do not apply for self-hosted runners):

  • Each job in a workflow can run for up to 6 hours of execution time.
  • Each workflow run is limited to 72 hours.
  • Total concurrent jobs for the free plan: 20 jobs (5 macOS)

GitHub-hosted runners run on machines with the following specifications:

  • 2-core CPU
  • 7 GB of RAM memory
  • 14 GB of SSD disk space
  • Environments: ubuntu-latest (a.k.a. ubuntu-18.04), ubuntu-20.04, windows-latest, macos-latest

GitHub Actions is free for Open Source repositories 💸

If you create a public repository you don’t need to be careful with the execution time and storage you are consuming.

GitHub free plan allows to run Actions in private repositories, but impose execution time and storage limitations. By default GitHub set your spending limit to 0 €, so you will not be billed by surprise. The free plan provides the following credits per months, they are attached to the user or organization owning the repository running the workflows:

  • 2,000 minutes of execution time (~33h)
  • 500 MB of storage (for private artifacts and GitHub Packages)

We recommend to use Linux runners, as jobs that run on Windows and macOS runners consume minutes at 2 and 10 times the rate that jobs on Linux runners consume.

Note that if your project hosts its code on GitLab, we recommend to use GitLab CI. Which works with mechanisms similar to GitHub Actions.

Since this project is be open source we don’t need to worry about spendings 💸

Generate the GitHub Actions workflow

  • Go to the Actions tab (next to Pull requests) in your GitHub repository.
  • Choose the “Python package by GitHub Actions” starter workflow.

Creating a workflow

  • It will generate a python-package.yml workflow with common steps to test a Python package.
  • You should now be able to edit the workflow generated in GitHub web interface.

Inspect the generated workflow

At the moment the workflow generated by GitHub fits our needs, so we will not need to change it a lot. Here is a breakdown of the generated file:

on:
  push:
    branches: [ master ]
  pull_request:
    branches: [ master ]

The workflow will be triggered when a push or a pull request is made to the master branch.

jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: [3.5, 3.6, 3.7, 3.8]

Runs the job named build on Ubuntu, and prepare to test on Python version 3.5 to 3.8.

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python $
      uses: actions/setup-python@v2
      with:
        python-version: $

Starts defining the steps of the build job:

  • actions/checkout get the latest version of your repository source code in the job working folder.
  • actions/setup-python will install the given Python version in the job. Here we use matrix.python-version defined in the previous step, in this case GitHub will run 4 times this job, for each version specified in the matrix.
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install flake8 pytest
        if [ -f requirements.txt ]; then pip install -r requirements.txt; fi

Once Python is setup in the job, the dependencies are installed:

  • Upgrade pip
  • Install flake8 and pytest
  • Install packages defined in `requirements.txt
    - name: Lint with flake8
      run: |
        # stop the build if there are Python syntax errors or undefined names
        flake8 . --count --select=E9,F63,F7,F82 --show-source --statistics
        # exit-zero treats all errors as warnings. The GitHub editor is 127 chars wide
        flake8 . --count --exit-zero --max-complexity=10 --max-line-length=127 --statistics

This step runs flake8, it will check for syntax errors in your Python code, and reports in the job logs where you are not following Python styling conventions (which is not mandatory).

Edit and commit the GitHub Actions workflow

  • Replace the step:
- name: Test with pytest
  run: |
    pytest
  • By this one, which runs the tests using your setup.py configuration:
- name: Test with pytest
  run: |
    python setup.py pytest
  • You can now click Start commit to publish the workflow.
  • The workflow file is stored in the GitHub repository at .github/workflows
  • Do a git pull in the repository on your local machine to retrieve the workflow file.

We will finally add a status badge to the README to conveniently monitor and share the results of the latest tests.

Add status badge

  • Go to the Actions tab of your repository on GitHub.
  • Go to your Python package workflow.
  • Click on the Create status badge button (on the right of the screen)
  • Add the markdown to your project README.md

Key Points

  • GitHub provides a lot of relevant templates for common workflows.

  • Make sure to install the tests requirements in the GitHub job before running the tests.

  • Generate a status badge with GitHub to show if the tests passed directly in your README.

Automate Docker build with GitHub Actions

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • How do I build and publish a new release of my application?

Objectives

  • Build a Docker image and push it to DockerHub if the tests pass.

  • Only build and push when a new release is published,.

You can add a job to your GitHub Action workflow which will automatically build the Docker image and push it to DockerHub if the tests pass.

Build and push Docker image

  • Find the Build and push Docker images action on the GitHub Marketplace: https://github.com/marketplace
  • Use the action to automatically build and push a Docker image with tag latest if the tests pass. Do the build in a new job named build. Use the Example usage section in the action readme.
  • You can safely store your DockerHub username and password using secrets.
    • Go to the ⚙️ Settings tab of your GitHub repository
    • Go to Secrets in the left navbar.
    • Create 2 secrets that will be used by the GitHub Actions workflow: DOCKER_USERNAME and DOCKER_PASSWORD 🔒

Once a secret has been defined no one (not even you) can read it 🙈, you can still override it though.

Solution

name: Test and publish to DockerHub
on:
  push:
    branches: [ master ]
jobs:
  test:
    [...]
  
  build:
    needs: test
    runs-on: ubuntu-latest
   
 steps:
       - uses: docker/build-push-action@v1
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}
        repository: myorg/my-repository
        tags: latest

It is recommended to avoid rebuilding and publishing a new image at every new push to master. We will now set the build and push job to only be triggered if a new release is created on GitHub (a.k.a tag 🏷️)

Build and push image only when release

  • Add a condition to only push to DockerHub when a release is pushed
  • Use the GitHub tag to tag the DockerHub image
  • 2 solutions are available for this case:
    • using a if condition in the GitHub workflow (recommended)
    • use a parameter provided by the “Build and push Docker images” action.

Solution

name: Test and publish to DockerHub
on:
push:
 branches: [ master ]
jobs:
test:
 [...]

build:
 if: startsWith(github.event.ref, 'refs/tags')
 needs: test
 runs-on: ubuntu-latest

 steps:
    - uses: docker/build-push-action@v1
      with:
        username: ${{ secrets.DOCKER_USERNAME }}
        password: ${{ secrets.DOCKER_PASSWORD }}
        repository: myorg/my-repository
        tag_with_ref: true

Key Points

  • Use the official GitHub Action from Docker.

  • Set sensible informations, such as passwords, in GitHub Secrets.

Automate the publication of your package using GitHub Actions

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • What do I need to think about when creating a new repository on GitHub?

Objectives

  • Know how to setup a GitHub repository according to IDS standards.

  • Understand the benifits of templates and how they differ from forking/cloning.

  • Understand how to allow the different levels of access to your repository.

The best way to make your application FAIR (Findable Accessible Interoperable and Reusable) is to publish it as a package in a popular repository. In the case of Python packages, the reference repository is PyPI (pronounce Pie-Pea-Eye).

You just need to register providing a valid email address and a username, then the project will be automatically created in PyPI, and you will be set as its owner if the chosen project name has not already been taken.

Automatically publish to PyPI

  • Add a new job named publish. Similarly to the build Docker job, this job will be triggered only if a release/tag is pushed.
  • Use the template Publish Python Package provided by GitHub in your repository Actions tab (which uses twine).
  • Define PYPI_USERNAME and PYPI_PASSWORD Secrets 🙈

Solution

  publish:
    if: startsWith(github.event.ref, 'refs/tags')
    needs: test
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python
      uses: actions/setup-python@v2
      with:
        python-version: '3.x'
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install setuptools wheel twine
    - name: Build and publish to PyPI
      if: startsWith(github.event.ref, 'refs/tags')
      env:
        TWINE_USERNAME: ${{ secrets.PYPI_USERNAME }}
        TWINE_PASSWORD: ${{ secrets.PYPI_PASSWORD }}
      run: |
        python setup.py sdist bdist_wheel
        twine upload dist/*

Publish a new release

  • Publish a new release to trigger the newly created publish job and publish the first version of your package! 🏷️

Add version badge

  • Add a badge getting the latest version from PyPI to your project README.md
![Version](https://img.shields.io/pypi/v/my-package)

Key Points

  • Use template provided by GitHub.

  • Set PyPI credentials in GitHub Secrets.

  • Add a version badge to display the latest version available on PyPI in your README.

Add a new feature and create new release

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • How do I publish a new version of my package?

Objectives

  • Increase version number.

  • Create new release.

Now that you have published a first version of your package you might want to edit it and publish a new version:

Key Points

  • Just do not mess up the version number change.

Complete and publish the documentation

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • How can I publish documentation for my application?

Objectives

  • Know how to setup a GitHub repository according to IDS standards.

  • Understand the benifits of templates and how they differ from forking/cloning.

  • Understand how to allow the different levels of access to your repository.

Depending on the size of your application and your use-case you can choose between various options. All the options proposed here are using the Markdown format (the format used by the README.md)

Create a simple README.md

  • Complete it with relevant informations you want the user of your application to see first (install, usage, etc)

Transform your README.md in a simple GitHub Page

  • Choose the best template to display your documentation. We recommend Cayman (clear and wide main page), XXX (generates outline using ## Title 2 and ### Title 3)

Create a GitHub Wiki for more details

  • Create an install page
  • Create a “How to cite” page
  • Add sidebar and footer

Create a Gitter chat room

Gitter is a service from GitLab which allows to easily create and use public and private chatrooms linked to GitHub repositories. Users can easily connect using their GitHub or GitLab account.

  • Login to Gitter using your GitHub account
  • Access the workshop Gitter chat room (TODO?)
  • Post a message
  • Check an issue in the activity sidebar

Automated and embedded Python documentation with MkDocs

MkDocs is a library to generate and maintain documentation for your Python project.

The generated documentation goes to docs/

Complete documentation website using Docusaurus

For large project you might want to build a complete documentation website with a fancy landing page and dozens of documentations pages written in markdown and ordered in categories.

We recommend to use Docusaurus from facebook Open Source. Docusaurus is built with React and allows you to deploy a documentation website based on markdown file. Pages, like the landing or help page, can be more customized using simplified JavaScript/React templates.

Docusaurus provides scripts to easily deploy your website to GitHub or GitLab Pages, or using Docker.

Get started in a few minutes at https://github.com/facebook/docusaurus

Complete documentation website with readthedocs

Another popular solution to publish documentation is Read the Docs.

Key Points

  • No one wants to read your dirty code to understand how to run your application, not even yourself in 2 months.

  • So please publish a short, but exhaustive documentation about how to deploy and use your application.

Create a GitHub Action for your package

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • How can I use the application I just packaged as a GitHub Action?

Objectives

  • Create a separate repository to define your action

  • Write action.yml and README.md

  • Publish to the GitHub Marketplace.

Example: https://github.com/vemonet/sparql-operations-action

Might be a bit too advanced at the moment and not that relevant: people at IDS don’t need to publish their applications as GitHub Actions. We could just mention they can do it and propose pointers

Create a repository from template

  • first step

Configure repository permissions

  • first step

Configure SSH

  • first step

Key Points

  • When creating a GitHub repository keep permissions in mind.

  • Templates are a quick way to scaffold your application.

Continous Deployment (CD) using GitHub Actions

Overview

Teaching: 1 min
Exercises: 1 min
Questions

  • How do I deploy a service in production using a GitHub Action?

Objectives

  • Show an example of deployment to GitHub Pages.

  • Show an example of deployment to Firebase

  • Show an example of deployment using a self-hosted runner

TODO:

Key Points

  • GitHub Pages is the best solution for static website (and its free).

  • Be careful to not reach limitations set by the cloud provider you use.