Why GitHub Actions basics? - Purpose & Use Cases

The Big Idea

What if your code could test and deploy itself every time you save a change?

The Scenario

Imagine you have a project where every time you change code, you need to manually check if it works, build it, and then deploy it. You open your computer, run commands one by one, and hope you didn't miss a step.

The Problem

This manual way is slow and tiring. You might forget a step or make a mistake. It wastes time and can cause bugs to sneak into your project. Doing the same tasks over and over is boring and error-prone.

The Solution

GitHub Actions lets you automate these tasks. It runs checks, builds, and deploys your code automatically whenever you make changes. This means less work for you and fewer mistakes.

Before vs After

✗ Before

git pull
npm install
npm test
npm run build
npm run deploy

✓ After

on: push
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: npm install
      - run: npm test
      - run: npm run build
      - run: npm run deploy

What It Enables

It enables your project to build and test itself automatically, so you can focus on writing great code.

Real Life Example

When a team works together on a website, GitHub Actions can automatically check that new changes don't break anything before they become live.

Key Takeaways

Manual code checks and deployments are slow and risky.

GitHub Actions automates these tasks to save time and reduce errors.

Automation helps teams deliver better software faster.

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