Skip to content

Add sampo distribute mode for artifact distribution #111

@goulvenclech

Description

@goulvenclech

Describe the problem

Our release workflow always builds binaries before we know whether a release actually ships, and once sampo publish runs we manually move artifacts into GitHub Releases or other channels. Without a single source of truth, every distribution step re-derives which crates changed and where binaries live, duplicating logic that Sampo already knows.

What's the proposed behaviour?

Introduce sampo distribute (accessible via sampo-github-action --mode distribute) as the post-publish phase. It would read the release plan and the tags produced earlier, then:

  • execute user-defined build scripts/commands for each (crate, target) that needs artifacts (See BIG LIMITATION below)
  • push the resulting binaries to configured destinations

The first backends to implement:

  1. GitHub Release – automatically upload freshly built binaries to the release entries created during sampo publish.
  2. Custom Target – run an arbitrary user command, passing the binary path once the build succeeds.

Longer term, additional adapters should cover OS registries (apt, dnf, pacman, Homebrew, AUR, etc.) and artifact repositories (S3, CDN, internal buckets). Sampo remains the SSOT that decides when distribution is required, while adapters encapsulate the API calls or git pushes needed to publish binaries.

Open questions

  • BIG LIMITATION: the action can’t inject matrix entries on its own, so the workflow still owns the matrix definition... Probably something like :
  build:
    needs: release
    if: ${{ needs.release.outputs.build-matrix != '' }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix: ${{ fromJson(needs.release.outputs.build-matrix) }}
    steps:
      - uses: actions/checkout@v4
      - run: ./scripts/build.sh ${{ matrix.crate }} ${{ matrix.target }}

Using the sampo release output from the action's auto ou release mode. And then the distribute mode take the freshly built artifacts, and distribute them.

  • What should the configuration format look like? A [distribution] table with per-target entries? Or introcing a general-purpose sampo.toml for crate-specific configuration? (Could be useful for other features)
  • How do we report failures granularly so CI can retry a single backend without re-running builds?

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2 - highBugs that violates the documented behavior.RFCProposed feature or change - open for feedbackcrt:sampoChanges in Sampo CLI crate.crt:sampo-coreChanges in Sampo core logic or internal utils.crt:sampo-github-actionChanges in Sampo's Github action crate.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions