Change #1067228 had a related patch set uploaded (by Hashar; author: Hashar):

[integration/gearman-java@master] pom: remove Wikimedia Archiva

https://gerrit.wikimedia.org/r/1067228

Change #1067228 merged by jenkins-bot:

[integration/gearman-java@master] pom: remove Wikimedia Archiva

https://gerrit.wikimedia.org/r/1067228

If I remove Wikimedia Archiva from https://github.com/jenkinsci/gearman-plugin/ , it fails:

$ mvn clean compile
...
[ERROR] Failed to execute goal on project gearman-plugin: Could not resolve dependencies for project org.jenkins-ci.plugins:gearman-plugin:hpi:0.6.1-SNAPSHOT: org.wikimedia.gearman:gearman-java:jar:0.10 was not found in https://repo.jenkins-ci.org/public/ during a previous attempt. This failure was cached in the local repository and resolution is not reattempted until the update interval of repo.jenkins-ci.org has elapsed or updates are forced -> [Help 1]

The pom lists https://archiva.wikimedia.org/repository/releases which yields a 404 . I thus supposed our Archiva had been entirely dropped. I then looked at https://mvnrepository.com/artifact/org.wikimedia.gearman/gearman-java and assumed I got it published to Maven Central but that does not match <distributionManagement> which was set to Archiva.

Turns out https://mvnrepository.com/artifact/org.wikimedia.gearman/gearman-java has indexed our Archiva, most probably from the Gearman Jenkins plugin which refers to that that repository. From there there are link to the pom and jar files for example https://archiva.wikimedia.org/repository/releases/org/wikimedia/gearman/gearman-java/0.10/gearman-java-0.10.pom

Turns out https://archiva.wikimedia.org/repository/releases yields a 404 but if I had a trailing slash to it it is working fine:

https://archiva.wikimedia.org/repository/releases/

And I get a list of the past releases at https://archiva.wikimedia.org/repository/releases/org/wikimedia/gearman/gearman-java/

The devil now is to find out how to copy that from Archiva toward Maven Central.

I could not find out how to use Maven to copy artifacts from our Archiva to Maven central.

Then on https://central.sonatype.org/publish/publish-portal-upload/ it seems one can upload a Zip file with the following structure:

$ tree
.
`-- com
    `-- sonatype
        `-- central
            `-- example
                `-- example_java_project
                    `-- 0.1.0
                        |-- example_java_project-0.1.0-javadoc.jar
                        |-- example_java_project-0.1.0-javadoc.jar.asc
                        |-- example_java_project-0.1.0-javadoc.jar.md5
                        |-- example_java_project-0.1.0-javadoc.jar.sha1
                        |-- example_java_project-0.1.0-sources.jar
                        |-- example_java_project-0.1.0-sources.jar.asc
                        |-- example_java_project-0.1.0-sources.jar.md5
                        |-- example_java_project-0.1.0-sources.jar.sha1
                        |-- example_java_project-0.1.0.jar
                        |-- example_java_project-0.1.0.jar.asc
                        |-- example_java_project-0.1.0.jar.md5
                        |-- example_java_project-0.1.0.jar.sha1
                        |-- example_java_project-0.1.0.pom
                        |-- example_java_project-0.1.0.pom.asc
                        |-- example_java_project-0.1.0.pom.md5
                        `-- example_java_project-0.1.0.pom.sha1

So tentatively, I can retrieve them from Archiva with:

wget --recursive \
  --no-parent \
  --no-host-directories --cut-dirs=2 \
  --reject index.html --reject index.html.tmp \
  https://archiva.wikimedia.org/repository/releases/org/wikimedia/gearman/gearman-java/

Which gives me pretty much the same layout:

$ tree
./
└── org/
    └── wikimedia/
        └── gearman/
            └── gearman-java/
                ├── 0.10/
                │   ├── gearman-java-0.10.jar
                │   ├── gearman-java-0.10.jar.asc
                │   ├── gearman-java-0.10.jar.md5
                │   ├── gearman-java-0.10.jar.sha1
                │   ├── gearman-java-0.10-javadoc.jar
                │   ├── gearman-java-0.10-javadoc.jar.asc
                │   ├── gearman-java-0.10-javadoc.jar.md5
                │   ├── gearman-java-0.10-javadoc.jar.sha1
                │   ├── gearman-java-0.10.pom
                │   ├── gearman-java-0.10.pom.asc
                │   ├── gearman-java-0.10.pom.md5
                │   ├── gearman-java-0.10.pom.sha1
                │   ├── gearman-java-0.10-sources.jar
                │   ├── gearman-java-0.10-sources.jar.asc
                │   ├── gearman-java-0.10-sources.jar.md5
                │   ├── gearman-java-0.10-sources.jar.sha1
                │   ├── maven-metadata.xml
                │   ├── maven-metadata.xml.md5
                │   └── maven-metadata.xml.sha1
                ├── 0.8/
                │   ├── gearman-java-0.8.jar
                │   ├── gearman-java-0.8.jar.md5
                │   ├── gearman-java-0.8.jar.sha1
...

When I upload the zip, it fails for multiple reasons:

• 0.8 Javadocs must be provided but not found in entries
• 0.8 Missing signature file for: XXX
• Namespace 'org.wikimedia.gearman' is not allowed
• 0.9 and 0.10: Invalid signature for file: XXX

I went to try registering org.wikimedia which fails since that is already in the legacy system:

Namespace 'org.wikimedia' is already registered as an OSSRH Namespace.

For help with OSSRH namespaces, please refer to our documentation. If you own this namespace on OSSRH and want to manage it through Central Portal, please read through the differences between Central Portal and Legacy OSSRH.

Once you have read the above documentation, please email central-support@sonatype.com for help migrating.

After reviewing the CI build errors, it mentions it can't download the artifacts from artifact-caching-proxy.privatelink.azurecr.io. I went to search in https://github.com/jenkins-infra and found a doc about it https://github.com/jenkins-infra/documentation/blob/a5ef397cbe139ffe0477f39bd4600e3729f274f3/ci.adoc#artifact-caching-proxy :

Artifact Caching Proxy

The artifact caching proxy is a mechanism we’ve put in place using nginx proxy in front of repo.jenkins-ci.org (our JFrog sponsored Artifactory instance) and Maven Central to cache artifact download requests.

The main goals are to decrease the consumed bandwidth (many terabytes per month) and to increase Jenkins infrastructure reliability and resilience.

In case you need for whatever reason to disable this mechanism (discouraged), you have two possibilities:

Temporarily, on your pull request add a skip-artifact-caching-proxy label

Permanently, in your Jenkinsfile add useArtifactCachingProxy: false to the recommanded buildPlugin configuration

Ex:

buildPlugin(
  useContainerAgent: true, // Set to `false` if you need to use Docker for containerized tests
  useArtifactCachingProxy: false,
  configurations: [
    [platform: 'linux', jdk: 17],
    [platform: 'windows', jdk: 11],
])

So I have turned the feature branch to a proper pull request https://github.com/jenkinsci/gearman-plugin/pull/18 I have applied the skip-artifact-caching-proxy label to it and this time the build managed to fetch gearman-java from our archive of Archiva \o/.

I think the issue is Jenkins infra disables all repositories or overrides the repositories definition in favor of using the mirror. I would have to report it upstream to find an appropriate solution.

At least I now have some failures I can file as other tasks and start addressing.

I have filed the proxy issue Upstream with https://github.com/jenkins-infra/jenkins-infra/issues/3631 https://github.com/jenkins-infra/helpdesk/issues/4271

From upstream:

For a new / unknown external repository, the maven configuration should not setup the mirror or ACP should support proxying requests to it.

This is a behavior we do not want on ci.jenkins.io. The goal is to avoid (as much as possible : it is not absolute of course!) spreading dependencies everywhere.
A certain level of "control -> check -> add" loopback is needed, otherwise we'll start having sustainability issues (disappearing dependencies, CVEs, supply chains attacks, etc.).

Which makes total sense, they want some control upon dependencies injected in their ecosystem. So the easiest for us is to have gearman-java to be published on Maven Central.

The workaround to fix the build is to apply a label skip-artifact-caching-proxy to each pull requests or disable the proxy in the Jenkinsfile:

buildPlugin( useArtifactCachingProxy: false, ...)

Change #1068036 had a related patch set uploaded (by Hashar; author: Hashar):

[operations/puppet@production] archiva: allow trailing slash for top directories

https://gerrit.wikimedia.org/r/1068036

Change #1068728 had a related patch set uploaded (by Hashar; author: Hashar):

[integration/config@master] jjb: remove timeout from gearman-java jobs

https://gerrit.wikimedia.org/r/1068728

Change #1068728 merged by jenkins-bot:

[integration/config@master] jjb: remove timeout from gearman-java jobs

https://gerrit.wikimedia.org/r/1068728

Change #1068036 merged by Brouberol:

[operations/puppet@production] archiva: allow trailing slash for top directories

https://gerrit.wikimedia.org/r/1068036

I would need org.wikimedia.gearman:gearman-java version 0.10 to be published to the Central repository. That can be done by someone having access to org.wikimedia on Maven Central.

The documentation to do a manual publishing is on https://central.sonatype.org/publish/publish-manual/#bundle-creation . It requires the artifacts to be bundled a in jar file which can then be uploaded via the web interface.

I have thus retrieved the artifacts from https://archiva.wikimedia.org/repository/releases/org/wikimedia/gearman/gearman-java/0.10. The jar and pom files already had gpg signatures.

I have created a bundle using jar -cvf and have uploaded it at https://people.wikimedia.org/~hashar/T373352/gearman-java-0.10-bundle.jar

Bundle has been uploaded to Maven Central and is available: https://repo.maven.apache.org/maven2/org/wikimedia/gearman/gearman-java/0.10/