Sbt-github-packages: Les packages GitHub ne semblent pas (encore) prendre en charge sbt

Autant que je sache, -sources, -javadoc, -tests ne sont pas pris en charge

en utilisant sbt-aether-deploy, j'ai publié avec succès des packages github à partir de sbt

projet/plugins.sbt

addSbtPlugin("no.arktekk.sbt" % "aether-deploy" % "0.23.0")
addSbtPlugin("com.dwijnand" % "sbt-dynver" % "4.0.0")

build.sbt

externalResolvers += "GitHub lokkju Apache Maven Packages" at "https://maven.pkg.github.com/lokkju/github-action-sbt"
publishTo := Some("GitHub lokkju Apache Maven Packages" at "https://maven.pkg.github.com/lokkju/github-action-sbt")
credentials += Credentials("GitHub Package Registry", "maven.pkg.github.com", "lokkju", "<GITHUB_TOKEN>")

// GitHub package repo isn't supporting javadoc and sources
publishArtifact in (Compile, packageDoc) := false
publishArtifact in (Compile, packageSrc) := false

sbt aetherDeploy

Un aspect supplémentaire; si j'utilise le Charles Web Debugging Proxy, tout fonctionne bien. Sans cela, j'obtiens parfois des erreurs sur le serveur qui ne répond pas.

@lokkju Hmm, qu'en est-il des versions multi-modules ?

je ne les ai pas essayés; key ici semble utiliser aether-deploy, bien qu'il ne le corrige pas entièrement. Je soupçonne que c'est un problème avec le support SSL dans les versions clientes utilisées par chaque outil.

Je vais essayer différentes bibliothèques Java http et voir si je peux remplacer une configuration simple qui fonctionne et ne fonctionne pas. Je vous tiens au courant.

Donc, après plus d'exploration, j'ai trouvé des symptômes intéressants.

En utilisant simplement curl pour essayer de télécharger des packages, j'ai trouvé;

• Le premier fichier que vous mettez est traité comme l'artefact principal, quel que soit le nom de fichier ou l'extension
• vous pouvez ensuite télécharger autant de fichiers POM (valides) que vous le souhaitez, tant qu'ils ont des noms uniques
• vous ne pouvez pas télécharger d'autres fichiers non POM
• Les fichiers avec les extensions de fichier JAR et POM sont analysés par github, et les formats non valides signaleront une erreur en tant que message de l'erreur HTTP 4xx renvoyée.

La clé à retenir actuellement est que vous devez d'abord télécharger l'artefact JAR, puis publier le POM.

J'ai un e-mail au support, nous verrons s'ils fournissent plus d'informations.

Hmm, donc pas de signature d'artefact non plus, alors ?

Il génère automatiquement les *.md5 et *.sha1 pour tous les fichiers téléchargés.

Aussi, trouvé ceci: https://github.com/sbt/librarymanagement/blob/d09f9f81b664baaac15054730fbcb51e1b240de2/ivy/src/main/scala/sbt/internal/librarymanagement/IvyActions.scala#L123

Artifactory deals with the publishing (and republishing) of SNAPSHOTs using a strict rule on the order of publishing. The ;build.timestamp=... suffix is the alternative.

The strict rule is:

publish the main artefact (which has no classifier)
publish the POM/ivy.xml file
publish additional artefacts which have a classifier

Je n'arrive pas du tout à déployer des classificateurs jusqu'à présent, ce qui est gênant et fait partie de ce sur quoi j'ai une question sur github.

Je vais probablement créer un projet maven/java pur et voir si cela fonctionne alors

Je viens d'essayer de déployer un instantané à l'aide de la publication par défaut et j'ai obtenu ceci :

[error] stack trace is suppressed; run last publish for the full output
[error] (publish) java.io.IOException: PUT operation to URL https://maven.pkg.github.com/company/foo/bar/utils/3.24.0-SNAPSHOT/utils-3.24.0-SNAPSHOT.pom failed with status code 400: Bad Request

Aucune mention d'instantanés dans les docs

En fait j'ai la même chose pour les packages normaux :

java.io.IOException: PUT operation to URL https://maven.pkg.github.com/company/foo/bar/utils/utils/0.0.1/utils-0.0.1.pom failed with status code 400: Bad Request

[error] java.io.IOException: PUT operation to URL https://maven.pkg.github.com/company/foo/bar/utils/utils/0.0.1/utils-0.0.1.pom failed with status code 400: Bad Request
[error]     at org.apache.ivy.util.url.AbstractURLHandler.validatePutStatusCode(AbstractURLHandler.java:82)
[error]     at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:264)
[error]     at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
[error]     at org.apache.ivy.util.FileUtil.copy(FileUtil.java:150)

Je me demande à quoi ressemble le corps de ce 400

Y a-t-il des mises à jour à ce sujet ?

Pas encore de mises à jour ! Les expériences de @lokkju sont les dernières, je pense. Je veux jouer un peu plus avec, mais honnêtement, il semble que les packages GitHub ne prennent toujours pas en charge les fichiers d'hébergement qui font partie intégrante d'un distribuable Maven standard (tels que les signatures, la documentation et les classificateurs). Il est difficile de faire quoi que ce soit de pratique avec lui en tant qu'hôte d'artefacts jusqu'à ce qu'ils corrigent ces lacunes.

Quelques informations supplémentaires, test avec sbt 1.3.2 (pas de plugins supplémentaires)

