GitHub Actions

GitHub Actions – CI/CD Tool (Brief Overview)

GitHub Actions is a CI/CD (Continuous Integration and Continuous Deployment) tool built right into GitHub.
It helps you automate tasks such as building, testing, and deploying your code — directly from your GitHub repository.

Imagine GitHub Actions like a robot assistant for your code
When you do something in GitHub (like pushing code),
the robot says:

“Oh, you pushed code! Let me automatically do some work for you.”

---

⚙️ How It Works (In Simple Words)

Event/Trigger → Workflow → Job → Steps

• Event/Trigger: Something happens (like pushing code or opening a pull request).

• Workflow: A plan you give to the robot (written in a .yml file).

• Job: A big task (like building, testing, or deploying your app).

• Steps: The actual commands or small actions the robot runs.

---

📄 Workflows

• A workflow is an automation process defined in a .yml file.

• Stored inside the .github/workflows/ folder.

• Written in YAML syntax.

• You can have multiple workflows in a single repository.

Think of it like:

A plan you give to your robot assistant describing what to do and when.

---

Events (Triggers)

An event is what starts a workflow.

Common Events

• push → Runs when you push commits to the repo.

• pull_request → Runs when someone opens or updates a pull request.

• issues → Runs when an issue is opened, commented, or closed.

• schedule → Runs automatically at specific times (like a cron job).

• workflow_dispatch → Manual trigger (you click a button to run it).

Analogy:

Event = “Alarm rings” → That’s when your robot starts working.

---

Jobs

• A job is a collection of steps that run on a runner (a machine/VM).

• Each job runs independently, but jobs can depend on each other.

• A workflow can have one or many jobs (for build, test, deploy, etc.).

Analogy:

Job = A big task inside your daily plan (like Make breakfast or Go to gym).

---

Steps & Actions

Steps

• The actual commands or smaller tasks inside a job.

• Each step can be:

  • A shell command (e.g., run: echo "Hello")

  • Or a pre-built Action from GitHub Marketplace.

Actions

• Actions are reusable pieces of code that perform specific tasks.

• They help automate common tasks like:

  • Checking out code (actions/checkout)

  • Setting up environments (actions/setup-node, actions/setup-java)

  • Deploying apps (AWS, Azure, etc.)

Analogy:

Steps = Small actions inside the big task
(Boil water, Add tea, Lift weights, Run 2 km)

---

🖥️ Runners

A runner is the machine that executes your jobs.

Types of Runners

1. GitHub-Hosted Runner

   • Provided by GitHub (e.g., Ubuntu, Windows, macOS).

   • Automatically created and destroyed for each job.

   • Example: runs-on: ubuntu-latest

2. Self-Hosted Runner

   • Your own server, VM, or on-prem machine.

   • Useful for custom environments or private infrastructure.

   • Example: runs-on: self-hosted

Think of runners as the computers where your robot assistant works.

---

🔐 GitHub Secrets

• Used to store sensitive information (passwords, API keys, tokens).

• Defined under Repository Settings → Secrets → Actions.

• Accessed inside workflows using ${{ secrets.MY_SECRET_NAME }}.

Example:

- name: Deploy to AWS  
  run: aws deploy ...  
  env:  
    AWS_KEY: ${{ secrets.AWS_ACCESS_KEY }}

Tip: Secrets are encrypted and hidden in logs for security.

Full Analogy Summary

Runner

Machine running the job

Ubuntu VM / Self-hosted server

Secrets

Secure variables

API keys, tokens

Lets start with few example

---

name: Manual Workflow

on:
  push:
    branches: [main]  
    workflow_dispatch:

jobs:
  manual-job:
    runs-on: ubuntu-latest
    steps:
      - name: Say Hello
        run: echo "This workflow is on auto and manual option"

A simple workflow that prints “Hello World.” It is configured to trigger automatically whenever there is a push to the main branch of the repository. Additionally, it includes the workflow_dispatch event, which allows the workflow to be triggered manually from the GitHub Actions interface.

let’s take a look at second example

---

name: Node.js CLI CI/CD

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
  workflow_dispatch:
  release:
    types: [published]  # triggers when a release is published

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'

      - name: Install dependencies
        working-directory: ./nodeappcli
        run: npm install

      - name: Run tests
        working-directory: ./nodeappcli
        run: npm test

  publish:
    needs: test
    runs-on: ubuntu-latest
    if: github.event_name == 'release' && github.event.action == 'published'
    steps:
      - name: Checkout code
        uses: actions/checkout@v3

      - name: Set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
          registry-url: 'https://registry.npmjs.org/'

      - name: Install dependencies
        working-directory: ./nodeappcli
        run: npm install

      - name: Publish to NPM
        working-directory: ./nodeappcli
        run: npm publish --access public
        env:
          NODE_AUTH_TOKEN: ${{ secrets.NPM_TOKEN }}

Triggers

It runs when:

• Code is pushed or a pull request is made to the main branch.

• A release is published on GitHub.

• It’s manually triggered via workflow_dispatch.

Jobs

1. test

Runs on every push, PR, or manual trigger to ensure code works:

• Checks out the code.

• Sets up Node.js v18.

• Installs dependencies from ./nodeappcli.

• Runs npm test to execute the tests.

2. publish

Runs only after tests pass and when a release is published:

• Checks out the code.

• Sets up Node.js and configures the NPM registry.

• Installs dependencies.

• Publishes the package to npm using the secret NPM_TOKEN for authentication.

In short:
Push/PR → Test → Release → Auto Publish to NPM (if tests pass).