YAML Config Reading
GitHub Actions workflows, docker-compose files — reading YAML configs and explaining triggers, dependencies, and variable substitution
YAML config vocabulary
- on: pull_request / push / workflow_dispatch — GitHub Actions trigger events; always read
on:first - needs: [job1, job2] — job dependency; the current job runs only after all listed jobs succeed
- depends_on: — docker-compose startup order (container starts, not service readiness)
- env_file: .env — loads host-side file into container environment variables at startup
- ${VAR:-default} — substitution with fallback; ${VAR} reads from host environment
Question 0 of 5
Read this GitHub Actions workflow snippet. Which event triggers this workflow to run?name: CI
on:
pull_request:
branches: [main, develop]
workflow_dispatch:
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm test
- on: — defines what events trigger the workflow
- pull_request: branches: [...] — fires when a PR is opened, updated, or synchronized against the listed branches
- workflow_dispatch — adds a "Run workflow" button in the GitHub Actions UI for manual runs
- push: branches: [...] — would fire on direct pushes (not present here)
on: key first — it tells you exactly what causes the workflow to run. Common triggers: push, pull_request, schedule, workflow_dispatch, release.In this docker-compose.yml, which services does the api service depend on, and what does that mean at startup?services:
api:
image: myapp:latest
depends_on:
- db
- redis
db:
image: postgres:16
redis:
image: redis:7
worker:
image: myapp:latest
depends_on:
- db
- depends_on: [db, redis] — Compose starts
dbandrediscontainers beforeapi - Important caveat — "started" means the container process launched, not that PostgreSQL or Redis is accepting connections yet
- For true readiness — use
depends_on: condition: service_healthywith ahealthcheckdefined on the dependency
worker service only depends on db, so it starts after db is running but independently of redis and api.What does env_file: .env do in this docker-compose service?services:
api:
image: myapp:latest
env_file:
- .env
- .env.production
environment:
NODE_ENV: production
- env_file — reads each
KEY=valueline from the file and sets them as container environment variables - Multiple files — listed top-to-bottom; if the same key appears in both, the last file wins
- environment: — inline key-value pairs; these have higher priority than env_file entries
- Security — add
.envto.gitignore; never commit secrets to version control
Read this GitHub Actions deploy workflow. What does the needs: keyword mean here?jobs:
test:
runs-on: ubuntu-latest
steps:
- run: npm test
build:
runs-on: ubuntu-latest
needs: test
steps:
- run: npm run build
deploy:
runs-on: ubuntu-latest
needs: [test, build]
steps:
- run: ./deploy.sh
- needs: jobName — this job waits for jobName to complete with success before starting
- needs: [job1, job2] — waits for all listed jobs
- If any prerequisite fails — the dependent job is skipped (not failed) by default
- Parallel execution — jobs without
needsrun in parallel;needscreates a sequential pipeline
Identify all environment variables in this YAML file and explain how each gets its value:services:
app:
environment:
DATABASE_URL: postgresql://db:5432/myapp
API_KEY: ${API_KEY}
NODE_ENV: production
PORT: "3000"
DEBUG: ${DEBUG:-false}
- hardcoded value —
NODE_ENV: productionis the literal string "production" in every environment - ${API_KEY} — reads the
API_KEYvariable from the shell/host environment where docker-compose is run; if unset, the variable is empty - ${DEBUG:-false} — uses bash-style default syntax: if
DEBUGis not set on the host, it defaults tofalse - PORT: "3000" — quoted to ensure it is treated as a string, not a YAML integer
${VAR:-default} for optional config and ${VAR} (no default) for required secrets — an empty required secret is easier to catch.