GitHub Actions basics - Step-by-Step Execution

Process Flow - GitHub Actions basics

Push code to GitHub

↓

GitHub detects push event

↓

Trigger GitHub Actions workflow

↓

Run defined jobs and steps

↓

Jobs execute commands (build, test, deploy)

↓

Workflow completes with success or failure

↓

Status shown on GitHub repository

This flow shows how pushing code to GitHub triggers a workflow that runs jobs and steps, then reports the result.

Execution Sample

Git

name: CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello from GitHub Actions!"

This workflow runs on every push and prints a message in the job.

Process Table

Step	Action	Evaluation	Result
1	Push code to GitHub	Event detected	Workflow triggered
2	Start job 'build'	Runs on ubuntu-latest	Job environment ready
3	Run step: echo message	Execute shell command	Output: Hello from GitHub Actions!
4	Job completes	No errors	Job success
5	Workflow completes	All jobs done	Workflow success status shown

💡 Workflow ends after all jobs and steps finish successfully.

Status Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	Final
Workflow status	Not started	Triggered	Running	Running	Success
Job status	Not started	Not started	Running	Success	Success
Step output	None	None	None	Hello from GitHub Actions!	Hello from GitHub Actions!

Key Moments - 3 Insights

Why does the workflow start when I push code?

Because the workflow is set to trigger on the 'push' event, as shown in execution_table step 1.

What does 'runs-on: ubuntu-latest' mean?

It means the job runs on a fresh Ubuntu virtual machine provided by GitHub, as seen in step 2.

How do I know if my command ran successfully?

The command output appears in step 3, and the job success in step 4 confirms no errors.

Visual Quiz - 3 Questions

Look at the execution table, what is the workflow status after step 2?

A Running

B Success

C Not started

D Failed

💡 Hint

Check the 'Workflow status' row in variable_tracker after Step 2.

At which step does the job environment become ready?

A Step 1

B Step 2

C Step 3

D Step 4

💡 Hint

Look at the 'Action' and 'Result' columns in execution_table for job start.

If the echo command failed, what would change in the execution table?

A Step 1 would not trigger the workflow

B Step 2 would not run the job

C Step 3 would show an error output and Step 4 would show failure

D Step 5 would show success anyway

💡 Hint

Refer to step 3 and 4 in execution_table for command execution and job completion.

Concept Snapshot

GitHub Actions basics:
- Trigger workflows on events like push
- Define jobs with 'runs-on' to set environment
- Jobs have steps that run commands
- Workflow status shows success or failure
- Outputs appear in job logs

Full Transcript

GitHub Actions basics start when you push code to your GitHub repository. This push event triggers a workflow defined in a YAML file. The workflow runs jobs on virtual machines like 'ubuntu-latest'. Each job runs steps, which are commands like printing messages or running tests. The workflow ends with a success or failure status shown on GitHub. This visual trace shows each step from push to workflow completion, tracking status and outputs clearly.

Practice

1. What is the main purpose of GitHub Actions in a repository?

easy

A. To automate tasks like testing and deployment when events happen

B. To store large files in the repository

C. To manage user permissions on the repository

D. To create branches automatically

Solution

1. Step 1: Understand GitHub Actions role

   GitHub Actions automate workflows triggered by events such as code pushes or pull requests.

2. Step 2: Compare options with purpose

   Options B, C, and D describe other GitHub features, not automation tasks.

3. Final Answer:

   To automate tasks like testing and deployment when events happen -> Option A

4. Quick Check:

   Automation = A [OK]

Hint: GitHub Actions = automation triggered by events [OK]

Common Mistakes:

• Confusing GitHub Actions with file storage
• Thinking it manages user permissions
• Assuming it creates branches automatically

2. Which of the following is the correct location to place a GitHub Actions workflow file?

easy

A. .git/actions/

B. .github/workflows/

C. workflows/.github/

