2.8 KiB
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
A branch could describe its tests but could not build downloadable samples after they passed. All follow-up triggers were pinned, even when the follow-up inherited the same sandbox as the tests. Deployment authority and ordinary build dependencies need different rules.
Non-Goals
This change does not install Keluna's desktop build environment or enable ARM64 compilation. It does not change sandbox policies, credential access or follow-up scheduling semantics.
The Scenarios
Feature: Branch-owned sandboxed follow-ups
Scenario#74.01: Build samples after successful tests
- Given a host-enforced Docker or Werkdock sandbox
- When a branch defines a sample build after its test build
- Then the sample build inherits the sandbox and runs at the successful test's commit
- And the branch can change an existing ordinary follow-up's predecessor and selectors
Verified by
Scenario#74.02: Keep deployments under host control
- Given an explicit host trigger or a follow-up with host execution, Docker socket access or instance restart
- When a branch tries to add or override its dependency
- Then the host policy remains in effect
- And sandboxed deployment triggers explicitly configured on the host stay pinned too
Verified by
Scenario#74.03: Reject cyclic dependencies
- Given a branch defining sandboxed follow-ups
- When their dependencies form a cycle
- Then configuration validation refuses that branch configuration
Verified by
The Solution
Keep track of trigger blocks explicitly authored in instance defaults, the applied fragment and the repository's machine configuration. Pin these blocks regardless of the sandbox. Allow branch-owned follow-up dependencies only under the primary configuration's inherited sandbox policy, without Docker socket access or instance restart. Preserve default sandbox flags even when a named build overrides only an environment variable and the branch removes its default definition. Existing cycle validation and follow-up execution at the predecessor's commit remain in place.
Additional Changes
Version 1.19.0 documents the new behavior in the release notes, configuration reference and init template.