Core Components: Events, Jobs, and Steps

To master GitHub Actions, you must understand the fundamental building blocks that make up a workflow. Think of a GitHub Action as a recipe: the Event is the hunger that triggers the cooking, the Jobs are the different courses being prepared, and the Steps are the individual instructions like "chop onions" or "boil water."

The Workflow Hierarchy

Every automation in GitHub Actions follows a specific hierarchy. Understanding how these components nest within each other is crucial for debugging and optimization.

Workflow File (.yml)
└── Event (The Trigger)
    └── Job 1 (The Runner Environment)
        ├── Step 1 (Action or Script)
        └── Step 2 (Action or Script)
    └── Job 2 (Optional: Runs in parallel)
        ├── Step 1
        └── Step 2
    

1. Events: The Triggers

An event is a specific activity in a repository that triggers a workflow run. In your YAML file, this is defined under the on: key.

• Webhook Events: These occur when someone pushes code, creates a pull request, or opens an issue.
• Scheduled Events: Using cron syntax, you can trigger workflows at specific times (e.g., every night at midnight).
• Manual Events: The workflow_dispatch event allows you to trigger a workflow manually via the GitHub UI.

Example: Triggering a workflow on a push to the main branch.

on:
  push:
    branches:
      - main
    

2. Jobs: The Execution Units

A job is a set of steps that execute on the same runner. By default, if your workflow has multiple jobs, they run in parallel. However, you can make them dependent on each other using the needs keyword.

• Runner: Each job runs on a fresh virtual machine (Ubuntu, Windows, or macOS) or a container.
• Isolation: Jobs are isolated from each other. If Job A creates a file, Job B cannot see it unless you use "Artifacts" to pass data.
• Efficiency: Running jobs in parallel speeds up your CI/CD pipeline.

3. Steps: The Individual Tasks

Steps are the smallest building blocks. They are executed in sequential order within a job. If one step fails, the subsequent steps in that job are usually skipped.

Steps can perform two types of tasks:

• Commands: Running shell scripts or CLI commands using the run keyword.
• Actions: Using pre-built components (from the GitHub Marketplace) using the uses keyword.

Practical Example: A Java Build Workflow

Here is how these components look when combined in a real-world scenario for a Java developer.

name: Java CI with Maven
on: [push] # The Event

jobs:
  build: # Job ID
    runs-on: ubuntu-latest # The Runner
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4 # An Action Step

      - name: Set up JDK 17
        uses: actions/setup-java@v3 # An Action Step
        with:
          java-version: '17'
          distribution: 'temurin'

      - name: Build with Maven
        run: mvn clean package # A Command Step
    

Common Mistakes to Avoid

• YAML Indentation: GitHub Actions is extremely sensitive to spaces. A single misplaced space in your steps or jobs block will cause a syntax error.
• Assuming Persistent State: Beginners often expect a file created in "Job 1" to be available in "Job 2". Remember: Jobs run on different runners. Use actions/upload-artifact to share data.
• Missing Permissions: Sometimes a step fails because the GITHUB_TOKEN does not have write access to the repository.

Real-World Use Cases

• Automated Testing: Triggering a "Test" job every time a developer creates a Pull Request to ensure no breaking changes are introduced.
• Continuous Deployment: A "Deploy" job that only runs after a "Build" job completes successfully on the production branch.
• Code Linting: A step that checks Java code formatting and fails the build if the code is messy.

Interview Notes: GitHub Actions Components

• Question: How do you make jobs run sequentially instead of in parallel?
• Answer: Use the needs keyword in the dependent job. For example, deploy: needs: [build].
• Question: What is the difference between run and uses?
• Answer: run executes a shell command, while uses invokes a reusable GitHub Action.
• Question: Can a single workflow have multiple triggers?
• Answer: Yes, the on: key can accept a list of events like [push, pull_request].

Summary

In this lesson, we explored the core components of GitHub Actions. We learned that Events trigger the process, Jobs define the environment and execution strategy, and Steps contain the actual logic, whether they are custom scripts or reusable actions. Mastering the relationship between these three is the foundation of building robust CI/CD pipelines.