Sbt-github-packages: GitHub-Pakete scheinen sbt (noch) nicht zu unterstützen

Soweit ich das beurteilen kann, werden -sources, -javadoc, -tests nicht unterstützt

Mit sbt-aether-deploy habe ich erfolgreich Pakete von sbt auf github veröffentlicht

project/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

Ein zusätzlicher Aspekt; Wenn ich den Charles Web Debugging Proxy verwende, funktioniert alles einwandfrei. Ohne sie erhalte ich gelegentlich Fehlermeldungen, dass der Server nicht antwortet.

@lokkju Hmm , was ist mit Builds mit mehreren Modulen?

Ich habe sie nicht ausprobiert; Der Schlüssel hier scheint Aether-Deploy zu verwenden, obwohl es das Problem nicht vollständig behebt. Ich vermute, dass es sich um ein Problem mit der SSL-Unterstützung in den Client-Versionen handelt, die von jedem Tool verwendet werden.

Ich werde ein paar verschiedene Java-HTTP-Bibliotheken ausprobieren und sehen, ob ich eine einfache funktionierende und nicht funktionierende Konfiguration ersetzen kann. Ich halte dich auf dem Laufenden.

Also, nach mehr Forschung, habe ich einige interessante Symptome gefunden.

Ich habe festgestellt, dass ich nur curl verwende, um zu versuchen, Pakete hochzuladen.

• Die erste PUT-Datei wird unabhängig vom Dateinamen oder der Erweiterung als Hauptartefakt behandelt
• Sie können dann beliebig viele (gültige) POM-Dateien hochladen, solange sie eindeutige Namen haben
• Sie können keine anderen Nicht-POM-Dateien hochladen
• Dateien mit JAR- und POM-Dateierweiterungen werden von Github analysiert, und ungültige Formate melden einen Fehler als Nachricht des zurückgegebenen HTTP-Fehlers 4xx.

Die wichtigste Erkenntnis ist derzeit, dass Sie zuerst das JAR-Artefakt hochladen und dann das POM veröffentlichen müssen .

Ich habe eine E-Mail an den Support, wir werden sehen, ob sie weitere Informationen bereitstellen.

Hmm, also auch kein Signieren von Artefakten?

Es generiert automatisch die *.md5 und *.sha1 für alle hochgeladenen Dateien.

Auch gefunden: 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

Ich kann anscheinend bisher überhaupt keine Klassifikatoren bereitstellen, was lästig ist und Teil dessen ist, worüber ich eine Frage zu Github habe.

Ich werde wahrscheinlich ein reines Maven/Java-Projekt erstellen und sehen, ob es dann funktioniert

Ich habe gerade versucht, einen Snapshot mit der Standardveröffentlichung bereitzustellen, und habe Folgendes erhalten:

[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

Keine Erwähnung von Schnappschüssen in den Dokumenten

Tatsächlich habe ich das gleiche für normale Pakete:

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)

Ich frage mich, wie der Körper dieser 400 aussieht

Gibt es dazu irgendwelche Updates?

Noch keine Updates! Die Experimente von @lokkju sind die neuesten, denke ich. Ich möchte noch etwas damit herumspielen, aber ehrlich gesagt hört es sich so an, als ob GitHub-Pakete das Hosten von Dateien immer noch nicht unterstützen, die Teil eines standardmäßigen Maven-Distributable sind (wie Signaturen, Dokumentation und Klassifikatoren). Es ist schwer, irgendetwas Praktisches damit als Artefakt-Host zu tun, bis sie diese Mängel behoben haben.

Einige weitere Informationen, Testen mit einfachem sbt 1.3.2 (keine zusätzlichen Plugins)

Sie müssen im Repository Ihres Projekts veröffentlichen:

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

Credentails sollten so definiert werden

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

Ihr Token benötigt die folgenden Bereiche: read:packages , repo und write:packages

