Bird
Raised Fist0
Gitdevops~5 mins

GitHub Actions basics - Time & Space Complexity

Choose your learning style10 modes available
Time Complexity: GitHub Actions basics
O(n)
Understanding Time Complexity

We want to understand how the time it takes to run a GitHub Actions workflow changes as the number of jobs or steps grows.

How does adding more steps or jobs affect the total execution time?

Scenario Under Consideration

Analyze the time complexity of this simple GitHub Actions workflow.

name: Example Workflow

on: [push]

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Step 1
        run: echo "Hello"
      - name: Step 2
        run: echo "World"
      - name: Step 3
        run: echo "!"

This workflow runs three steps sequentially when code is pushed.

Identify Repeating Operations

Look for repeated actions that take time.

  • Primary operation: Each step runs one command.
  • How many times: Number of steps in the job (3 in this example).
How Execution Grows With Input

As you add more steps, the total time grows roughly by adding each step's time.

Input Size (n = steps)Approx. Operations (steps run)
1010 steps
100100 steps
10001000 steps

Pattern observation: The total time grows directly with the number of steps.

Final Time Complexity

Time Complexity: O(n)

This means the total execution time grows linearly as you add more steps.

Common Mistake

[X] Wrong: "Adding more steps won't affect total time because they run fast."

[OK] Correct: Each step adds time, so more steps mean more total time, even if each is short.

Interview Connect

Understanding how workflow steps add up helps you design efficient pipelines and explain your choices clearly.

Self-Check

"What if some steps run in parallel jobs instead of sequentially? How would the time complexity change?"

Practice

(1/5)
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
Recommended

Ready to prove it?

Pass the test and this pattern moves unknown strong while earning +1 Grip toward your certificate.

10 questions~5 mineasy hard