dojo.md 0.1.0 → 0.2.0

package/courses/github-actions-cicd/scenarios/level-1/environment-variables-secrets.yaml

@@ -0,0 +1,65 @@
+meta:
+  id: environment-variables-secrets
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Manage environment variables and secrets — configure secrets, env vars, and contexts safely in GitHub Actions workflows"
+  tags: [github, actions, secrets, environment-variables, security, basics]
+
+state: {}
+
+trigger: |
+  You're setting up environment variables and secrets for a project
+  that deploys to AWS and uses a PostgreSQL database. The team has
+  been hardcoding values in their workflows and you need to fix this.
+
+  Current (insecure) workflow snippet:
+  ```yaml
+  jobs:
+    deploy:
+      runs-on: ubuntu-latest
+      steps:
+        - run: |
+            export AWS_ACCESS_KEY_ID=AKIA1234567890
+            export AWS_SECRET_ACCESS_KEY=wJalr+secret+key
+            export DATABASE_URL=postgres://admin:password123@db.example.com/prod
+            npm run deploy
+  ```
+
+  Requirements:
+  1. Move all sensitive values to GitHub Secrets
+  2. Use repository-level secrets for AWS credentials
+  3. Use environment-level secrets for database URLs (different per
+     environment: staging vs production)
+  4. Set non-sensitive configuration as environment variables (NODE_ENV,
+     LOG_LEVEL, APP_VERSION)
+  5. Make the GitHub Actions run number available as APP_VERSION
+  6. Explain the secret masking behavior (what happens if a secret
+     is accidentally printed to logs)
+
+  Your teammate asks:
+  - "What's the difference between repository secrets, environment
+    secrets, and organization secrets?"
+  - "Can I use secrets in if: conditions or as part of action inputs?"
+  - "How do I pass secrets to a Docker container step?"
+  - "What happens if I fork a repo — can the fork access the secrets?"
+
+  Task: Rewrite the workflow to use secrets and environment variables
+  correctly. Show: the GitHub Secrets configuration needed (which
+  secrets at which level), the corrected workflow YAML, the answers
+  to all 4 teammate questions, and a security checklist for secrets
+  in GitHub Actions.
+
+assertions:
+  - type: llm_judge
+    criteria: "Secrets are correctly configured — AWS credentials use repository or organization secrets (secrets.AWS_ACCESS_KEY_ID), database URLs use environment-level secrets, the workflow references secrets with ${{ secrets.NAME }} syntax, and no hardcoded sensitive values remain"
+    weight: 0.35
+    description: "Correct secrets configuration"
+  - type: llm_judge
+    criteria: "All 4 questions are answered accurately — explains the 3 secret scopes (repo/env/org) with inheritance rules, limitations of secrets in if: conditions, env: for Docker container steps, and fork security (secrets not available to forks in PRs from forks)"
+    weight: 0.35
+    description: "Accurate question answers"
+  - type: llm_judge
+    criteria: "Security best practices are covered — secret masking behavior, the GITHUB_TOKEN automatic secret, least-privilege principle for secrets, rotation strategy, and the security checklist includes at least 5 actionable items"
+    weight: 0.30
+    description: "Security best practices"

