Sbt-github-packages: Los paquetes de GitHub no parecen ser compatibles con sbt (todavía)

Por lo que puedo decir, -sources, -javadoc, -tests no son compatibles

usando sbt-aether-deploy, he publicado con éxito paquetes de github desde sbt

proyecto/plugins.sbt

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

construir.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 aspecto adicional; si utilizo Charles Web Debugging Proxy, todo funciona bien. Sin él, de vez en cuando obtengo errores acerca de que el servidor no responde.

@lokkju Hmm, ¿qué pasa con las compilaciones de varios módulos?

No los he probado; La clave aquí parece estar usando aether-deploy, aunque no lo soluciona por completo. Sospecho que es un problema con el soporte SSL en las versiones de cliente utilizadas por cada herramienta.

Voy a probar algunas bibliotecas java http diferentes y ver si puedo reemplazar una configuración simple que funciona y no funciona. Te mantendré informado.

Entonces, después de más exploración, encontré algunos síntomas interesantes.

Simplemente usando curl para intentar cargar paquetes, encontré;

• El primer archivo que PONE se trata como el artefacto principal, independientemente del nombre del archivo o la extensión.
• luego puede cargar tantos archivos POM (válidos) como desee, siempre que tengan nombres únicos
• no puede cargar ningún otro archivo que no sea POM
• Github analiza los archivos con extensiones de archivo JAR y POM, y los formatos no válidos informarán un error como el mensaje de error HTTP 4xx que se devuelve.

La conclusión clave actualmente es que primero debe cargar el artefacto JAR y luego publicar el POM.

Tengo un correo electrónico en soporte, veremos si brindan más información.

Hmm, ¿entonces tampoco hay firma de artefactos?

Genera automáticamente *.md5 y *.sha1 para cualquier archivo cargado.

Además, encontré esto: 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

Parece que hasta ahora no puedo implementar clasificadores, lo cual es molesto, y parte de lo que tengo una pregunta sobre github.

Probablemente crearé un proyecto maven/java puro y veré si funciona.

Intenté implementar una instantánea usando la publicación predeterminada y obtuve esto:

[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

No se mencionan instantáneas en los documentos.

De hecho tengo lo mismo para los paquetes normales:

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)

Me pregunto cómo se ve el cuerpo de ese 400

¿Hay alguna actualización sobre esto?

¡Aún no hay actualizaciones! Los experimentos de @lokkju son los últimos, creo. Quiero jugar un poco más con esto, pero, sinceramente, parece que los paquetes de GitHub aún no admiten el alojamiento de archivos que son parte integrante de un distribuible estándar de Maven (como firmas, documentación y clasificadores). Es difícil hacer algo práctico con él como anfitrión de artefactos hasta que corrijan estas deficiencias.

Algo más de información, probando con sbt 1.3.2 simple (sin complementos adicionales)

Necesitas publicar en el repositorio de tu proyecto:

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

Las credenciales deben definirse así

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

Su token necesita los siguientes alcances: read:packages , repo y write:packages

pero una vez que publica, termina con estas coordenadas de paquete propuestas (donde organization="io.test" y name="test"):

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

Las instantáneas se pueden cargar, pero es probable que no tengan un manejo especial, ya que no se pueden cargar dos veces.

La carga de Pom funciona, pero el resto falla:

[info] publicó test_2.13 en https://maven.pkg.github.com/ [nombre de usuario]/[proyecto]/io/test/test_2.13/0.0.3/test_2.13-0.0.3.pom
[error] java.io.IOException: acceso a la URL https://maven.pkg.github.com/ [nombre de usuario]/[proyecto]/io/test/test_2.13/0.0.3/test_2.13-0.0. 3.jar fue rechazado por el servidor: Respuesta prohibida=Error: "test_2.13-0.0.3.jar" en la versión 0.0.3 de "io.test.test_2.13" ya se ha publicado.

La carga de JAR de @francisdb falla porque SBT carga los archivos desordenados; por lo que puedo recordar, es un error de larga data en SBT (IvyActions.scala) donde la función de publicación usa un tipo de mapa en lugar de un tipo de secuencia. Con el cambio al sistema de gestión de dependencias de Coursier, esto podría resolverse por sí solo.

Mi sugerencia sería anular el proceso de carga en sí dentro de este complemento, asegurándose de cargar primero el pom. Por supuesto, esto todavía no ayuda con los clasificadores, para los cuales necesito soporte.

parece que en sbt 1.3.2 Coursier no se usa para cargar artefactos, solo para descargar

Además, no he recibido ninguna respuesta de GitHub sobre este problema.

Hmmm... Acabo de echar un vistazo muy rápido. sbt 1.2.8 todavía se usa aquí en todas partes:
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

(Tal vez me perdí algunos sin embargo)

Supongo que estos necesitan actualizaciones?

Solicitud de extracción: #2

Coursier solo se usa de forma predeterminada a partir de sbt 1.3.0

mi prueba fue con 1.3.2

@francisdb Lo tengo.

Parece que Github ha cambiado algunas cosas, pudo hacer una carga completa hoy. (vainilla 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

La interfaz de usuario web todavía está confundida sobre el sufijo sbt

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

¡Esto es emocionante! Voy a hacer algunas pruebas hoy y ver si puedo cerrar esto. Muy, muy emocionante.

Puedo confirmar que, con algunos ajustes en el complemento para usar los resultados experimentales de @francisdb , ¡las cosas ahora funcionan! Los problemas de webui con sufijos de compilación cruzada no parecen afectar la resolución real, solo la interfaz de usuario. Entonces, la publicación y la resolución ahora funcionan con el complemento. Todavía no he probado cosas con un repositorio privado; Supongo que aún no están funcionando del todo, pero las cosas son lo suficientemente buenas como para publicar 0.1.0 .

¡Gracias a todos por su arduo trabajo y experimentación! El complemento es notablemente trivial gracias a todos ustedes.

@francisdb

Las instantáneas se pueden cargar, pero es probable que no tengan un manejo especial, ya que no se pueden cargar dos veces.

Puede cargarlos dos veces: puede eliminar una instantánea en la interfaz de usuario de GitHub y luego volver a cargar una nueva instantánea (es decir, la misma versión de la instantánea). Eso funcionó para mí. Un poco engorroso, pero funciona.