GitHub Actions 101: Your First Step Into CI/CD

Have you ever noticed job postings that say “Knowledge of CI/CD or GitHub Actions required” or have you come across it and wonder “What does that actually mean?” If so, you’re in the right place.

Continuous Integration and Continuous Deployment (CI/CD) is the practice of automatically building, testing, and deploying code changes, which allows a faster and reliable software release. In real life, it’s like ordering a food from a high-tech food app. You first place your order (push code) then the automated kitchen builds your meal (cooks it), runs a quality check on the food (tests it) and a driver instantly brings your order to your doorstep (deploys it).

If you’re just starting to explore these topics, CI/CD can sound intimidating, but adding your first GitHub Action is easier than you think! In this walkthrough, I’ll show you how to set up a simple GitHub Action so that every time you push your code changes, it will automatically run without your intervention.

---

🚨 Prerequisites:

• This guide assumes you already have a Next.js app in a GitHub repository. If not, you can quickly create with npx create-next-app@latest and push it to GitHub.
• If you see a banner in your repository that asks you to add a billing, you will need to input a valid card payment in order to proceed.

---

🛠️ The Walkthrough

We'll tackle this in four steps: create the file, add the code, push to GitHub, and check the results.

Step 1: Create a folder in your root directory called .github. Once you have that, create a new folder inside it named workflows. This is where we will add our GitHub action file. In this walkthrough, I will name my GitHub action file github-action-demo.yml. You are free to name yours whatever fits your needs.

• 💡 This directory is where github scans for an available github actions. Any .yml file that you put in here will be detected as a github action.

Step 2: Inside the .yml file we created, we will define a basic github actions workflow configuration.

name: A Simple Hello World
on: [push]
jobs:
  say-hello-job:
    runs-on: ubuntu-latest
    steps:
      - name: Say Hello
        run: echo "Hello, World! I'm running my first GitHub Action!"
      - name: Say Goodbye
        run: echo "Done! This was easy."

• Name: This defines the name of the workflow. It allows you to easily identify it in the Github Actions dashboard. You can also use name inside individual steps to describe the action that they are performing.
• on: [push] = This defines the event that triggers the action. In this example, the workflow will run everytime you push a code to your repository.
  • Github Actions supports many other triggers like (push, pull_request etc.) you can check out the other events in here: Github actions event
• Jobs: This is where you will define what your workflow actually does. A github action can have multiple jobs. By default, job runs in parallel unless you specify a dependency, in which case one job will only run after another completes. In my example, we will only have 1 job.
  • To avoid confusion:
    • A Job is a set of instructions. For example, "How to bake a cake".
    • Steps are the sequential things that you need to follow in order to have a perfect cake.
      1. "Preheat the oven to 350°F."
      2. "Mix flour, sugar, and eggs."
      3. "Pour batter into pan."
      4. "Bake for 30 minutes."

Step 3: Once you are done, push the file to your GitHub repository. If you have not set up your GitHub repository, refer to this official guide: GitHub Docs QuickStart for repositories

Step 4: Now go to GitHub → The repository of your app and navigate to actions. You should see an action running here (indicated by a spinner icon).

✅ = This means that your GitHub action has run successfully

❌ = This means that your action has failed. Click on it to check the logs for why it failed (this could be an error in your .yml file or an account issue, like the billing notice mentioned in the prerequisites)

And there you have it 🎉. You've just automated your first workflow. You now have a foundational skill that you can build on, such as expanding your configuration to include automated testing and many more.

As a next step, try modifying the .yml file so that it will run on a pull_request that has been closed instead of on push. Comment down below and share how you would achieve that.