Distribuer hawser vers des registres privés

Chaque version taguée publie d’abord une GitHub Release signée. Une fois celle-ci réussie, le job distribute dans .github/workflows/release.yml réplique les mêmes artefacts vers l’un des quatre registres privés — Nexus, Artifactory, GitLab et Bitbucket — pour les organisations qui installent depuis un miroir interne plutôt que depuis GitHub.

Chaque registre est opt-in : une cible n’est tentée que lorsque ses secrets sont configurés. Un dépôt sans aucun secret défini publie tout de même sa version avec succès — le job distribute journalise un clair skipping <target>: secret not set et l’ensemble du job est continue-on-error, de sorte qu’une panne de registre ne peut jamais faire échouer la version.

Ce qui est téléversé

Pour chaque registre configuré, le job téléverse l’ensemble complet des artefacts de la version :

haw-<version>-<target>.tar.gz / .zip — les archives de plateforme
haw-<version>-<target>.<ext>.sha256 — sommes de contrôle SHA-256
haw-<version>-<target>.<ext>.sig et .pem — signature cosign sans clé + certificat
hawser_<version>-1_amd64.deb et hawser-<version>-1.x86_64.rpm — paquets Linux

Ce sont les fichiers identiques à ceux attachés à la GitHub Release, de sorte que les sommes de contrôle et les signatures cosign se vérifient de la même manière quel que soit le miroir depuis lequel vous avez récupéré (voir INSTALL.md → Verify).

Matrice des secrets

Configurez-les comme secrets de dépôt (ou d’organisation) GitHub Actions. Seuls les registres dont les secrets requis sont présents recevront des publications.

Registre	Secret	Requis ?	Défaut	Objet
Nexus	`NEXUS_URL`	requis	—	URL de base, par ex. `https://nexus.example.com`
	`NEXUS_USER`	requis	—	Nom d’utilisateur
	`NEXUS_PASS`	requis	—	Mot de passe / jeton
	`NEXUS_REPO`	facultatif	`raw-hosted`	Nom du dépôt raw hosted
Artifactory	`ARTIFACTORY_URL`	requis	—	URL de base, par ex. `https://artifactory.example.com/artifactory`
	`ARTIFACTORY_TOKEN`	requis	—	Jeton Bearer / d’identité
	`ARTIFACTORY_REPO`	facultatif	`generic-local`	Clé de dépôt générique
GitLab	`GITLAB_TOKEN`	requis	—	Jeton d’accès personnel/de projet (scope `api`)
	`GITLAB_PROJECT_ID`	requis	—	ID de projet numérique
	`GITLAB_URL`	facultatif	`https://gitlab.com`	URL de base de l’instance auto-hébergée
Bitbucket	`BITBUCKET_USER`	requis	—	Nom d’utilisateur
	`BITBUCKET_TOKEN`	requis	—	Mot de passe d’application / jeton d’accès
	`BITBUCKET_WORKSPACE`	requis	—	Slug de l’espace de travail
	`BITBUCKET_REPO`	requis	—	Slug du dépôt

Un registre est ignoré (journalisé, pas en échec) sauf si tous ses secrets requis sont définis.

Disposition et installation par registre

Partout, <version> est le tag sans le v initial (par ex. 0.1.7).

Nexus (dépôt raw hosted)

Chaque fichier est envoyé par PUT vers un dépôt raw hosted sous un chemin versionné :

<NEXUS_URL>/repository/<NEXUS_REPO>/haw/<version>/<file>

Téléversement (ce que la CI exécute, par fichier) :

curl -u "$NEXUS_USER:$NEXUS_PASS" \
  --upload-file haw-0.1.7-x86_64-unknown-linux-musl.tar.gz \
  "$NEXUS_URL/repository/raw-hosted/haw/0.1.7/haw-0.1.7-x86_64-unknown-linux-musl.tar.gz"

Consommer :

curl -u "$NEXUS_USER:$NEXUS_PASS" -O \
  "$NEXUS_URL/repository/raw-hosted/haw/0.1.7/haw-0.1.7-x86_64-unknown-linux-musl.tar.gz"
tar xzf haw-0.1.7-x86_64-unknown-linux-musl.tar.gz && sudo install haw /usr/local/bin/

Artifactory (dépôt générique)

Chaque fichier est envoyé par PUT (auth Bearer) vers un dépôt générique sous un chemin versionné :

<ARTIFACTORY_URL>/<ARTIFACTORY_REPO>/haw/<version>/<file>

Téléversement (par fichier) :

curl -H "Authorization: Bearer $ARTIFACTORY_TOKEN" \
  --upload-file haw-0.1.7-x86_64-unknown-linux-musl.tar.gz \
  "$ARTIFACTORY_URL/generic-local/haw/0.1.7/haw-0.1.7-x86_64-unknown-linux-musl.tar.gz"

Consommer :

curl -H "Authorization: Bearer $ARTIFACTORY_TOKEN" -O \
  "$ARTIFACTORY_URL/generic-local/haw/0.1.7/haw-0.1.7-x86_64-unknown-linux-musl.tar.gz"

GitLab (registre de paquets générique + Release)

Deux choses se produisent. D’abord, chaque fichier est envoyé par PUT vers le registre de paquets générique du projet :

<GITLAB_URL>/api/v4/projects/<GITLAB_PROJECT_ID>/packages/generic/haw/<version>/<file>

Ensuite, une GitLab Release est créée pour le tag, avec assets.links[] pointant vers chaque fichier de paquet téléversé (une release existante pour le tag est tolérée, pas une erreur).

Téléversement (par fichier) :