Vous devez publier dans le dépôt de votre projet :

publishTo := Some("GitHub Package Registry" at "https://maven.pkg.github.com/[username]/[project]")

les informations d'identification doivent être définies comme ceci

credentials += Credentials("GitHub Package Registry","maven.pkg.github.com","[username]","[token]")

Votre jeton a besoin des champs d'application suivants : read:packages , repo et write:packages

mais une fois que vous publiez, vous vous retrouvez avec ces coordonnées de package proposées (où organization="io.test" et name="test") :

<dependency>
  <groupId>com.github.[username]/[project]</groupId>
  <artifactId>io.test.test_2.13</artifactId>
  <version>0.1</version>
</dependency> 

Les instantanés peuvent être téléchargés, mais ils n'ont probablement pas de traitement spécial car vous ne pouvez pas les télécharger deux fois

Le téléchargement de Pom fonctionne, mais le reste échoue :

[info] a publié test_2.13 sur https://maven.pkg.github.com/ [username]/[project]/io/test/test_2.13/0.0.3/test_2.13-0.0.3.pom
[erreur] java.io.IOException : accès à l'URL https://maven.pkg.github.com/ [nom d'utilisateur]/[projet]/io/test/test_2.13/0.0.3/test_2.13-0.0. 3.jar a été refusé par le serveur : Forbidden response=Erreur : "test_2.13-0.0.3.jar" dans la version 0.0.3 de "io.test.test_2.13" a déjà été publié.

@francisdb Le téléchargement JAR échoue car SBT télécharge les fichiers dans le désordre ; d'après ce dont je me souviens, c'est un bogue de longue date dans SBT (IvyActions.scala) où la fonction de publication utilise un type de carte au lieu du type seq. Avec le passage au système de gestion des dépendances Coursier, cela pourrait se résoudre d'eux-mêmes.

Ma suggestion serait de remplacer le processus de téléchargement lui-même dans ce plugin, en veillant à télécharger le pom en premier. Bien sûr, cela n'aide toujours pas avec les classificateurs, pour lesquels j'ai besoin d'aide.

ressemble à sbt 1.3.2 Coursier n'est pas utilisé pour le téléchargement d'artefacts, uniquement pour le téléchargement

De plus, je n'ai eu aucune réponse de GitHub sur ce problème

Hmmm... Je viens de jeter un coup d'œil très rapide. sbt 1.2.8 est toujours utilisé ici partout :
https://github.com/djspiewak/sbt-github-packages/blob/0839b97dea06100a202f2a105cbe83873784bf77/build.sbt#L28
https://github.com/djspiewak/sbt-github-packages/blob/0839b97dea06100a202f2a105cbe83873784bf77/src/sbt-test/sbtghpackages/publish/project/build.properties#L1
https://github.com/djspiewak/sbt-github-packages/blob/0839b97dea06100a202f2a105cbe83873784bf77/project/build.properties#L1

(Peut-être en a-t-il manqué cependant)

Je suppose que ces mises à niveau ont besoin?

Demande d'extraction : #2

Coursier n'est utilisé par défaut qu'à partir de sbt 1.3.0

mon test était avec 1.3.2

@francisdb Compris .

On dirait que Github a changé certaines choses, a pu faire un téléchargement complet aujourd'hui. (vanille sbt 1.3.3)

[info]  published test_2.13 to https://maven.pkg.github.com/francisdb/foo/com/example/test_2.13/0.0.9/test_2.13-0.0.9.pom
[info]  published test_2.13 to https://maven.pkg.github.com/francisdb/foo/com/example/test_2.13/0.0.9/test_2.13-0.0.9.jar
[info]  published test_2.13 to https://maven.pkg.github.com/francisdb/foo/com/example/test_2.13/0.0.9/test_2.13-0.0.9-sources.jar
[info]  published test_2.13 to https://maven.pkg.github.com/francisdb/foo/com/example/test_2.13/0.0.9/test_2.13-0.0.9-javadoc.jar

L'interface utilisateur Web est toujours confuse au sujet du suffixe sbt

<dependency>
  <groupId>com.example.test_2</groupId>
  <artifactId>13</artifactId>
  <version>0.0.9</version>
</dependency> 

C'est excitant! Je vais faire des tests aujourd'hui et voir si je peux fermer ça. Très très excitant.

Je peux confirmer qu'avec quelques ajustements au plugin pour utiliser les résultats expérimentaux de @francisdb , les choses fonctionnent maintenant ! Les problèmes d'interface Web avec les suffixes de construction croisée ne semblent pas affecter la résolution réelle, uniquement l'interface utilisateur. Ainsi, la publication et la résolution fonctionnent désormais avec le plugin. Je n'ai pas encore testé les choses avec un dépôt privé ; je suppose qu'ils ne fonctionnent pas encore tout à fait, mais les choses sont assez bonnes pour que j'ai publié 0.1.0 .

Merci à tous pour votre travail acharné et vos expérimentations ! Le plugin est remarquablement trivial grâce à vous tous.

@francisdb

Les instantanés peuvent être téléchargés, mais ils n'ont probablement pas de traitement spécial car vous ne pouvez pas les télécharger deux fois

Vous _pouvez_ les télécharger deux fois : vous pouvez supprimer un instantané dans l'interface utilisateur GitHub, puis télécharger à nouveau un nouvel instantané (c'est-à-dire la même version d'instantané). Cela a fonctionné pour moi. Un peu encombrant, mais ça marche.