aber sobald Sie veröffentlichen, erhalten Sie diese vorgeschlagenen Paketkoordinaten (wobei organization="io.test" und name="test"):

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

Schnappschüsse können hochgeladen werden, aber sie haben wahrscheinlich keine besondere Behandlung, da Sie sie nicht zweimal hochladen können

Der Pom-Upload funktioniert, aber der Rest schlägt fehl:

[info] veröffentlicht test_2.13 auf https://maven.pkg.github.com/[username]/[project]/io/test/test_2.13/0.0.3/test_2.13-0.0.3.pom
[Fehler] java.io.IOException: Zugriff auf URL https://maven.pkg.github.com/ [Benutzername]/[Projekt]/io/test/test_2.13/0.0.3/test_2.13-0.0. 3.jar wurde vom Server abgelehnt: Forbidden response=Error: „test_2.13-0.0.3.jar“ in Version 0.0.3 von „io.test.test_2.13“ wurde bereits veröffentlicht.

@francisdb JAR-Upload schlägt fehl, weil SBT die Dateien nicht in der richtigen Reihenfolge hochlädt; Soweit ich mich erinnern kann, handelt es sich um einen seit langem bestehenden Fehler in SBT (IvyActions.scala), bei dem die Veröffentlichungsfunktion einen Kartentyp anstelle eines Seq-Typs verwendet. Mit der Umstellung auf das Coursier-Abhängigkeitsverwaltungssystem könnte sich dies von selbst lösen.

Mein Vorschlag wäre, den Upload-Prozess selbst innerhalb dieses Plugins zu überschreiben und sicherzustellen, dass der Pom zuerst hochgeladen wird. Das hilft natürlich immer noch nicht bei Klassifikatoren, wofür ich Unterstützung benötige.

sieht so aus auf sbt 1.3.2 Coursier wird nicht zum Hochladen von Artefakten verwendet, sondern nur zum Herunterladen

Außerdem habe ich keine Antwort von GitHub zu diesem Problem erhalten

Hmmm... Ich habe nur ganz kurz nachgeschaut. sbt 1.2.8 wird hier noch überall verwendet:
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

(Vielleicht aber etwas übersehen)

Ich denke, diese brauchen Upgrades?

Pull-Request: #2

Coursier wird erst ab sbt 1.3.0 standardmäßig verwendet

mein Test war mit 1.3.2

@francisdb Verstanden .

Sieht so aus, als hätte Github einige Dinge geändert, konnte heute einen vollständigen Upload durchführen. (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

Die Webbenutzeroberfläche ist immer noch verwirrt über das Suffix sbt

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

Das ist spannend! Ich werde heute ein paar Tests machen und sehen, ob ich das schließen kann. Sehr sehr spannend.

Ich kann bestätigen, dass mit ein paar Änderungen am Plugin, um die experimentellen Ergebnisse von @francisdb zu verwenden, die Dinge jetzt funktionieren! Die Webui-Probleme mit Cross-Build-Suffixen scheinen sich nicht auf die tatsächliche Auflösung auszuwirken, sondern nur auf die Benutzeroberfläche. Veröffentlichung und Auflösung funktionieren jetzt also mit dem Plugin. Ich habe die Dinge noch nicht mit einem privaten Repository getestet; Ich vermute, dass sie noch nicht ganz funktionieren, aber die Dinge sind gut genug, dass ich 0.1.0 veröffentlicht habe.

Vielen Dank an alle für all eure harte Arbeit und Experimente! Das Plugin ist dank euch allen bemerkenswert trivial.

@francisdb

Schnappschüsse können hochgeladen werden, aber sie haben wahrscheinlich keine besondere Behandlung, da Sie sie nicht zweimal hochladen können

Sie _können_ sie zweimal hochladen: Sie können einen Snapshot in der GitHub-Benutzeroberfläche löschen und dann erneut einen neuen Snapshot hochladen (d. h. dieselbe Snapshot-Version). Das hat bei mir funktioniert. Etwas umständlich, aber es geht.