package/courses/github-actions-cicd/scenarios/level-1/first-cicd-shift.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: first-cicd-shift
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "First CI/CD shift — handle a batch of CI/CD setup tasks and troubleshooting requests as the team's GitHub Actions go-to person"
+  tags: [github, actions, shift-simulation, troubleshooting, batch, basics]
+
+state: {}
+
+trigger: |
+  You're the designated GitHub Actions person for your team this week.
+  You have 5 requests to handle.
+
+  Request 1 — New project setup (from the tech lead):
+  "We're starting a new Python project (FastAPI + PostgreSQL). Need a
+  basic CI workflow: lint with ruff, type-check with mypy, test with
+  pytest, and build a Docker image. Use Python 3.12. We also need
+  PostgreSQL as a service container for integration tests."
+
+  Request 2 — Flaky test investigation (from a frustrated developer):
+  "My E2E tests pass locally but fail randomly in CI. About 30% of
+  the time. The error is always 'connection refused' when trying to
+  reach the API server. The workflow starts the server with
+  'npm start &' and immediately runs tests. I think it's a timing
+  issue."
+
+  Request 3 — Cost optimization (from the engineering manager):
+  "Our GitHub Actions bill jumped from $200 to $800 this month. Can
+  you figure out why and fix it? I see we have 15 workflows and some
+  run on every push to every branch."
+
+  Request 4 — Secret rotation (from the security team):
+  "We're rotating all AWS credentials. Please update the GitHub Secrets
+  and make sure the deployment workflow uses the new credentials
+  without any downtime. Also, we found that the old credentials are
+  hardcoded in a workflow file. Remove them."
+
+  Request 5 — Status badge request (from the PM):
+  "Can you add a CI status badge to our README? Also, the deploys page
+  should show the current deployed version. Can GitHub Actions help
+  with that?"
+
+  Task: Handle all 5 requests. For each, write: the solution (workflow
+  YAML, configuration, or investigation steps), the explanation (so
+  the requester understands what you did), and any follow-up
+  recommendations. Prioritize the requests by urgency and explain
+  your prioritization.
+
+assertions:
+  - type: llm_judge
+    criteria: "Priority order is sensible — secret rotation (security) and flaky test (blocking developer) are higher priority than cost optimization and badge requests. The hardcoded credentials in Request 4 are flagged as critical"
+    weight: 0.35
+    description: "Sensible priority order"
+  - type: llm_judge
+    criteria: "Solutions are technically correct — Python CI workflow uses correct setup-python and service container syntax, flaky test fix uses wait-for-it or health check before running tests, cost optimization identifies unnecessary triggers and suggests path filters/concurrency"
+    weight: 0.35
+    description: "Technically correct solutions"
+  - type: llm_judge
+    criteria: "Explanations are accessible — each response is written for the specific requester's context (tech lead gets YAML, frustrated developer gets root cause, manager gets cost breakdown, security gets rotation procedure, PM gets badge markdown)"
+    weight: 0.30
+    description: "Context-appropriate explanations"

package/courses/github-actions-cicd/scenarios/level-1/job-dependencies-outputs.yaml

