Lab: turn local Python tests into a reviewable CI check

Use the small project you already understand

Create a practice GitHub repository containing the Python module lab's three source files and tests/test_capacity.py at the root. Run the five tests locally first. No AWS account, MicroBank secrets, or Docker engine is required for this CI exercise.

Save .github/workflows/ci.yml:

name: Capacity fixture checks
on:
  push:
  pull_request:
permissions:
  contents: read
jobs:
  test:
    runs-on: ubuntu-24.04
    timeout-minutes: 5
    steps:
      - name: Check out source
        uses: actions/checkout@d23441a48e516b6c34aea4fa41551a30e30af803
        with:
          persist-credentials: false
      - name: Set up Python
        uses: actions/setup-python@ece7cb06caefa5fff74198d8649806c4678c61a1
        with:
          python-version: '3.12'
      - name: Run the fixture tests
        run: python -m unittest discover -s tests -v

These immutable SHAs were resolved from the official actions' v6 tags on 30 September 2026. Review action updates deliberately rather than replacing them with an unverified SHA. Runtime versions and runner images still need maintenance; SHA pinning alone does not freeze the entire environment.

Observe a real failure

Commit to your practice repository using its normal workflow. Check the event, source revision, runner, Python version, discovered test count, and conclusion. In a branch, deliberately change one assertion to the wrong expected value, observe the check fail, then correct it and compare the next run. Keep this fault injection out of a real release branch.

A workflow file sitting locally has not run on GitHub. If you do not execute the remote workflow, record “workflow prepared; hosted run not executed” and keep the local test evidence separate.

Read the workflow from inputs to result

Checkout makes the selected revision available on the runner. persist-credentials: false avoids leaving the checkout credential configured for later Git commands. Setup selects Python 3.12. The final step runs standard-library tests, so this small repository needs no package installation, cache, registry credential, or cloud login.

Use only the listed capacity files for the five-test baseline. If you deliberately add the earlier HTTP tests, record the new count and their separate scope. In the hosted log, identify the assertion that failed during the controlled bad change; a generic red conclusion is less informative than knowing which expected behavior was violated.

After correcting the assertion, confirm the successful run refers to the corrected source commit. Looking at a different green run does not establish that the broken branch was fixed. Keep the prepared-file, local-test, and hosted-run claims separate when a hosted run was not performed.

Plan the build and deployment stages

Write a proposed build/publish/deploy sequence for the container fixture. Specify an owned registry, image digest handoff, required checks, approval policy, and rollback evidence. Do not add cloud credentials or deployment permissions to this test-only workflow. MicroBank needs service-specific real test commands before adopting the same structure.

Checkpoint and cleanup

Explain why five discovered tests matter, why a failed command must fail the job, and why successful CI is not a completed deployment. Remove the deliberate bad assertion and close any practice PR through the normal repository process. Retain the workflow and evidence or retire the practice repository intentionally.

Revision: local proof → committed workflow → observed hosted run → failing control → corrected result → separately designed delivery.

Apply this to MicroBank

After the six foundations modules, build MicroBank artifacts and deploy a selected revision locally. Start with the project setup and follow its ordered steps; later implementation stages depend on the earlier files.

Sources and practice status

Primary references: Official checkout action↗; Official setup-python action↗; Testing Python with GitHub Actions↗.

Reviewed against documentation on 1 October 2026. The exercises still need to be run in your environment. Record your results and tool versions in your notes.