{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigtigxbadyogmbmwstbc4ave44fvtv4ymlltuegwurr46ve6m4tgq",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3molepsnqj5o2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreif53snzstlvzt2zhd4nyqtz4kk6gcjgdpaex5hb5p4obkq45fuigy"
    },
    "mimeType": "image/webp",
    "size": 63260
  },
  "path": "/oranguengineer/add-ci-when-the-project-can-boot-not-when-it-feels-finished-20m9",
  "publishedAt": "2026-06-18T16:58:51.000Z",
  "site": "https://dev.to",
  "tags": [
    "buildinpublic",
    "cicd",
    "githubactions",
    "devops",
    "Knot Forget",
    "Threads"
  ],
  "textContent": "I did not add CI to Knot Forget before the Django project existed. There would not have been much point: nothing meaningful to install, lint, or test.\n\nI added it at the first moment where it could prove something useful. The project could boot, dependencies were managed, settings loaded, Ruff had rules to enforce, and pytest could run a smoke test against a minimal home view. There was still no domain logic, no models, no real API, and no feature work worth protecting by hand.\n\nThat timing is the part I care about.\n\n> Add CI after the project has a real baseline, but before the codebase feels important enough for exceptions.\n\n##  The first pipeline should be boring\n\nThe first CI pipeline does not need to predict the future. Mine has two jobs: `lint` and `test`.\n\nThe `lint` job installs the project dependencies, runs Ruff checks, and verifies formatting. The `test` job installs the same dependencies and runs pytest. There is no deployment step, no Docker image publishing, no coverage threshold, and no database service yet. Those can come later, when the project actually needs them.\n\nAt this stage, CI has a narrower job: make every pull request prove that the project still has a working baseline.\n\n\n\n    name: CI\n\n    on:\n      push:\n        branches: [main]\n      pull_request:\n        branches: [main]\n\n    jobs:\n      lint:\n        runs-on: ubuntu-latest\n        steps:\n          - uses: actions/checkout@v4\n          - uses: astral-sh/setup-uv@v6\n            with:\n              enable-cache: true\n          - run: uv sync --frozen\n          - run: uv run ruff check .\n          - run: uv run ruff format --check .\n\n      test:\n        runs-on: ubuntu-latest\n        env:\n          DJANGO_SECRET_KEY: ci-dummy-secret-key-not-used-in-production\n        steps:\n          - uses: actions/checkout@v4\n          - uses: astral-sh/setup-uv@v6\n            with:\n              enable-cache: true\n          - run: uv sync --frozen\n          - run: uv run pytest\n\n\nThe stack is specific to this project: GitHub Actions, uv, Ruff, pytest, Django. The shape is not. Install the project reproducibly, check the code, run the tests, and keep the first version small enough that a failure means something.\n\nA complicated first pipeline is easy to explain away. A boring one is harder to argue with.\n\n##  A check that is not required is only a suggestion\n\nAdding a workflow file is not the whole job. If CI runs but failed checks do not block merging, the pipeline is mostly informational: useful, but not structural. It tells you something went wrong, then leaves the decision to whoever is tired enough to merge anyway.\n\nThe important step is making the checks required on `main`.\n\nFor Knot Forget, the branch ruleset requires both `lint` and `test` before a pull request can merge. Once that is true, CI becomes part of the repository contract. Nobody has to remember to ask whether the checks passed, and nobody has to decide whether this lint failure is acceptable because the change is small.\n\n> The repository answers before the merge button does.\n\nThat matters even on a solo project. Especially on a solo project. The person most likely to bypass a weak process is usually the same person who created it, late in the evening, convinced the patch is harmless.\n\nRequired checks remove that negotiation.\n\n##  CI caught the first missing piece immediately\n\nThe first version of the workflow did not include an `env` block in the `test` job.\n\nLocally, tests passed. That made sense: my machine already had the project environment in place. The `.env` file existed, the settings could read what they needed, and Django could start.\n\nThen CI ran for the first time, on a clean GitHub runner, with only the repository and the workflow instructions available. The test job failed before it reached any meaningful application behavior. Django tried to load settings, settings required `DJANGO_SECRET_KEY`, and the runner did not have one.\n\nThat was not a problem with CI. That was CI doing exactly what I added it to do.\n\n> The first useful thing CI did was disagree with my machine.\n\nThe pipeline had found a real assumption: the project needed an environment variable to boot, and the workflow had not declared it. Without CI, I could have kept running tests locally and missed that detail for longer, because the code looked healthy on the one machine that already had the missing piece.\n\nThe fix was small:\n\n\n\n    test:\n      runs-on: ubuntu-latest\n      env:\n        DJANGO_SECRET_KEY: ci-dummy-secret-key-not-used-in-production\n      steps:\n        - uses: actions/checkout@v4\n        - uses: astral-sh/setup-uv@v6\n          with:\n            enable-cache: true\n        - run: uv sync --frozen\n        - run: uv run pytest\n\n\nThe important part is not that the value is fake. Of course a test job should not use a production secret. The important part is that the test job now declares what the project needs in order to start.\n\nThat is what even a basic CI pipeline gives you. With only `lint` and `test`, the repository has to prove that a fresh runner can install the project, check the code, and run the test suite. That is a stronger statement than \"it works on my laptop\". It means the code works from the instructions committed to the repo.\n\n##  The smoke test is the first contract\n\nAt this point in the project, there was not much behavior to test. That was fine. The smoke test only needed to prove that Django could start and serve the minimal home view; it was not pretending to validate domain behavior that did not exist yet.\n\nThat small test still carried weight. It forced the settings module to load, forced required environment to be present, and made CI exercise the same bootstrap path future tests will build on.\n\nA first smoke test is not about coverage. It is about proving the project can stand up in a clean environment.\n\nThat phrase matters. Local tests are necessary, but they are not enough to prove bootstrap. Your machine accumulates state: a `.env` file exists because you created it earlier, a dependency may already be installed, a shell variable may still be set. A command can pass locally for reasons that are not visible in the repository.\n\nCI removes most of that accidental help. For a new project, one smoke test on a clean runner can reveal missing setup assumptions before they harden into undocumented project knowledge.\n\n##  CI has to run once before GitHub can require it\n\nThere is one awkward detail in GitHub branch protection: a status check has to exist before it can be selected as required.\n\nSo the sequence is not quite \"decide the check names, require them, then add CI\". In practice, it is closer to this: add the workflow, open a pull request, let the jobs run once, fix whatever the clean runner exposes, then add the resulting `lint` and `test` checks to the branch ruleset.\n\nThat first run is not just ceremony to make GitHub display the check names. It is the first clean-room execution of the project. It is where missing environment, incomplete setup instructions, and false local assumptions show up.\n\nOnce that run is green, requiring the checks means something. You are not requiring an imagined pipeline. You are requiring a command path that has already survived outside your machine.\n\n##  The timing is the decision\n\n\"Set up CI from day one\" is close, but not quite the rule I would use.\n\nDay one might be too early. Before the project can boot, CI is mostly ceremony: you can add an empty workflow, but it does not protect much. \"Set up CI later\" is worse, because later usually means after feature work begins, after conventions have started drifting, and after local assumptions have become invisible.\n\nThe useful moment is in between.\n\nAdd CI when the project can boot: when there is one real command to lint, one real command to test, and one minimal path through application startup. Then run those commands somewhere clean enough to disagree with your machine.\n\n> That disagreement is the point.\n\nIn my case, the first CI run immediately caught that the test job was missing `DJANGO_SECRET_KEY`. The fix was one line, but the signal was larger: the project was not fully reproducible from the repository yet.\n\nThat is why I want CI as soon as the project can meaningfully pass through it. Not because the pipeline is mature, and not because there is much behavior to test yet, but because even a small `lint` + `test` pipeline forces the code to prove it works somewhere clean.\n\n_Building Knot Forget in public · Threads_",
  "title": "Add CI When the Project Can Boot, Not When It Feels Finished"
}