Bosca / Artifacts

Platform integration

The registry your releases wait on

Because the registry is part of the platform, a published version isn't a file on a shelf — it's a signal. CI gates open on it, events carry it, and the models behind your recommendations ship through it.

CI requirement gates

Builds that wait for the right artifact

A CI job can require an artifact — a Maven coordinate at an exact version — and it won't dispatch until the registry has it.

  • The run shows waiting on artifacts until the requirement is met, then dispatches — no polling loops, no retry scripts.
  • Publish events re-evaluate waiting jobs the moment a version lands.
  • A setup-registry step points the job's build tools at a registry repository, so publishing from CI is an ordinary gradle publish.
  • That's how cross-repo releases order themselves: downstream builds gate on the upstream artifacts they compile against.
release.yaml
jobs:
  build-and-publish:
    runner: linux
    requires:
      - type: maven
        namespace: bosca-maven
        coordinate: "io.bosca:core:${{ version }}"
        timeout: 60m
    steps:
      - uses: setup-registry
        with:
          repository: bosca-maven

Publish events

Publishes are platform events

Every publish is announced on the platform's pub/sub — the same signal the CI requirement gate listens for, available to any service that subscribes.

  • Every published version fires bosca.artifacts.version.published with the namespace, repository, type, and version.
  • Docker fires on tag updates too — re-pointing latest is a publish.
  • One event shape across all six formats, serialized like every other platform event.
bosca.artifacts.version.published
{
  "namespace": "library",
  "repository": "api",
  "type": "docker",
  "version": "sha256:9f86d081…"
}

Models & management

Models ship like any other artifact

The registry isn't only for code you deploy — it's where the platform keeps the ML models it serves, and it's managed with the same tools as everything else.

  • Recommendation models are versioned archives in an ml repository — published after training, pulled for serving, from the same registry as your images and jars.
  • A dedicated service principal with narrowly-scoped push and pull tokens is provisioned automatically on first boot.
  • Studio manages the registry end to end: namespaces, repositories, versions, tags, and permission grants.
  • A GraphQL admin API covers the same ground for automation — create namespaces, add repositories, re-point tags, grant access.
connected
Model archive pulled from model/… for serving
ml-service principal · push + pull tokens
Namespaces & grants managed in Studio
GraphQL · createRepository(namespaceId, …)

Keep exploring

More on Artifacts