Publication

Dans ce tutoriel, vous allez configurer un backend de publication pour que vos installateurs signés et leurs métadonnées d'auto-update arrivent au même endroit — GitHub Releases, un bucket S3 ou n'importe quel host HTTP. Vous choisirez un canal et un type de release, vous contrôlerez le moment où la publication s'exécute, et vous verrez ce que chaque store desktop attend pour une soumission. La configuration vit dans le même DSL nucleus { } que le reste de votre build.

Avant de commencer

• Des installateurs fonctionnels pour vos plateformes cibles. Voir Configuration pour le réglage de targetFormats(...).
• Des builds signés pour les plateformes que vous distribuez. Voir signature de code.
• Une cible d'hébergement : un dépôt GitHub, un bucket S3 ou un serveur HTTP que vous contrôlez.

Configurer un backend de publication

Ajoutez un bloc publish { } dans nativeDistributions { } et activez un backend. Le bloc génère seulement la configuration et le YAML d'update ; l'upload lui-même s'exécute en CI.

nucleus {
    application {
        nativeDistributions {
            publish {
                github {
                    enabled = true
                    owner = "myorg"
                    repo = "myapp"
                    token = System.getenv("GITHUB_TOKEN")
                    channel = ReleaseChannel.Latest
                    releaseType = ReleaseType.Release
                }
            }
        }
    }
}

v1.0.0 (Release)
├── MyApp-1.0.0-macos-arm64.dmg
├── MyApp-1.0.0-macos-universal.dmg
├── MyApp-1.0.0-windows-amd64.exe
├── MyApp-1.0.0-windows.msixbundle
├── MyApp-1.0.0-linux-amd64.deb
├── MyApp-1.0.0-linux-amd64.AppImage
├── latest-mac.yml
├── latest.yml
└── latest-linux.yml

publish {
    s3 {
        enabled = true
        bucket = "my-updates-bucket"
        region = "us-east-1"
        path = "releases/myapp"
        acl = "public-read"
    }
}

publish {
    generic {
        enabled = true
        url = "https://updates.example.com/releases/"
        channel = ReleaseChannel.Latest
        useMultipleRangeRequest = true
    }
}

Choisir un canal et un type de release

Le canal sélectionne le fichier YAML que lit l'auto-updater, ainsi que le pattern de tag associé :

Pour GitHub Releases, le type de release contrôle la visibilité :

Définir le mode de publication

publishMode décide du moment où la publication s'exécute. Sa valeur par défaut est PublishMode.Never :

publish {
    publishMode = PublishMode.Auto
    // github { ... }
}

• PublishMode.Never — ne publie pas. Les métadonnées latest-*.yml sont tout de même générées localement pour chaque format à jour.
• PublishMode.Auto — publie quand le build part d'un tag git.
• PublishMode.Always — publie à chaque build, avec ou sans tag.

Soumettre à un store desktop

La distribution en store passe par le portail de chaque éditeur plutôt que par le bloc publish { }. Construisez le format store, puis uploadez l'artefact :

• Mac App Store — soumettez le PKG via Transporter ou xcrun altool. Les provisioning profiles (sandboxing) et la catégorie du store (appCategory) sont fixés au build. Apple review le build ; les builds App Store ne sont pas notarisés.
• Microsoft Store — uploadez le .msixbundle sur Partner Center. L'identité doit correspondre à la réservation (identityName, publisher = CN=<GUID>, publisherDisplayName). Voir cibles Windows.
• Snapcraft — lancez snapcraft upload depuis la CI. Le Snap Store accepte les confinements strict et classic ; classic exige une approbation. Définissez le grade avec linux.snap { grade = SnapGrade.Stable }.
• Flathub — soumettez une pull request de manifest au dépôt Flathub. Votre bloc flatpak produit le bundle ; Flathub build à partir des sources via votre manifest.
• GitHub Releases / téléchargement direct — le chemin par défaut. Combinez-le avec l'auto-update pour les apps auto-distribuées.

Référence

• publish { publishMode = … }
• publish.github { enabled, owner, repo, token, channel, releaseType }
• publish.s3 { enabled, bucket, region, path, acl }
• publish.generic { enabled, url, channel, useMultipleRangeRequest }
• enum class PublishMode { Never, Auto, Always }
• enum class ReleaseChannel { Latest, Beta, Alpha }
• enum class ReleaseType { Release, Draft, Prerelease }

Voir la référence Gradle DSL pour la surface complète.

Et ensuite

• Auto-update — comment le YAML publié pilote les mises à jour in-app.
• CI de release — le workflow qui build, signe et uploade.
• Signature de code — signez vos builds avant de les publier.