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_*orFORGEJO_*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=falsein the environment of its Docker container or werkdock sandbox - When the build runs
- Then its commands see
CI=false
Verified by
- DockerBuildRunnerUnitTest: assembles the exact docker run command
- WerkdockBuildRunnerUnitTest: adds the sandbox env after the branch environment
The Solution
BuildExecutor.buildEnvironmentputsCI=truenext tobranchinto every build environment.- The runners already pass this environment on: natively into the process, as
--envtodocker run, as-etowerkdock run, which becomes bwrap's--setenv. docs/configuration.mdgets 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.