curl --header "PRIVATE-TOKEN: $GITLAB_TOKEN" \
  --upload-file haw-0.1.7-x86_64-unknown-linux-musl.tar.gz \
  "https://gitlab.com/api/v4/projects/$GITLAB_PROJECT_ID/packages/generic/haw/0.1.7/haw-0.1.7-x86_64-unknown-linux-musl.tar.gz"

Consommer :

curl --header "PRIVATE-TOKEN: $GITLAB_TOKEN" -O \
  "https://gitlab.com/api/v4/projects/$GITLAB_PROJECT_ID/packages/generic/haw/0.1.7/haw-0.1.7-x86_64-unknown-linux-musl.tar.gz"

Ou ouvrez la page Deploy → Releases du projet et téléchargez depuis les assets de la release.

Bitbucket (Downloads du dépôt)

Chaque fichier est envoyé par POST (multipart) vers la zone Downloads du dépôt :

https://api.bitbucket.org/2.0/repositories/<BITBUCKET_WORKSPACE>/<BITBUCKET_REPO>/downloads

Téléversement (par fichier) :

curl -u "$BITBUCKET_USER:$BITBUCKET_TOKEN" \
  -X POST \
  "https://api.bitbucket.org/2.0/repositories/$BITBUCKET_WORKSPACE/$BITBUCKET_REPO/downloads" \
  -F files=@haw-0.1.7-x86_64-unknown-linux-musl.tar.gz

Consommer (les fichiers arrivent sous l’onglet Downloads du dépôt ; les noms de fichiers sont à plat, non versionnés) :

curl -u "$BITBUCKET_USER:$BITBUCKET_TOKEN" -O -L \
  "https://bitbucket.org/$BITBUCKET_WORKSPACE/$BITBUCKET_REPO/downloads/haw-0.1.7-x86_64-unknown-linux-musl.tar.gz"

Bitbucket Downloads est un espace de noms à plat (pas de dossiers par version), la <version> est donc portée dans le nom de fichier lui-même.

`haw publish` — téléverser des artefacts depuis le CLI

Le job CI distribute réplique les archives de release, mais vous pouvez pousser vous-même n’importe quels artefacts (sorties de build, un bundle evidence, un SBOM) vers les quatre mêmes registres avec haw publish. Il utilise les chemins de téléversement et l’authentification identiques à ceux de la CI, en lisant les identifiants depuis les mêmes variables d’environnement.

haw publish <files…> --to <nexus|artifactory|gitlab|bitbucket>
            [--name <NAME>] [--version <VER>] [--url <URL>]
            [--dry-run] [--insecure] [--format json]

Option	Signification
`<files…>`	Fichiers ou globs à téléverser. Par défaut `haw-evidence.tar.gz` s’il est présent et qu’aucun fichier n’est fourni.
`--to`	Registre cible : `nexus`, `artifactory`, `gitlab`, ou `bitbucket` (requis).
`--name`	Nom du paquet. Par défaut : le stack courant, sinon le nom du répertoire de l’espace de travail.
`--version`	Version du paquet. Par défaut : le SHA HEAD court, sinon `unversioned`.
`--url`	Remplace l’URL de base de la cible (sinon prise dans la variable d’environnement de la cible).
`--dry-run`	Affiche exactement ce qui serait téléversé (méthode, URL, emplacement d’authentification) et se termine — sans réseau, sans identifiants requis.
`--insecure`	Autorise un registre non-HTTPS (`http://`). Par défaut, les registres `http://` sont rejetés ; sans cette option, `haw publish` refuse d’envoyer des identifiants en clair.
`--format json`	Émet un résumé JSON `{target, name, version, uploads:[…]}`.

Les identifiants proviennent de l’environnement, par cible (mêmes variables que la matrice des secrets CI ci-dessus) :

Cible	Variables d’env.
Nexus	`NEXUS_URL`, `NEXUS_USER`, `NEXUS_PASS`, optional `NEXUS_REPO` (default `raw-hosted`)
Artifactory	`ARTIFACTORY_URL`, `ARTIFACTORY_TOKEN`, optional `ARTIFACTORY_REPO` (default `generic-local`)
GitLab	`GITLAB_TOKEN`, `GITLAB_PROJECT_ID`, optional `GITLAB_URL` (default `https://gitlab.com`)
Bitbucket	`BITBUCKET_USER`, `BITBUCKET_TOKEN`, `BITBUCKET_WORKSPACE`, `BITBUCKET_REPO`

haw publish ./out/*.bin --to nexus                 # téléverser les sorties de build vers Nexus raw-hosted
haw publish --to gitlab                             # téléverser haw-evidence.tar.gz vers les packages GitLab
haw publish sbom.json haw-evidence.tar.gz --to artifactory   # plusieurs fichiers à la fois
haw publish app.bin --to bitbucket                  # POST vers les Downloads du dépôt Bitbucket
haw publish app.bin --to nexus --dry-run            # afficher le plan (méthode/URL/auth), sans réseau
haw publish app.bin --to nexus --format json        # résumé de téléversement lisible par machine

Vérifier après téléchargement

Quel que soit le miroir, vérifiez exactement comme avec la GitHub Release — téléchargez les .sha256, .sig et .pem correspondants aux côtés de l’archive :

sha256sum -c haw-0.1.7-x86_64-unknown-linux-musl.tar.gz.sha256
cosign verify-blob \
  --certificate haw-0.1.7-x86_64-unknown-linux-musl.tar.gz.pem \
  --signature   haw-0.1.7-x86_64-unknown-linux-musl.tar.gz.sig \
  --certificate-identity-regexp 'https://github.com/Nastwinns/hawser' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  haw-0.1.7-x86_64-unknown-linux-musl.tar.gz

Voir INSTALL.md pour le flux complet de vérification et d’air-gap.

Retour à INSTALL.md.

Keyboard shortcuts

hawser — the beam that binds the repos