claude
fbec36cb67
Scaffold the course repo and author the full curriculum in dependency-chain order, following the settled build decisions in handoff.md. - Scaffold: course README, vendor-neutral AGENTS.md (dogfoods Module 5), _TEMPLATE.md (the fixed 9-section module shape), root .gitignore, ship config. - Modules 1-2: reference exemplars (locked for tone/depth/lab style). - Modules 3-27: full lessons + runnable labs, each following the template, respecting the chain, vendor/model-agnostic, with "feel the pain" labs. - Module 8 hosting comparison web-researched and date-stamped (as of 2026-06-22), not written from memory; expansion-zone modules carry Verify-before-publish. - Capstone: the full loop end to end on the running tasks-app example. Lab code syntax-checked (Python/shell/YAML); every module has the 7 core template sections. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TfzV5QvtPDz8LJS3Pu5VLT
23 lines
919 B
YAML
23 lines
919 B
YAML
# The SAME pipeline as ci-starter.yml, written for GitLab CI instead of GitHub Actions.
|
|
#
|
|
# The point of having both side by side: CI is a concept, not a product. Checkout, set up the
|
|
# language, install tools, lint, test — every forge does these. Only the YAML dialect and the
|
|
# magic filename differ.
|
|
#
|
|
# Where this file goes: GitLab reads a single file named .gitlab-ci.yml at the repo root. Copy this
|
|
# there, commit, and push. (Other forges: Forgejo/Gitea use .forgejo/ or .gitea/workflows/ with
|
|
# Actions-compatible YAML; Bitbucket uses bitbucket-pipelines.yml. The shape rhymes everywhere.)
|
|
|
|
stages:
|
|
- check
|
|
|
|
check:
|
|
stage: check
|
|
# The runner image — a throwaway container with Python already installed. The GitLab equivalent
|
|
# of "runs-on: ubuntu-latest" plus "set up Python".
|
|
image: python:3.12
|
|
script:
|
|
- pip install pytest ruff
|
|
- ruff check . # lint
|
|
- pytest -q # test
|