Skip to content

Qualify the complete build runner on native Machines #809

Closed as not planned

Description

@nick-potts

Parent

Build runner spec (#798)

What to build

Qualify the assembled feature through the existing release process and close the evidence gaps that require real Machines. Earlier tickets own their own regression tests; this ticket proves their composition and packaging, not a deferred generic test suite or a new execution engine.

Acceptance criteria

  • Run the user-visible Dockerfile and Railpack workflows from packaged musl CLI/daemon artifacts on real Machines. Cover local default, explicit remote target, automatic remote selection and local override; remote operation must not require a local Docker daemon. Test the tools actually provisioned by the product, not a manually prepared developer-only stack.
  • Build and Deploy a Railpack application across native AMD64 and native ARM64 Machines, inspecting complete source content and destination-selected variants, then running the application with external-registry fallback disabled. Include an incomplete peer and prove it cannot supply an absent variant. Exercise both recipes' single-platform output and the deliberate multiple-platform Dockerfile refusal.
  • Verify the composition of fixed source, separate private variables/provider-once behavior, Service image dependencies, exact-image identity across requested-tag reuse, all-Builds-before-application-mutation, per-Machine transfer outcomes, ordinary/Data Loss Confirmation, and prepare-once Deploy. Cover changed platform requirements without automatic rebuilding or application relocation.
  • Exercise admitted and queued cancellation/disconnect, daemon restart, timeout and resource policy through packaged tools, including truthful unknown termination and safe subsequent reuse. Demonstrate persistent cache across builder recreation and deliberate cache clearing without unrelated Docker-data loss. Reuse lower-rung evidence rather than duplicating every policy permutation on real Machines.
  • Use the existing rung-5 release qualification process and register any new rung-4 informing binaries correctly. Record exact artifact/tool versions, native hardware/platform observations, runnable commands, completed/failed/unattempted cases and evidence links. Update product-path evidence only for tests that exist and pass; the retained prototype and emulated ARM64 never count as release Authority.
  • Document the actual supported Compose options, recipe/location defaults, registry-free delivery, host limits/cache controls, cancellation/queue behavior and explicit v1 refusals alongside the user-facing workflow. Do not claim Cloud/polling/provider support, full Compose compatibility, hard disk quotas, or hardened untrusted multi-tenant execution.
  • Confirm the final implementation still exposes capture and execute rather than leaking per-platform, upload or cleanup orchestration into callers. Remove temporary busy refusals and any now-unused transition paths left by earlier slices. Rust fixes follow the required implementation and incremental four-axis-review workflow; documentation/qualification scripts alone do not trigger a Rust review gate.

Blocked by

Activity

  1. nick-potts commented on Sep 29, 2026

    @nick-potts
    ContributorAuthor

    This relied on rung-5 qualification, which #1005 deleted, and the --remote/--local workflows it would check went in #1031. The 0.2.0 gate is CI plus using the beta on real Machines through Cloud.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    ready-for-agentFully specified, ready for an AFK agent

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions