Writing a basic Github CI workflow

Writing a basic Github CI workflow

In this article I would like to share about why do we need a CI workflow and my experience in creating a Github CI workflow.


Why do we need a CI workflow?

Let's say you are working on a new feature and creating a PR to the main branch once the development is completed. A manual code review process may be initiated by another team member or a lead developer, after the code review, the changes are merged into the main branch. Testing is performed manually by developers or a QA team. If issues are found during testing, developers have to go back to their code, make fixes, and repeat the process. This process is time consuming and a waste of resource.

With a CI workflow, each time a developer creates a pull request (we can configure when to trigger a workflow) a CI workflow is triggered automatically. The CI workflow includes steps to build the application, run automated tests, and perform other checks. If any tests fail or there are issues in the code, the CI system immediately notifies the developer. Developers can quickly identify and fix issues, reducing the time between introducing a problem and fixing it. Once all checks pass, the changes can be merged into the main branch confidently, knowing that they have been thoroughly tested.


What is Github actions?

GitHub Actions is a powerful automation platform provided by GitHub that allows developers to build, test, and deploy their code directly from their GitHub repositories. It enables developers to create custom workflows, which are sequences of steps that execute tasks such as running tests, building Docker images, deploying applications, and more.

With GitHub Actions, developers can define workflows using YAML syntax directly within their repositories, making it easy to automate various aspects of their development process. Workflows can be triggered in response to events such as pushes to the repository, pull requests, issue comments, or scheduled events.


Writing a basic Github CI workflow

I had the opportunity to work on a Github issue in an open source project to add a Github workflow that runs if some files where modified in the path packages/twenty-website and checks that the website is still building.

name: CI Website
on:
  push:
    branches:
      - main
    paths:
      - 'package.json'
      - 'packages/twenty-website/**'
  pull_request:
    paths:
      - 'package.json'
      - 'packages/twenty-website/**'
concurrency:
  group: ${{ github.workflow }}-${{ github.ref }}
  cancel-in-progress: true

jobs:
  website-build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: "18"
      - name: Website / Install Dependencies
        run: yarn
      - name: Website / Build Website
        run: yarn nx build twenty-website        

Let's break down this and understand it.

  • Name: CI Website: This is just a label for the workflow, it's called "CI Website."
  • On: This section defines when the workflow should run.
  • Push: It specifies that the workflow should trigger when code is pushed to the repository's main branch.
  • Pull_request: It specifies that the workflow should also trigger when a pull request is opened or updated.
  • Concurrency: This section helps manage concurrent workflow runs to prevent collisions or conflicts.
  • Group: It groups workflow runs by the workflow name (github.workflow) and the Git reference (github.ref), such as branch or tag.
  • Cancel-in-progress: If a new workflow run is triggered while a previous one is still running, the previous one will be automatically canceled.
  • Jobs: This section defines the actual tasks that will be executed as part of the workflow.
  • Website-build: This is the name of the job.

  • Runs-on: It specifies the type of environment the job will run on. In this case, it's the latest version of Ubuntu.
  • Steps: These are the individual actions or tasks that make up the job.
  • Uses: It pulls in a GitHub Action (in this case, actions/checkout@v4) to perform a task. This action checks out the repository's code.
  • Name: It's a label for the step, providing a description of what the step does.
  • Setup Node.js: It sets up the Node.js environment using the actions/setup-node@v3 action. It specifies Node.js version 18.
  • Website / Install Dependencies: It runs the yarn command to install dependencies required for the website.
  • Website / Build Website: It runs the yarn nx build twenty-website command to build the website using Nx, a toolkit for monorepo development.


This is a basic workflow which makes sure that the website build succeed for each PR that changes the respective code. Implementing a CI workflow is important for every project as it saves considerable time and effort for developers.

Happy learning!



To view or add a comment, sign in

More articles by Anoop P

  • Best practices to load fonts faster

    Fonts are an inevitable part of a web application, without them the user will not be able to view the page content…

  • Understanding Polyfill in Javascript

    What is a Polyfill? A polyfill is a snippet of code, often written in JavaScript for web applications, that serves the…

    1 Comment

Insights from the community

Others also viewed

Explore topics