CI and Dev Containers
Kannav Sethi
Posted on November 18, 2024
Introduction
For this week of contribution, I planned to implement a CI pipeline that will automate all of the checks made to any of the changes pushed to my main branch directly or via a PR
In addition to this, since my project is becoming bigger and is open-sourced, I believe more people are going to contribute to this, so I also added the option to have dev-containers for the ease-of-use of a developer and better dev experience.
Again, all of this work is being done on my project, DialectMorph
CI Pipeline
There are a lot of tools that could help with making CI/CD pipelines, but for this project, I decided to go with Github Action, this was because I was already familiar with it and it would be a perfect fit for my project
Github Actions work on YAML Scripts, these are nothing but configuration files, similar to how JSON is used to provide configuration settings. YAML is much preferred in the field of DevOps to make configuration easy and human-readable
Setup
For my project, I have used the following configuration setting
name: Linting and Formatting
on:
push:
branches:
- main
- master
pull_request:
branches:
- main
- master
jobs:
lint:
name: Prettier and ESLint
runs-on: ubuntu-latest
steps:
- name: Checks Out the Repository
uses: actions/checkout@v4
- name: Setup NodeJS
uses: actions/setup-node@v4
with:
node-version: 20
- name: Sets up the Bun enviornment
uses: oven-sh/setup-bun@v2
with:
bun-version: "latest"
- name: Installing Bun Dependencies
run: |
bun install .
bun install -D jest ts-jest @types/jest typescript
- name: Linting The Code
run: |
bun eslint .
- name: Checking for Formatting
run: |
bunx prettier . --check
- name: Running Tests
run: |
npm test
in the Github Actions config file, three things are necessary for a valid configuration which are
- name: Informs the name of the script
- on: Event that triggers the CI/CD pipeline
- jobs: Tasks that would run when the event is triggered
My specific configuration is as follows:
- Push or Pull Requests to the Main Branch trigger the CI script
- Once the event is triggered, the first command sets up the environment to run on an Ubuntu virtual machine
- Then the repository is cloned on the VM and
bun
installs dependencies and runs the project - The project is checked for any listing errors
- The project is then checked for consistent formatting based on the prettier rules that are in the project
- At last, the test-suite is run to check for any errors occurring during the changes that are coming from a different branch
Github actions helped me automate all of the checks that I would have to do manually just to ensure no major errors were occurring in my codebase and no tech debt was being stacked on.
Dev Containers
Dev-Containers, are one of the best tools for developers collaborating on a project and wanting to have a consistent platform to keep up with development, ignoring the dependency issues on each of their local machines.
Env Setup
To get this setup for my project, I had to provide the developer with the option to develop inside a container, which meant I had to configure the settings for my dev-container
My project utilizes bun
as the main package-handler tool, and it is not that easy to set it up on different machines, so I had to provide a Dockerfile as the base for my dev-container
for my Dockerfile, I utilized the following settings
FROM --platform=$TARGETPLATFORM ubuntu:latest
RUN apt-get update && apt-get install -y curl unzip git
RUN curl -fsSL https://bun.sh/install | bash
ENV PATH="/root/.bun/bin:${PATH}"
this ran the container in an Ubuntu image, it installs git curl and unzip as the machine dependencies, so that the user shouldn't have the issue of installing them manually
then it sets up the bun
package manager on the container for
now for the actual dev-container.json
configuration , I have used the following settings
{
"name": "Dev Container For DialectMorph",
"build": {
"dockerfile": "Dockerfile"
},
"customizations": {
"vscode": {
"settings": {
"window.zoomLevel": 0.5,
"workbench.tree.indent": 20,
"editor.minimap.renderCharacters": false,
"files.autoSave": "afterDelay",
"files.autoSaveDelay": 1000,
"editor.cursorBlinking": "smooth",
"files.eol": "\n",
"files.trimTrailingWhitespace": true,
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true,
"prettier.trailingComma": "es5",
"prettier.semi": true,
"prettier.tabWidth": 2,
"prettier.useTabs": true,
"prettier.printWidth": 80,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": "always"
},
"eslint.validate": ["typescript"]
},
"extensions": [
"dbaeumer.vscode-eslint", // ESLint support
"esbenp.prettier-vscode", // Prettier formatting
"ms-vscode.vscode-typescript-next", // TypeScript support
"aaron-bond.better-comments", // Better code comments
"christian-kohler.path-intellisense", // Path autocompletion
"streetsidesoftware.code-spell-checker", // Spell checking
"eamodio.gitlens", // Git integration
"yoavbls.pretty-ts-errors", // Better TypeScript errors
"wayou.vscode-todo-highlight", // Highlight TODOs
"gruntfuggly.todo-tree" // Track TODOs
]
}
}
}
in this, I have provided the base of my dev-container to be the Dockerfile and then added the recommended vs code setting and extensions which would help the user in the development
Conclusion
I successfully implemented a CI pipeline using GitHub Actions for my DialectMorph project, automating all the necessary code checks and testing processes. As my project grows, I wanted to ensure quality and consistency, which led me to configure the pipeline to run on both direct pushes and pull requests to the main branch. To make it even more contributor-friendly, I added dev container support with custom VS Code configurations, making it significantly easier for other developers to jump in and start contributing without worrying about environment setup
Posted on November 18, 2024
Join Our Newsletter. No Spam, Only the good stuff.
Sign up to receive the latest update from our blog.