Skip to content

Publish the installer artifacts to the static host on release #35

Description

@ExtraToast

Parent

Epic: https://github.com/JorisJonkers-dev/fleet-infra/issues/224 (fleet-infra)

What to build

Every released installer artifact present on the estate's public static host,
published by CI, and proven present by fetching it back.

Scope corrected 2026-09-14. #40 makes setup-workstation.sh the single
installer and retires install.sh, so publishing install.sh and
install-agents.sh would put a script on the public host that is about to
die. The artifacts are:

  • installer/setup-workstation.sh, generated from
    registry/estate-tooling.yaml, which has never been served at all;
  • the first-party skills bundle that script needs when it runs from
    curl | bash with no checkout — Make setup-workstation.sh a true superset and retire install.sh #40's KIT_ROOT gap is fixed by fetching
    this bundle rather than resolving a path from $0.

The order is #40, then this ticket, then #36.

Two estate rules shape the workflow:

  • A merge does not guarantee a workflow ran, and an upload exiting 0 does
    not prove the object is readable.
    Verify by fetching the published URL
    back and comparing the version token inside it against the release.
  • Jobs are billed by the minute, rounded up. One job with many steps, each
    carrying if: ${{ !cancelled() }} so a single failure still surfaces the
    rest. Splitting three uploads across three jobs triples the bill for
    identical work.

Credentials are the Garage access key from the bucket ticket, held as Actions
secrets. Nothing in the published artifacts is secret - that is the premise -
but the write credential is.

Acceptance criteria

  • curl -fsSL https://<host>/setup-workstation.sh | head -1 returns the
    script, with no Authorization header.
  • The published artifact's version token matches the release that
    published it, checked by CI and not by eye.
  • The skills bundle is published alongside it, and a piped run fetches and
    installs from it.
  • install.sh and install-agents.sh are not published.
  • Re-running the workflow on the same release is a no-op that still
    verifies.
  • The publish runs as steps of one job.

Blocked by

Activity

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

Metadata

Metadata

Assignees

Labels

area: toolingReusable workflows, Gradle, templates, Renovate, and API tooling.component: ciContinuous integration workflow or check behavior.priority: P1High; important and should be handled in the current iteration.status: blockedCannot move forward until an external dependency is resolved.type: featureNew user-facing or operator-facing capability.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions