Sbt-github-packages: Pacotes do GitHub não parecem suportar sbt (ainda)

Até onde eu sei, -sources, -javadoc, -tests não são suportados

usando sbt-aether-deploy, publiquei com sucesso nos pacotes do github do sbt

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

Um aspecto adicional; se eu usar o Charles Web Debugging Proxy, tudo funciona bem. Sem ele, ocasionalmente recebo erros sobre o servidor não responder.

@lokkju Hmm, e quanto a compilações de vários módulos?

Eu não tentei; key aqui parece estar usando o aether-deploy, embora não o corrija totalmente. Estou suspeitando que seja um problema com o suporte SSL nas versões do cliente usadas por cada ferramenta.

Vou tentar algumas bibliotecas http java diferentes e ver se posso substituir uma configuração simples de trabalho e não de trabalho. Vou mantê-lo atualizado.

Então, depois de mais exploração, encontrei alguns sintomas interessantes.

Apenas usando curl para tentar fazer upload de pacotes, descobri;

• O primeiro arquivo que você PUT é tratado como o artefato principal, independentemente do nome do arquivo ou extensão
• você pode enviar quantos arquivos POM (válidos) quiser, desde que tenham nomes exclusivos
• você não pode fazer upload de nenhum outro arquivo que não seja POM
• Arquivos com extensões de arquivo JAR e POM são analisados ​​pelo github, e formatos inválidos reportarão um erro como a mensagem do erro HTTP 4xx que é retornado.

A principal conclusão atualmente é que você deve fazer upload do artefato JAR primeiro e depois publicar o POM.

Tenho um email para o suporte, vamos ver se eles fornecem mais informações.

Hmm, então também não há assinatura de artefatos?

Ele gera automaticamente *.md5 e *.sha1 para qualquer arquivo carregado.

Além disso, encontrei isto: 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

Não consigo implantar classificadores até agora, o que é incômodo, e parte do que eu tenho uma pergunta no github.

Provavelmente vou criar um projeto maven/java puro e ver se funciona então

Apenas tentei implantar um instantâneo usando a publicação padrão e obtive isto:

[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

Nenhuma menção de instantâneos nos documentos

Na verdade, tenho o mesmo para pacotes normais:

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)

Gostaria de saber como é o corpo desse 400

Existem atualizações sobre isso?

Ainda não há atualizações! Os experimentos de @lokkju são os mais recentes, eu acho. Eu quero brincar um pouco mais com isso, mas honestamente parece que o GitHub Packages ainda não suporta arquivos de hospedagem que são parte integrante de um Maven padrão distribuível (como assinaturas, documentação e classificadores). É difícil fazer algo prático com ele como um host de artefatos até que eles corrijam essas deficiências.

Mais algumas informações, testando com sbt 1.3.2 simples (sem plugins extras)

Você precisa publicar no repositório do seu projeto:

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

credenciais devem ser definidas assim

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

Seu token precisa dos seguintes escopos: read:packages , repo e write:packages

mas uma vez que você publica, você acaba com essas coordenadas de pacote propostas (onde organization="io.test" e name="test"):

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

Os instantâneos podem ser carregados, mas provavelmente não têm tratamento especial, pois você não pode enviá-los duas vezes

O upload do Pom funciona, mas o resto falha:

[info] publicou test_2.13 em https://maven.pkg.github.com/ [username]/[project]/io/test/test_2.13/0.0.3/test_2.13-0.0.3.pom
[erro] java.io.IOException: Acesso à URL https://maven.pkg.github.com/ [username]/[project]/io/test/test_2.13/0.0.3/test_2.13-0.0. 3.jar foi recusado pelo servidor: Forbidden response=Erro: "test_2.13-0.0.3.jar" na versão 0.0.3 de "io.test.test_2.13" já foi publicado.

O upload do JAR do @francisdb falha porque o SBT carrega os arquivos fora de ordem; pelo que me lembro, é um bug de longa data no SBT (IvyActions.scala) onde a função de publicação usa um tipo de mapa em vez do tipo seq. Com a mudança para o sistema de gerenciamento de dependências do Coursier, isso pode ser resolvido automaticamente.

Minha sugestão seria substituir o próprio processo de upload dentro deste plugin, certificando-se de fazer o upload do pom primeiro. Claro, isso ainda não ajuda com classificadores, para os quais preciso de suporte.

parece no sbt 1.3.2 Coursier não está em uso para upload de artefatos, apenas para download

Além disso, não tive nenhuma resposta do GitHub sobre esse problema

Hmmm... Acabei de dar uma olhada muito rápida. sbt 1.2.8 ainda é usado aqui em todos os lugares:
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

(Talvez tenha perdido alguns no entanto)

Eu acho que estes precisam de atualizações?

Solicitação de pull: #2

Coursier só é usado por padrão a partir do sbt 1.3.0

meu teste foi com 1.3.2

@francisdb Entendi.

Parece que o Github mudou algumas coisas, conseguiu fazer um upload completo hoje. (baunilha 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

A interface do usuário da web ainda está confusa sobre o sufixo sbt

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

Isso é emocionante! Vou fazer alguns testes hoje e ver se consigo fechar isso. Muito muito emocionante.

Posso confirmar que, com alguns ajustes no plugin para usar os resultados experimentais do @francisdb , as coisas estão funcionando agora! Os problemas de webui com sufixos de compilação cruzada não parecem afetar a resolução real, apenas a interface do usuário. Portanto, publicação e resolução agora funcionam com o plugin. Ainda não testei coisas com um repositório privado; meu palpite é que eles não estão funcionando ainda, mas as coisas estão boas o suficiente para que eu publique 0.1.0 .

Obrigado a todos, por todo o seu trabalho duro e experimentação! O plugin é notavelmente trivial graças a todos vocês.

@francisdb

Os instantâneos podem ser carregados, mas provavelmente não têm tratamento especial, pois você não pode enviá-los duas vezes

Você _pode_ carregá-los duas vezes: você pode excluir um instantâneo na interface do usuário do GitHub e, em seguida, carregar novamente um novo instantâneo (ou seja, a mesma versão do instantâneo). Isso funcionou para mim. Um pouco trabalhoso, mas funciona.