@@ -0,0 +1,62 @@
+meta:
+  id: job-dependencies-outputs
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Configure job dependencies and outputs — use needs, outputs, and conditional execution to create structured workflow graphs"
+  tags: [github, actions, jobs, needs, outputs, conditional, basics]
+
+state: {}
+
+trigger: |
+  You're building a deployment workflow that requires careful job
+  orchestration. Different jobs need to pass data to each other and
+  execute conditionally.
+
+  Workflow requirements:
+  1. Job: "determine-changes" — Detect what changed in the PR
+     - Output: "backend_changed" (true/false)
+     - Output: "frontend_changed" (true/false)
+     - Output: "infra_changed" (true/false)
+     - Uses git diff to check which directories have changes
+
+  2. Job: "test-backend" — Only runs if backend code changed
+     - Needs: determine-changes
+     - Condition: only if backend_changed == 'true'
+     - Output: "test_status" (passed/failed)
+
+  3. Job: "test-frontend" — Only runs if frontend code changed
+     - Needs: determine-changes
+     - Condition: only if frontend_changed == 'true'
+     - Output: "test_status" (passed/failed)
+
+  4. Job: "deploy" — Runs only if relevant tests passed
+     - Needs: test-backend AND test-frontend
+     - Should run even if one of the test jobs was skipped (because
+       that directory didn't change)
+     - Should NOT run if any test job actually failed
+
+  5. Job: "notify" — Always runs, even if previous jobs fail
+     - Reports the final status to Slack
+     - Needs access to outputs from all previous jobs
+
+  Task: Write the complete workflow YAML. Explain: how to set and
+  read job outputs (the $GITHUB_OUTPUT syntax), how 'needs' creates
+  the dependency graph, how 'if' conditions work with job outputs and
+  status functions (success(), failure(), always(), cancelled()), and
+  the tricky behavior when a needed job is skipped (the deploy job
+  scenario).
+
+assertions:
+  - type: llm_judge
+    criteria: "Job outputs are correctly configured — uses echo 'key=value' >> $GITHUB_OUTPUT syntax, outputs are declared in job-level outputs section, and downstream jobs reference them correctly with needs.<job>.outputs.<name>"
+    weight: 0.35
+    description: "Correct job output configuration"
+  - type: llm_judge
+    criteria: "Conditional execution handles the tricky cases — the deploy job runs when tests pass OR are skipped (not failed), using the correct combination of if: conditions and status check functions. The notify job uses if: always() to run regardless"
+    weight: 0.35
+    description: "Correct conditional execution"
+  - type: llm_judge
+    criteria: "Explanations clarify confusing behaviors — explains that skipped jobs cause downstream 'needs' jobs to also skip by default, how to use 'if: always()' or '!cancelled()' to override, and the difference between a job being skipped vs failing"
+    weight: 0.30
+    description: "Clear behavior explanations"

package/courses/github-actions-cicd/scenarios/level-1/simple-ci-pipeline.yaml

@@ -0,0 +1,57 @@
+meta:
+  id: simple-ci-pipeline
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Build a simple CI pipeline — create a complete lint, test, and build pipeline with proper job dependencies and failure handling"
+  tags: [github, actions, CI, pipeline, lint, test, build, basics]
+
+state: {}
+
+trigger: |
+  You're creating a CI pipeline for a React + TypeScript project.
+  The pipeline should catch issues before code is merged to main.
+
+  Project setup:
+  - React 18 with TypeScript
+  - ESLint for linting
+  - Jest for unit tests
+  - Cypress for E2E tests (runs against a dev server)
+  - Vite for building
+
+  Pipeline requirements:
+  1. Lint job: Run ESLint and TypeScript type checking
+  2. Unit test job: Run Jest with coverage report
+  3. E2E test job: Start dev server, run Cypress tests, upload
+     screenshots on failure
+  4. Build job: Only run if lint and unit tests pass
+  5. The E2E tests should run in parallel with (not blocked by) the
+     build job
+  6. If any job fails, the PR should show a red status check
+  7. Cache node_modules to speed up subsequent runs
+
+  Additional context:
+  - The team currently runs everything locally before pushing, but
+    developers sometimes skip steps. The CI should be the safety net.
+  - E2E tests are flaky — about 10% failure rate. The team wants to
+    retry failed E2E tests once before marking as failed.
+
+  Task: Write the complete CI workflow. Include: the workflow YAML with
+  all 4 jobs and proper dependencies (needs), the caching configuration
+  for node_modules, the E2E test configuration with retry and failure
+  artifact upload, and an explanation of the job dependency graph
+  (which jobs run in parallel, which are sequential).
+
+assertions:
+  - type: llm_judge
+    criteria: "Job dependencies are correct — lint and unit tests can run in parallel, build needs lint + unit tests to pass, E2E runs independently or after lint, and the dependency graph is explicitly explained with a visual or textual representation"
+    weight: 0.35
+    description: "Correct job dependencies"
+  - type: llm_judge
+    criteria: "Caching and retry are properly configured — uses actions/cache or setup-node cache for node_modules with correct cache key (hash of package-lock.json), E2E test step has retry logic (either via Cypress retry or step-level continue-on-error with re-run), and failure artifacts are uploaded"
+    weight: 0.35
+    description: "Proper caching and retry configuration"
+  - type: llm_judge
+    criteria: "Pipeline is practical and complete — all 4 jobs have correct steps, the E2E test starts a dev server before running Cypress, coverage reports are generated, and the workflow would work in a real React + TypeScript project without modification"
+    weight: 0.30
+    description: "Practical complete pipeline"

package/courses/github-actions-cicd/scenarios/level-1/workflow-debugging.yaml

@@ -0,0 +1,90 @@
+meta:
+  id: workflow-debugging
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Debug GitHub Actions workflows — diagnose and fix common workflow failures, read logs effectively, and use debug mode"
+  tags: [github, actions, debugging, troubleshooting, logs, basics]
+
+state: {}
+
+trigger: |
+  You're helping a junior developer debug their first GitHub Actions
+  workflow. They've hit 5 different errors and can't figure out what's
+  wrong. For each error, diagnose the problem and provide the fix.
+
+  Error 1 — Workflow not triggering:
+  "I pushed to my feature branch but the workflow didn't run at all.
+  No entry in the Actions tab."
+  Their trigger config:
+  ```yaml
+  on:
+    push:
+      branches: [main]
+    pull_request:
+      branches: [main]
+  ```
+  They pushed to the branch 'feature/login' without opening a PR.
+
+  Error 2 — Permission denied:
+  ```
+  Error: HttpError: Resource not accessible by integration
+  ```
+  Their workflow tries to comment on a PR using the GITHUB_TOKEN.
+  The workflow is triggered by pull_request from a fork.
+
+  Error 3 — Action not found:
+  ```
+  Error: Can't find 'action.yml', 'action.yaml' or 'Dockerfile'
+  under '/home/runner/work/_actions/actions/setup-node/4'
+  ```
+  Their step: `uses: actions/setup-node@4` (missing the 'v' prefix)
+
+  Error 4 — Cache miss every time:
+  "My workflow takes 8 minutes because npm install runs fresh every
+  time. I added caching but it never hits."
+  ```yaml
+  - uses: actions/cache@v4
+    with:
+      path: node_modules
+      key: npm-${{ hashFiles('package.json') }}
+  ```
+  The issue: they're hashing package.json not package-lock.json.
+
+  Error 5 — Job output not available:
+  "My second job can't read the output from my first job. It's always
+  empty."
+  ```yaml
+  jobs:
+    build:
+      runs-on: ubuntu-latest
+      steps:
+        - run: echo "version=1.2.3" >> $GITHUB_OUTPUT
+    deploy:
+      needs: build
+      runs-on: ubuntu-latest
+      steps:
+        - run: echo "Deploying ${{ needs.build.outputs.version }}"
+  ```
+  They forgot to declare outputs at the job level.
+
+  Task: For each error, write: the diagnosis (what went wrong and why),
+  the fix (corrected YAML or configuration), the prevention strategy
+  (how to avoid this in the future), and the debugging technique (how
+  to find this type of error faster). Include a general GitHub Actions
+  debugging guide covering: enabling debug logging, reading workflow
+  run logs effectively, and the act tool for local testing.
+
+assertions:
+  - type: llm_judge
+    criteria: "All 5 errors are correctly diagnosed — trigger scope for Error 1, fork PR permissions for Error 2, version tag format for Error 3, cache key using wrong file for Error 4, and missing job-level outputs declaration for Error 5"
+    weight: 0.35
+    description: "Correct error diagnoses"
+  - type: llm_judge
+    criteria: "Fixes are specific and correct — each fix shows the corrected YAML snippet, and the fixes address the root cause (not just the symptom). Error 2's fix addresses the fundamental fork permission model, not just a workaround"
+    weight: 0.35
+    description: "Specific correct fixes"
+  - type: llm_judge
+    criteria: "Debugging guide is practical — covers ACTIONS_RUNNER_DEBUG and ACTIONS_STEP_DEBUG secrets, how to navigate workflow run logs in the GitHub UI, the 'act' tool for local workflow testing, and at least 3 prevention strategies (linting, local testing, PR templates)"
+    weight: 0.30
+    description: "Practical debugging guide"

package/courses/github-actions-cicd/scenarios/level-1/workflow-status-notifications.yaml

@@ -0,0 +1,59 @@
+meta:
+  id: workflow-status-notifications
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Configure workflow notifications — set up status badges, Slack alerts, and PR comments to communicate CI results effectively"
+  tags: [github, actions, notifications, badges, Slack, PR-comments, basics]
+
+state: {}
+
+trigger: |
+  Your team wants better visibility into CI status. Currently, the
+  only way to know if CI passed is to click into the Actions tab.
+  You need to set up 3 notification channels.
+
+  Channel 1 — README status badges:
+  - Add build status badge to README.md
+  - Show status for the main branch
+  - Include separate badges for: CI tests, deploy status, and
+    code coverage percentage
+
+  Channel 2 — Slack notifications:
+  - Send a message to #engineering-ci channel when:
+    * A deployment to production succeeds (green message)
+    * Any CI run on main fails (red message with link to logs)
+  - Do NOT notify on:
+    * Successful PR CI runs (too noisy)
+    * Cancelled workflows
+  - Include: commit message, author, branch, link to workflow run
+
+  Channel 3 — PR comments:
+  - Post a comment on the PR with:
+    * Test results summary (X passed, Y failed, Z skipped)
+    * Code coverage percentage (from coverage report)
+    * Build size comparison (current vs main)
+    * Link to full logs
+  - Update the existing comment instead of posting a new one each
+    time (avoid comment spam)
+
+  Task: Write the workflow additions for all 3 channels. Include: the
+  status badge markdown for the README, the Slack notification workflow
+  job (using a Slack webhook or action), the PR comment job (using
+  actions/github-script or similar), and the logic to update existing
+  comments instead of creating new ones. Explain the trade-offs of each
+  notification approach.
+
+assertions:
+  - type: llm_judge
+    criteria: "Status badges are correct — uses the correct GitHub badge URL format (https://github.com/OWNER/REPO/actions/workflows/FILE/badge.svg?branch=main), includes multiple badges, and the markdown syntax is valid for README.md"
+    weight: 0.35
+    description: "Correct status badges"
+  - type: llm_judge
+    criteria: "Slack notification is properly conditional — only sends on main branch failures and production deploy successes, uses correct if: conditions to filter events, and the message includes all required context (commit, author, link)"
+    weight: 0.35
+    description: "Properly conditional Slack notification"
+  - type: llm_judge
+    criteria: "PR comment uses find-and-update pattern — searches for existing bot comment (by marker text or comment body pattern), updates if found or creates if not, includes test results and coverage, and the implementation uses GitHub API correctly"
+    weight: 0.30
+    description: "Smart PR comment updates"

package/courses/github-actions-cicd/scenarios/level-1/workflow-triggers.yaml

@@ -0,0 +1,56 @@
+meta:
+  id: workflow-triggers
+  level: 1
+  course: github-actions-cicd
+  type: output
+  description: "Configure workflow triggers — set up push, pull_request, schedule, workflow_dispatch, and release triggers with filters"
+  tags: [github, actions, triggers, events, schedule, workflow-dispatch, basics]
+
+state: {}
+
+trigger: |
+  You're configuring triggers for an e-commerce application's CI/CD
+  pipeline. The team needs 5 different workflow files, each with a
+  specific trigger configuration.
+
+  Workflow 1 — CI Tests (ci.yml):
+  - Run on every push to any branch
+  - Run on every pull request to the main branch
+  - Only run when source code changes (src/** or package.json), NOT
+    when only documentation (docs/**) or README changes
+
+  Workflow 2 — Nightly Cleanup (nightly.yml):
+  - Run every day at 2:00 AM UTC
+  - Also allow manual triggering for on-demand cleanup
+
+  Workflow 3 — Production Deploy (deploy.yml):
+  - Manual trigger only (workflow_dispatch)
+  - Accept an input parameter "environment" with options: staging, production
+  - Accept an input parameter "version" (required, string)
+
+  Workflow 4 — Release (release.yml):
+  - Trigger when a GitHub Release is published
+  - Should NOT trigger on draft releases or pre-releases
+
+  Workflow 5 — Dependency Update (deps.yml):
+  - Run every Monday at 9:00 AM UTC
+  - Also trigger when package-lock.json changes on push to main
+
+  Task: Write the complete 'on:' section for each workflow file. For
+  each, explain: when it will trigger, when it will NOT trigger, and
+  one common pitfall to avoid. Also explain the difference between
+  'paths' and 'paths-ignore' filters, and when to use each.
+
+assertions:
+  - type: llm_judge
+    criteria: "All 5 trigger configurations are syntactically correct — push with branch and path filters, schedule with valid cron expressions (0 2 * * * for daily 2AM, 0 9 * * 1 for Monday 9AM), workflow_dispatch with typed inputs, release with types: [published]"
+    weight: 0.35
+    description: "Syntactically correct triggers"
+  - type: llm_judge
+    criteria: "Trigger behavior is accurately explained — each workflow's trigger and non-trigger conditions are correct, the paths/paths-ignore distinction is clear, and pitfalls are practical (e.g., schedule cron runs on default branch only, workflow_dispatch only works on default branch)"
+    weight: 0.35
+    description: "Accurate trigger behavior explanation"
+  - type: llm_judge
+    criteria: "Pitfalls and edge cases are noted — mentions that paths filters don't work with schedule triggers, that release published excludes drafts, that cron schedules can be delayed by GitHub load, and that workflow_dispatch inputs have no runtime validation by default"
+    weight: 0.30
+    description: "Practical pitfalls and edge cases"

package/courses/github-actions-cicd/scenarios/level-2/concurrency-control.yaml

@@ -0,0 +1,58 @@
+meta:
+  id: concurrency-control
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Manage workflow concurrency — prevent duplicate runs, configure merge queues, and handle parallel deployments safely"
+  tags: [github, actions, concurrency, merge-queue, parallel, intermediate]
+
+state: {}
+
+trigger: |
+  Your team's CI/CD has several concurrency problems causing wasted
+  resources and deployment conflicts:
+
+  Problem 1 — Duplicate CI runs:
+  A developer pushes 3 commits in quick succession. Each push triggers
+  a separate CI run. The first 2 runs are wasted because only the
+  latest commit matters. This wastes 24 minutes of runner time per
+  occurrence, happening ~20 times per day.
+
+  Problem 2 — Deployment conflicts:
+  Two PRs merge to main within seconds of each other. Both trigger
+  deployment workflows. The deployments race — sometimes deployment B
+  starts before deployment A finishes, causing a partially deployed
+  state. Last week this caused a 30-minute outage.
+
+  Problem 3 — PR merge bottleneck:
+  With "require branch up to date with main" enabled, only one PR can
+  merge at a time. Each PR merge triggers CI again. With 15 PRs per
+  day, this creates a 2-hour queue. The team is considering GitHub's
+  merge queue feature.
+
+  Problem 4 — Resource contention:
+  Self-hosted runners (4 total) are overwhelmed during peak hours
+  (10AM-2PM). 12 workflows queue up for runners, and some time out
+  after 30 minutes waiting.
+
+  Task: Solve all 4 problems. For each, write: the root cause analysis,
+  the solution using GitHub Actions concurrency features (concurrency
+  groups, cancel-in-progress, merge queue), the workflow YAML changes,
+  and the trade-offs of each solution. Include: the concurrency group
+  naming strategy (how to scope groups by PR, branch, or workflow),
+  the merge queue configuration, and the runner capacity planning
+  recommendations.
+
+assertions:
+  - type: llm_judge
+    criteria: "Concurrency groups are correctly configured — uses concurrency with group names scoped appropriately (e.g., ci-${{ github.ref }} for CI, deploy-production for deployments), cancel-in-progress: true for CI but false for deployments, and the naming strategy prevents accidental conflicts"
+    weight: 0.35
+    description: "Correct concurrency configuration"
+  - type: llm_judge
+    criteria: "All 4 problems are solved — duplicate runs cancelled with concurrency groups, deployments serialized with concurrency (no cancel), merge queue configured to batch PRs, and runner capacity recommendations address peak load (scaling, priority queues)"
+    weight: 0.35
+    description: "All problems solved"
+  - type: llm_judge
+    criteria: "Trade-offs are explained — notes that cancel-in-progress means intermediate results are lost, serialized deployments slow down when many PRs merge, merge queue adds complexity, and runner scaling has cost implications"
+    weight: 0.30
+    description: "Trade-offs explained"

package/courses/github-actions-cicd/scenarios/level-2/conditional-execution.yaml

@@ -0,0 +1,60 @@
+meta:
+  id: conditional-execution
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Master conditional execution — use if expressions, status functions, and context variables to control when jobs and steps run"
+  tags: [github, actions, conditional, if-expressions, contexts, intermediate]
+
+state: {}
+
+trigger: |
+  You're building a sophisticated deployment workflow that must behave
+  differently based on various conditions. The workflow needs to handle
+  multiple deployment targets, branch-specific logic, and failure
+  recovery.
+
+  Scenarios to implement:
+
+  Scenario 1 — Branch-based deployment:
+  - Push to main → deploy to staging
+  - Push with tag v*.*.* → deploy to production
+  - Push to feature/* → deploy to preview environment
+  - Pull request → run tests only (no deployment)
+
+  Scenario 2 — Conditional step execution:
+  - Run database migrations only if migration files changed
+  - Send Slack notification only on failure
+  - Skip expensive E2E tests if the PR is labeled "skip-e2e"
+  - Run security scan only on PRs touching src/auth/** files
+
+  Scenario 3 — Context-based decisions:
+  - Use different AWS accounts based on environment (staging/production)
+  - Set different resource limits based on runner type
+  - Include debug logging only when triggered manually with debug=true
+
+  Scenario 4 — Error recovery:
+  - If deployment fails, automatically run rollback
+  - If rollback also fails, page the on-call engineer
+  - Always run cleanup steps regardless of failure
+  - Produce a deployment report with pass/fail status for each step
+
+  Task: Write the workflow YAML covering all 4 scenarios. For each
+  condition, explain: the expression syntax, the available context
+  variables (github.event_name, github.ref, contains(), startsWith()),
+  and the evaluation rules (when does a condition short-circuit). Include
+  a cheat sheet of the most useful conditional expressions.
+
+assertions:
+  - type: llm_judge
+    criteria: "Conditional expressions are syntactically correct — uses github.ref, github.event_name, contains(), startsWith(), success(), failure(), always(), and the expressions handle all 4 scenarios correctly including tag matching for semver"
+    weight: 0.35
+    description: "Correct conditional expressions"
+  - type: llm_judge
+    criteria: "Error recovery pattern is sound — deployment failure triggers rollback step (if: failure()), rollback failure triggers paging, cleanup runs with if: always(), and the deployment report captures status from all steps using step outcomes"
+    weight: 0.35
+    description: "Sound error recovery pattern"
+  - type: llm_judge
+    criteria: "Cheat sheet is comprehensive and practical — covers the most common 10+ conditional patterns, explains boolean logic in expressions, notes that secrets context is not available in if: conditions, and clarifies the difference between job-level and step-level if:"
+    weight: 0.30
+    description: "Comprehensive conditional cheat sheet"

package/courses/github-actions-cicd/scenarios/level-2/custom-actions-development.yaml

@@ -0,0 +1,55 @@
+meta:
+  id: custom-actions-development
+  level: 2
+  course: github-actions-cicd
+  type: output
+  description: "Develop custom GitHub Actions — build JavaScript, Docker, and composite actions for team-specific automation needs"
+  tags: [github, actions, custom-actions, JavaScript, Docker, composite, intermediate]
+
+state: {}
+
+trigger: |
+  Your team has 3 automation needs that aren't covered by existing
+  marketplace actions. You need to build custom actions.
+
+  Action 1 — "deployment-notifier" (Composite action):
+  Purpose: Post a formatted deployment summary to Slack and update
+  a GitHub deployment status. Used in 8 repos.
+  Inputs: environment, version, status (success/failure), slack-webhook
+  Behavior: Posts Slack message with deployment details, creates GitHub
+  deployment status, and writes a summary to $GITHUB_STEP_SUMMARY
+
+  Action 2 — "pr-size-labeler" (JavaScript action):
+  Purpose: Automatically label PRs by size (XS, S, M, L, XL) based
+  on lines changed. Also warn if the PR exceeds 500 lines.
+  Inputs: github-token, size-thresholds (JSON: {XS: 10, S: 50, ...})
+  Behavior: Reads PR diff stats, applies label, posts warning comment
+  if over threshold
+
+  Action 3 — "security-context-check" (Docker action):
+  Purpose: Scan environment for leaked secrets, check that no
+  hardcoded credentials exist in the code, and verify .env files
+  aren't committed. Runs in an isolated Docker container for security.
+  Inputs: scan-paths, exclude-patterns, severity-threshold
+  Outputs: findings-count, report-path
+
+  Task: Build all 3 actions. For each, write: the action.yml metadata
+  file, the implementation (shell script for composite, index.js for
+  JavaScript, Dockerfile + entrypoint for Docker), the test strategy
+  (how to test custom actions), and the publishing approach (how to
+  version and release). Compare the 3 action types: when to use each,
+  performance differences, and maintenance considerations.
+
+assertions:
+  - type: llm_judge
+    criteria: "action.yml files are correctly structured — each has proper name, description, inputs with types/defaults/required, outputs where applicable, runs section matching the action type (composite/node20/docker), and branding metadata"
+    weight: 0.35
+    description: "Correct action.yml structure"
+  - type: llm_judge
+    criteria: "Implementations are functional — composite action uses correct shell syntax with ${{ inputs.* }}, JavaScript action uses @actions/core and @actions/github packages correctly, Docker action has proper Dockerfile and entrypoint script receiving inputs as env vars"
+    weight: 0.35
+    description: "Functional implementations"
+  - type: llm_judge
+    criteria: "Comparison helps decision-making — explains when to choose composite (simple, no build step), JavaScript (rich API access, fast startup), or Docker (isolation, any language), and covers testing strategies, versioning with tags, and the marketplace publishing process"
+    weight: 0.30
+    description: "Decision-helping comparison"