GitHub Actions basics - Commands & Configuration

Introduction

GitHub Actions lets you automate tasks like testing and deploying your code whenever you make changes. It helps you save time by running these tasks automatically without doing them manually.

When you want to automatically test your code every time you push changes to GitHub.

When you want to build and deploy your app to a server or cloud after updating your code.

When you want to run code quality checks or linters on your project automatically.

When you want to automate sending notifications after your code is merged.

When you want to schedule regular tasks like backups or reports using your GitHub repository.

Config File - ci.yml

ci.yml

name: CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v3
    - name: Run a one-line script
      run: echo "Hello, world!"

name: Names the workflow for easy identification.

on: Defines when the workflow runs, here on pushes or pull requests to the main branch.

jobs: Contains tasks to run; this example has one job called 'build'.

runs-on: Specifies the environment, here the latest Ubuntu Linux.

steps: Lists actions and commands to execute, starting with checking out the code and then running a simple script.

Commands

Add the GitHub Actions workflow file to the staging area so it can be committed.

Terminal

git add .github/workflows/ci.yml

Expected Output

No output (command runs silently)

Commit the workflow file to your local repository with a clear message.

Terminal

git commit -m "Add GitHub Actions workflow for CI"

Expected Output

[main abc1234] Add GitHub Actions workflow for CI

 1 file changed, 15 insertions(+)

 create mode 100644 .github/workflows/ci.yml

Push your committed workflow file to the main branch on GitHub, triggering the workflow to run.

Terminal

git push origin main

Expected Output

Enumerating objects: 5, done.

Counting objects: 100% (5/5), done.

Delta compression using up to 8 threads

Compressing objects: 100% (3/3), done.

Writing objects: 100% (3/3), 350 bytes | 350.00 KiB/s, done.

Total 3 (delta 1), reused 0 (delta 0), pack-reused 0

remote: Resolving deltas: 100% (1/1), completed with 1 local object.

To github.com:username/repository.git

   def5678..abc1234  main -> main

List recent GitHub Actions workflow runs to check if your workflow started successfully.

Terminal

gh run list

Expected Output

ID    NAME  STATUS  CONCLUSION  EVENT  BRANCH  AGE

12345  CI    completed  success    push   main    1m ago

→

--limit 5 - Show only the 5 most recent workflow runs

View detailed logs of the workflow run with ID 12345 to see the output of each step.

Terminal

gh run view 12345 --log

Expected Output

Run CI



Job build



Step: Checkout repository

  Checked out repository

Step: Run a one-line script

  Hello, world!

→

--log - Show the full logs of the workflow run

Key Concept

If you remember nothing else from this pattern, remember: GitHub Actions runs your automated tasks whenever you push code changes, using workflow files stored in your repository.

Common Mistakes

Placing the workflow file outside the .github/workflows directory

GitHub Actions only detects workflow files inside the .github/workflows folder, so your workflow won't run.

Always save your workflow YAML files inside the .github/workflows directory in your repository.

Using incorrect event names under the 'on' section

If the event names are wrong, the workflow will never trigger when you expect it to.

Use valid event names like 'push' or 'pull_request' exactly as documented.

Not committing and pushing the workflow file to GitHub

The workflow only runs on GitHub, so if the file is not pushed, nothing happens.

After creating or changing the workflow file, commit and push it to the branch you want to trigger the workflow.

Summary

Create a workflow YAML file in .github/workflows to define automated tasks.

Commit and push the workflow file to GitHub to trigger the automation.

Use GitHub CLI commands to check the status and logs of your workflow runs.

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