Skip to content
All posts
2 min readtebakopackagingtutorial

Basic payloads: Publish to your users (5 of 5)

The basic payloads series, hands-on: publish to your users.

The Tebako team

github.com/tamatebako
Note

Post 5 of 5 in the series Basic payloads.

○ ○ ○ ○ ●

  1. Basic payloads: Run your first package

  2. Basic payloads: Data payloads: make one, read one

  3. Basic payloads: Package a Ruby application

  4. Basic payloads: Package a Rails or Sinatra application

  5. Basic payloads: Publish to your users (this post)
Note

Reference guide: Publish to your own registry and Check a payload.

The last subject in this series is the hand-off: moving a payload from the packager’s machine to its users. The work has three steps — prove the payload, publish it, and let users install it — and every step is a command.

Build your own feedstock recipe + CI release artifacts + registry one YAML file, press one executable shim a command on SHA256SUMS your own repo per platform the user PATH every hop is gated payload checks: the release proves it works before anything downstream sees it no central server anywhere your releases are the store; the registry only mirrors resolution fields

Figure 1 — The pipeline: the packager builds and checks the payload, publishes it to their own release, and users install it from that registry.

Prove it: checks

A payload can carry its own acceptance test, declared in its manifest:

checks:
  smoke:
    entry: /bin/myapp
    argv: ["--version"]
    expect: { exit: 0, stdout: ["myapp"] }
    timeout: 30
$ tebako check ./myapp
slice myapp: smoke PASS 2s

A missing prerequisite skips with a reason and never fails; a real failure exits with code 79 and names the expectation that failed. When the checks run in CI, a broken payload cannot reach users.

Publish it

Publishing writes a registry — one YAML file — onto the publisher’s own release, with a SHA-256 beside every artifact:

$ tebako publish --name myapp --version 1.0.0 \
    --release tfs:github:acme/myapp:v1.0.0 \
    --payload universal=dist/myapp-1.0.0-universal.tfs
published myapp 1.0.0 -> tfs:github:acme/myapp (tag v1.0.0)
sha256 9f2c…a1  myapp-1.0.0-universal.tfs

No server and no store are involved: the publisher’s releases are the registry.

Your users' side

They add your registry once and install — and what they receive is the shim from the first post:

$ tebako add-registry tfs:github:acme/myapp
$ tebako install myapp
$ myapp --version
myapp 1.0.0

Versions are theirs to pin:

$ TEBAKO_MYAPP_VERSION=0.9.2 myapp   # per invocation
$ tebako-shim which myapp            # what resolves right now
$ tebako-shim doctor                 # is everything healthy

A .tebako-tools.yaml file in a project pins versions for the whole project. The shims guide covers the full surface.

What you can do now

The series has covered the complete arc: running a package, making a data payload, packaging applications — Ruby, Rails, and Sinatra — checking them, and publishing them. The advanced payloads series picks up exactly where the basics end: tracing, jails, image formats, native code, and the most demanding payload in the series.

Note

This is the end of the series Basic payloads. Continue with Advanced payloads, part 1 next.