GitHub Actions basics - Time & Space 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?
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.
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).
As you add more steps, the total time grows roughly by adding each step's time.
| Input Size (n = steps) | Approx. Operations (steps run) |
|---|---|
| 10 | 10 steps |
| 100 | 100 steps |
| 1000 | 1000 steps |
Pattern observation: The total time grows directly with the number of steps.
Time Complexity: O(n)
This means the total execution time grows linearly as you add more steps.
[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.
Understanding how workflow steps add up helps you design efficient pipelines and explain your choices clearly.
"What if some steps run in parallel jobs instead of sequentially? How would the time complexity change?"
Practice
Solution
Step 1: Understand GitHub Actions role
GitHub Actions automate workflows triggered by events such as code pushes or pull requests.Step 2: Compare options with purpose
Options B, C, and D describe other GitHub features, not automation tasks.Final Answer:
To automate tasks like testing and deployment when events happen -> Option AQuick Check:
Automation = A [OK]
- Confusing GitHub Actions with file storage
- Thinking it manages user permissions
- Assuming it creates branches automatically
Solution
Step 1: Recall workflow file location
GitHub Actions workflows must be stored in the .github/workflows/ directory in the repository.Step 2: Verify other options
Options B, C, and D do not match the required directory structure for workflows.Final Answer:
.github/workflows/ -> Option BQuick Check:
Workflow path = .github/workflows/ [OK]
- Placing workflow files outside .github/workflows/
- Using incorrect folder names like .git or actions
- Confusing workflows folder location
name: Test Workflow
on:
push:
branches:
- main
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: echo "Build started"Solution
Step 1: Analyze trigger event
The workflow triggers on push events to the main branch as specified under 'on: push: branches: - main'.Step 2: Check job steps
The job named 'build' runs on ubuntu-latest and executes a step that runs the command echo "Build started".Final Answer:
The workflow runs and prints 'Build started' on push to main -> Option AQuick Check:
Push to main triggers echo output [OK]
- Thinking workflow triggers on pull requests only
- Assuming no output is printed
- Believing there is a syntax error
name: CI
on: push
jobs:
test:
runs-on: ubuntu-latest
steps:
- name: Run tests
run: pytest
- name: Deploy
run: deploy.sh
if: success()Solution
Step 1: Review 'if' condition syntax in GitHub Actions
GitHub Actions requires expressions inside ${{ }} for conditions, so 'if: success()' is invalid syntax.Step 2: Validate other parts
'runs-on' is correctly spelled, and the steps list has proper dashes. Indentation is correct.Final Answer:
The 'if' condition is invalid; it should be 'if: ${{ success() }}' -> Option CQuick Check:
Conditions need ${{ }} syntax [OK]
- Omitting ${{ }} around conditions
- Misplacing dashes in steps list
- Misspelling 'runs-on'
Solution
Step 1: Understand event triggers needed
The workflow should trigger on push to 'develop' and on pull requests targeting 'develop'.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.Final Answer:
on: push: branches: - develop pull_request: branches: - develop -> Option DQuick Check:
Push and PR on develop branch = C [OK]
- Mixing 'main' and 'develop' branches in triggers
- Omitting pull_request event
- Using incorrect indentation in YAML
Ready to prove it?
Pass the test and this pattern moves unknown
