Unit 0. Welcome to the course

Handing work in

Every unit with a notebook can be handed in. Week 0 is a record of the work and is never marked. Every session carries marks, scored from what its checks print. Two sessions are assistant-driven, so nothing can re-run them and the output you saved is the evidence the marks rest on — save the notebook before you submit.

What each command does

Nothing here is magic, and none of it touches the course repository.

Command What it does
uv run bootcamp check ch03 Runs your notebook in a separate process and prints which exercises passed. It never writes to your file — so a green check is not yet evidence
uv run bootcamp submit ch03 --github <you> Reads the notebook as saved on disk and writes submissions/<you>/ch03/ — the claim plus the exact notebook it is a claim about. Refuses a notebook with nothing in it
… --push The same, and then hands it in for you — three steps, spelled out below
uv run python scripts/verify_submission.py submissions/<you>/ch03 The check CI will run, on your machine first: re-runs the notebook and compares what it prints against what your claim says
gh auth login Signs the GitHub CLI in, once, so --push can act as you

The one that catches people: check runs your notebook, submit reads your file. They are different, which is why a passing check and an empty submission can both be true at the same time — save the notebook before you submit.

What --push actually does, in three steps

  1. It writes a folder with your submission in it — submissions/<you>/ch03/, holding the claim and the exact notebook the claim is about. That part happens with or without --push, and you can open the folder and look at it.
  2. It makes a fork. A fork is your own copy of a repository, under your own GitHub account. You cannot write to the course's submissions repository — nobody can — so you write to your copy instead. This happens once, ever; after that the fork already exists and the step does nothing.
  3. It opens a pull request on the original repository. A pull request is a request to take the change in your copy and put it in theirs — which is exactly what handing work in is. The command prints the link.

CI then checks the shape of what you sent, and a green pull request is merged automatically. Nobody has to be asked, and nothing needs to happen in a browser.

The short way

uv run bootcamp check ch03                              # what passes, what does not
uv run bootcamp submit ch03 --github <you> --push       # and hand it in

--push forks the submissions repository if you have not already, copies the bundle in, commits, pushes, and opens the pull request. It prints the URL. You never touch git.

Re-submitting updates the same pull request rather than opening a second one, because handing in again is the normal case and not a mistake.

It needs the GitHub CLI, which is one install and one sign-in:

# https://cli.github.com
gh auth login

Without it, --push tells you exactly that and stops. Your bundle is already written either way — it is never a dead end, only a longer route.

The long way, which is the same thing by hand

uv run bootcamp submit ch03 --github <you>       # writes submissions/<you>/ch03/

The bundle holds two files: submission.json, the claim, and notebook.ipynb, the evidence. CI checks the shape, that the folder is yours, that the notebook is the file the claim was written against, and that the score follows from the passes and help the claim lists.

No gh? Hand it in from your browser

No GitHub CLI and no git needed. Two things decide whether it works: the repository and the path.

  1. Open Gecko-Academy/dev3pack-submissions and click Fork. This is the submissions repository.

  2. In your fork, open the submissions folder.

  3. Click Add file → Upload files. From your course folder, drag in the folder submissions/<you> — the one submit just wrote.

  4. Check the paths before you continue. The files must end up at:

    submissions/<you>/ch03/notebook.ipynb
submissions/<you>/ch03/submission.json

  5. Choose Create a new branch, click Propose changes, then Create pull request. The base repository must be Gecko-Academy/dev3pack-submissions.

A green check means accepted.

The two mistakes we see most:

Mistake What happens Fix
The pull request is on dev3pack-cohort-2026-09, the course repository Nothing is checked or marked. It is closed with a note Open it on dev3pack-submissions instead
The files are at ch03/… instead of submissions/<you>/ch03/… No check runs, and the pull request waits for ever Upload the folder inside submissions/, as in step 3

Do not commit your notebooks or submissions/ to your copy of the course: the course repository is read-only for everyone, and submissions/ is ignored there on purpose.

Using gh by hand? gh pr create needs --body, or it hangs waiting for input you cannot see.

Merging is automatic: a job merges every green pull request and rebuilds the public track. It is scheduled every half hour, but GitHub does not honour that on a quiet repository — runs have been two to five hours apart. Green means accepted; the score appearing on the track can take a few hours, and nobody needs to be asked.

Before you open the pull request you can run the same check CI will:

uv run python scripts/verify_submission.py submissions/<you>/ch03

It runs your notebook and compares what it actually prints against what your file claims.

Submitting again replaces the earlier attempt. Nothing is locked, and nothing is lost: the history is the pull requests.

← Give the course to your assistantWeek 0 — the prerequisite →