In this post, I would like to share my experience in writing the very first CI workflow in github and what are the things to be noticed while creating one.
Let's understand why CI workflows are important
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 pushes changes to their branch, 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 the first 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.
Lets breakdown the changes and understand what does it mean
Workflow Name and Triggers:
The workflow is named "CI Website".
It's triggered by two events:
- Pushes to the main branch.
- Pull requests that modify specific files.
The specified files are "package.json" and any file within the "packages/twenty-website/" directory. Which means whenever the package.json or any files in packages/twenty-website changes, the workflow will be run.
Concurrency:
This section manages workflow concurrency, ensuring that only one instance of the workflow runs for each combination of workflow and branch simultaneously.
If a new instance is triggered while another is still running, the existing one will be canceled.
Jobs:
The workflow contains a single job named "website-build".
This job runs on an Ubuntu latest virtual environment.
Job Steps:
Step 1: Check out the Repository:
It uses the actions/checkout@v4 action to fetch the repository's content into the runner environment.Step 2: Setup Node.js Environment:
Utilizes the actions/setup-node@v3 action to set up the Node.js environment.
Specifies Node.js version 18 as the desired version.Step 3: Install Dependencies:
Uses the "yarn" command to install dependencies required for the website project.
Dependencies are typically defined in the "package.json" file.Step 4: Build Website:
Executes the "yarn nx build twenty-website" command to build the website.
Summary
With these changes, whenever a new PR is created and it has some changes inside package.json file or packages/twenty-front the workflow will run, the developers can make sure that the website builds successfully.
Top comments (0)