Continuous Integration
You will learn how to create a basic CI file for GitHub and GitLab, and run tests on them
Continuous Integration (CI)#
No matter which of the deployment plans you choose, you will need a build pipeline. There are many third-party tools out there such asJenkins, Travis CI, andCircle CI, but to keep it simple, I will be using the vanilla GitLab and GitHub pipelines.
GitHub#
As most of you probably have a GitHub account, I will be starting with this one.
The GitHub CI is activated for your repository when you have a/.github/workflows
folder with a YAML workflow file. This file can be called
pretty much whatever you want, and you can have as many workflow files as you
want. See more information about the configurationhere
if you are interested. When you make any file changes to your repository on
GitHub (push, merge, pr etc.), GitHub will check your .github/workflows
folder
and each of the jobs to see if any of them can be executed. There is currently
no way to trigger the jobs manually, but you can rerun past jobs if needed.
Let's start by creating our YAML file: /.github/workflows/ci.yml
, and adding
the following to it:
name: CI
env:
DENO_VERSION: 1.26.0
on:
push:
branches:
- main
jobs:
lint-and-format-check:
runs-on: ubuntu-latest
steps:
- name: Clone repo
uses: actions/checkout@v3
- name: Install deno
uses: denoland/setup-deno@v1
with:
deno-version: ${{env.DENO_VERSION}}
- name: Deno formatting
run: deno fmt --check
- name: Deno linting
run: deno lint
We've named our pipeline CI
, then set an environment variable for our Deno
version. We also want to only run the deployment for the main
branch, but we
want to allow it for all pushes. This is of course dependent on your
requirements, but for this tutorial, it will serve as a good start.
This page is a preview of Build and deploy a REST API with Deno