D. actions/workflows/

Solution

1. Step 1: Recall workflow file location

   GitHub Actions workflows must be stored in the .github/workflows/ directory in the repository.

2. Step 2: Verify other options

   Options B, C, and D do not match the required directory structure for workflows.

3. Final Answer:

   .github/workflows/ -> Option B

4. Quick Check:

   Workflow path = .github/workflows/ [OK]

Hint: Workflow YAML files go inside .github/workflows/ folder [OK]

Common Mistakes:

• Placing workflow files outside .github/workflows/
• Using incorrect folder names like .git or actions
• Confusing workflows folder location

3. Given this workflow snippet, what will happen when code is pushed to the main branch?

name: Test Workflow
on:
  push:
    branches:
      - main
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - run: echo "Build started"

medium

A. The workflow runs and prints 'Build started' on push to main

B. The workflow runs but does nothing on push to main

C. The workflow runs only on pull requests, not push

D. The workflow fails due to syntax error

Solution

1. Step 1: Analyze trigger event

   The workflow triggers on push events to the main branch as specified under 'on: push: branches: - main'.

2. Step 2: Check job steps

   The job named 'build' runs on ubuntu-latest and executes a step that runs the command echo "Build started".

3. Final Answer:

   The workflow runs and prints 'Build started' on push to main -> Option A

4. Quick Check:

   Push to main triggers echo output [OK]

Hint: Push to main triggers echo command in workflow [OK]

Common Mistakes:

• Thinking workflow triggers on pull requests only
• Assuming no output is printed
• Believing there is a syntax error

4. Identify the error in this workflow YAML:

name: CI
on: push
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Run tests
        run: pytest
      - name: Deploy
        run: deploy.sh
        if: success()

medium

A. The 'if' condition syntax is incorrect; should be 'if: success()' without indentation

B. The 'steps' list is missing a dash before 'Deploy'

C. The 'if' condition is invalid; it should be 'if: ${{ success() }}'

D. The 'runs-on' key is misspelled

Solution

1. Step 1: Review 'if' condition syntax in GitHub Actions

   GitHub Actions requires expressions inside ${{ }} for conditions, so 'if: success()' is invalid syntax.

2. Step 2: Validate other parts

   'runs-on' is correctly spelled, and the steps list has proper dashes. Indentation is correct.

3. Final Answer:

   The 'if' condition is invalid; it should be 'if: ${{ success() }}' -> Option C

4. Quick Check:

   Conditions need ${{ }} syntax [OK]

Hint: Use ${{ }} for conditions in GitHub Actions [OK]

Common Mistakes:

• Omitting ${{ }} around conditions
• Misplacing dashes in steps list
• Misspelling 'runs-on'

5. You want a GitHub Actions workflow that runs tests only when code is pushed to the 'develop' branch or when a pull request targets 'develop'. Which 'on' configuration is correct?

hard

A. on:
push:
branches:
- develop
pull_request:
branches:
- main

B. on:
push:
branches:
- main
pull_request:
branches:
- develop

C. on:
push:
branches:
- main
pull_request:
branches:
- main

D. on:
push:
branches:
- develop
pull_request:
branches:
- develop

Solution

1. Step 1: Understand event triggers needed

   The workflow should trigger on push to 'develop' and on pull requests targeting 'develop'.

2. Step 2: Match branches in 'on' configuration

   on: push: branches: - develop pull_request: branches: - develop correctly specifies both push and pull_request events with branches set to 'develop'. Other options mix 'main' and 'develop' incorrectly.

3. Final Answer:

   on: push: branches: - develop pull_request: branches: - develop -> Option D

4. Quick Check:

   Push and PR on develop branch = C [OK]

Hint: Match branch names exactly in push and pull_request triggers [OK]

Common Mistakes:

• Mixing 'main' and 'develop' branches in triggers
• Omitting pull_request event
• Using incorrect indentation in YAML