Skip to content

FLIGHTCONTROL.md

Latest commit

 

History

History
65 lines (52 loc) · 2.76 KB

FLIGHTCONTROL.md

File metadata and controls

65 lines (52 loc) · 2.76 KB
Raw

Flightcontrol fork notes

This is a fork of railwayapp/railpack, maintained to carry the Flightcontrol-specific frontend behavior described below.

Registry cache imports

buildkit/frontend.go never populated CacheImports on its own internal client.SolveRequest calls, so docker buildx build --cache-from / --cache-to never reached the vertices railpack-frontend defines. Export worked (that's driven by the outer solve, not the frontend), but import never produced a single cache hit, even across consecutive builds of an unchanged repo.

See buildkit/frontend.go's parseCacheImports/parseCacheFromRefs for the fix. It merges two sources, in order of reliability:

  1. A cache-from build-arg (--build-arg cache-from=<ref>[,<ref>...]) - the mechanism our own CI pipeline uses, since it already controls cache-key/secrets-hash/github-token the same way and doesn't depend on unverified BuildKit-internal opt forwarding.
  2. The cache-from / cache-imports FrontendOpt keys the standard Dockerfile frontend reads (github.com/moby/buildkit/frontend/dockerui), as a best-effort bonus in case BuildKit does forward these to external gateway.v0 frontends in some invocation paths - kept for correctness with upstream behavior, not required for our own use.

Artifact-only exports

The frontend accepts an export-path build argument containing an absolute path in the final deploy filesystem. When set, the frontend returns a scratch state containing only that directory. Flightcontrol static builds combine this with BuildKit's local exporter to avoid serializing and loading the full runtime image solely to copy static assets back out.

docker buildx build \
  --build-arg export-path=/app/dist \
  --output type=local,dest=extracted-static \
  -f railpack-plan.json .

Structure

  • main mirrors railwayapp/railpack:main untouched, for easy diffing/merging against upstream.
  • flightcontrol/v<version> branches carry Flightcontrol's patches rebased onto each upstream release tag we actually run in production (older branches may retain a patch-specific suffix). The image we publish is always built from one of these branches, never from main.

Rebuilding after an upstream version bump

git fetch origin
git checkout -b flightcontrol/v<new-version> v<new-version>
git cherry-pick <flightcontrol-patch-commits>
docker build --platform linux/amd64 -f images/alpine/frontend/Dockerfile -t <registry>/railpack-frontend:v<new-version>-fc<N> .
docker push <registry>/railpack-frontend:v<new-version>-fc<N>

Then update the immutable frontend tag and its matching feature gate in packages/tower-go/pkg/steps/ci/build_helpers/railpack_instructions.go in the Flightcontrol monorepo.