Files
werkator/docs/prs/2026-10-09-PR#132-ci-true-in-every-build.md
claude-code cbdaaacc74
werkator build succeeded after 03:27
werkator/deploy build succeeded after 00:13
CI=true in every build (v1.38.0) (#132)
Co-authored-by: claude-code <claude-code@javagil.de>
2026-10-09 21:29:20 +02:00

2.8 KiB

PR#132: CI=true in Every Build

WARNING: This document describes only the change applied in this PR. It may already be outdated once the next PR is merged. Historic PR-documentation is not maintained along with new PRs — treat it as a snapshot, not as current documentation.

The Problem

Many build tools ask the variable CI whether they run unattended. Test runners then run once instead of watching, package managers ask nothing, and progress bars do not fill the log. Forgejo Actions, GitHub Actions, GitLab and Jenkins set it; Werkator did not. A build that works on another CI system could therefore hang on a prompt or flood its log on Werkator.

RFC 0006 step 2 lists CI=true together with the GITHUB_* and FORGEJO_* variables. Only CI is useful on its own: the other names help only scripts written for another system, and no project on Werkator has one.

Non-Goals

  • No GITHUB_* or FORGEJO_* variables; they wait until a project brings a script that reads them.
  • No new configuration key.

The Scenarios

Feature: The environment of a build

Scenario#132.01: Every command of a build runs with CI=true

So that build tools run unattended on Werkator, as they do on any other CI system.

  • Given a build with a clean command and a build command
  • When the build runs
  • Then both commands see CI=true
  • This holds natively, in the Docker container and in the werkdock sandbox, because all three runners pass the same build environment on.
Verified by

Scenario#132.02: A sandbox environment may set another value

So that a build that must not run in CI mode can still say so.

  • Given a build definition that sets CI=false in the environment of its Docker container or werkdock sandbox
  • When the build runs
  • Then its commands see CI=false
Verified by

The Solution

  • BuildExecutor.buildEnvironment puts CI=true next to branch into every build environment.
  • The runners already pass this environment on: natively into the process, as --env to docker run, as -e to werkdock run, which becomes bwrap's --setenv.
  • docs/configuration.md gets the section "What a build finds in its environment", which also names the variables Werkator set before.
  • The version is 1.38.0: a build behaves differently, so this is new behaviour, not a fix.