🔍 Breakdown:#

• name: Descriptive name of the workflow.

name: CI Test Workflow

You can give any name here to help identify the purpose of the workflow file. This is especially useful when managing multiple workflows in a project.

• on: Defines the event that triggers the workflow. For example, the following configuration runs the workflow when there is a push to the main branch:

on:
  push:
    branches:
      - main

You can customize this to trigger on other events like pull_request, schedule, or even on specific paths or tags.

• jobs: Defines a set of tasks (jobs) that will be executed as part of the workflow. Each job runs independently (unless dependencies are defined), and can be assigned a name, operating system, and a set of steps.

jobs:
  build:
    runs-on: ubuntu-latest

In this example, a job named build will run on the latest version of an Ubuntu runner provided by GitHub. You can name the job anything and choose other environments like windows-latest or macos-latest depending on your requirements.

Also, you can use different OS versions as needed.

jobs:
  build:
    runs-on: ubuntu-18.04

NOTE

In this example, the workflow includes two separate jobs:

• build-and-push: Handles building the application and pushing the Docker image (or artifacts) to a repository.
• deploy-to-live: Responsible for deploying the built code or image to the live environment.

Each job runs independently or sequentially, depending on how you define dependencies between them.

• This is the example how that defined in workflow file

name: Build and Push Docker Image

on:
  push:
    branches:
      - main  # Trigger on push to main branch
  workflow_dispatch: # Allow manual trigger


jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:
    # Checkout the code
    - name: Checkout repository
      uses: actions/checkout@v4

  deploy-to-live:
        runs-on: ubuntu-latest
        needs: build-and-push

        steps:
          # Checkout the code
          - name: Checkout code
            uses: actions/checkout@v4

In this example, the deploy-to-live job will only run after the build-and-push job has completed successfully. If you don’t use needs, both jobs will run in parallel by default. Using needs helps you control the execution order of jobs and ensure that deployment only happens if the build process is successful.

needs: build-and-push

• steps: Individual tasks within the job.

In GitHub Actions, the steps section defines what happens inside a job. Each step can run a shell command, use a prebuilt action, or set up part of the workflow. Steps share the same environment and file system within the job.

Here’s a breakdown of the steps in your sample workflow:

jobs:
  build-and-push:
    runs-on: ubuntu-latest

    steps:

    - name: Checkout repository
      uses: actions/checkout@v4

    - name: Log in to GitHub Container Registry
      uses: docker/login-action@v3
      with:
        registry: ghcr.io
        username: ${{ github.actor }}
        password: ${{ secrets.GITHUB_TOKEN }}

    - name: Build Docker image
      run: |
        PROJECT_NAME=$(basename ${{ github.repository }})
        docker build -t ghcr.io/${{ github.repository_owner }}/${PROJECT_NAME}:latest .

    - name: Push Docker image
      run: |
        PROJECT_NAME=$(basename ${{ github.repository }})
        docker push ghcr.io/${{ github.repository_owner }}/${PROJECT_NAME}:latest

🔧 How to Add a Secret in GitHub#

1. Go to your GitHub repository.
2. Click on Settings.
3. Go to Secrets and variables → Actions.
4. Click New repository secret.
5. Set a name like DOCKER_PASSWORD and paste the secret value.

✅ How to Use a Secret in a Workflow#

You access secrets using the secrets context inside ${{ ... }}:

- name: Log in to Docker
  uses: docker/login-action@v3
  with:
    username: ${{ secrets.DOCKER_USERNAME }}
    password: ${{ secrets.DOCKER_PASSWORD }}

- name: Use secret in shell script
  run: echo "The secret is $MY_SECRET"
  env:
    MY_SECRET: ${{ secrets.MY_SECRET_VALUE }}