I’m back! 🏠 After a two-day gap spent disconnected in my village, I returned to my setup today with a lot of energy. I decided to tackle the CI (Continuous Integration) lifecycle head-on using GitHub Actions.
Here is a quick log of what I implemented and learned today.
🛠 The Setup
I worked with a sample Node.js application. The goal was to create a workflow that acts as a gatekeeper for the code.
The Workflow Triggers: I configured the .github/workflows/main.yml to trigger on:
push (to the main branch)
pull_request (targeting the main branch)
✅ The Job Steps
I defined a job build-and-test that performs the following execution strategy:
Checkout Code: Uses actions/checkout.
Setup Node: Uses actions/setup-node (I tested with Node v18).
Install Dependencies: npm ci (clean install).
Build: npm run build.
Test: npm test.
Now, if a test fails, the PR is flagged immediately. No more breaking production! 🛑
🏃♂️ Runners: Self-Hosted vs. GitHub-Hosted
I also dug into where these jobs actually run.
GitHub-hosted Runners: The default. GitHub spins up a fresh VM (Ubuntu/Windows/Mac) for every job. It’s clean and easy, but you have limited control over hardware.
Self-hosted Runners: You install the runner agent on your own machine (or AWS EC2).
Pro: You persist data between runs (faster caching).
Pro: You can access private network resources.
Con: You have to manage the updates and scaling yourself.
📝 Wrap up
It was a productive day catching up on what I missed over the weekend. Understanding the difference between runners is going to be super useful when I start deploying to AWS.
Have you tried setting up a Self-hosted runner yet? Let me know in the comments! 👇
Linkedin: https://www.linkedin.com/in/dasari-jayanth-b32ab9367/
Top comments (0)