It seems that the latest build error is due to authentication issue to deploy the binary to repo.jenkins-ci.io.

It seems that the latest build error is due to authentication issue to deploy the binary to repo.jenkins-ci.io.

As far as I can tell, infra.ci.jenkins.io does not have any credential allowing deployment to repo.jenkins-ci.org, because it was not designed for this use case.

There are multiple solutions for the next steps:

• Allow deployment from infra.ci.jenkins.io, but restricted:

  • Only allowed to publish to a specific hosted repository (that may, or may not be aggrregated in repo.jenkins-ci.org/public => to be discussed)
  • Define a technical account with its credential (and credential rotation using the team calendar) only in the job in charge of thte deployment

• Use the same CD process as plugins : safer but requires using GitHub Action for this task

There are multiple solutions for the next steps

We could also inverse the phase, "deploy" on ci.jenkins.io, and "verify" on infra.ci.jenkins.io, much simpler IMO.

ci.jenkins.io doesn't have the credentials either.

I'm not sure I want to use a GHA for something we (Jenkins community) should support.

For the moment, this is not mandatory. We can revisit this when it is.

I'm not sure I want to use a GHA for something we (Jenkins community) should support.

The safe, supported and automated way for deploying artefacts other than Jenkins Core to the Maven repository is the CD process.

Using Jenkins instead of GHA for this (an eventual cd.jenkins.io) is theorically posible but would require a JEP to have a disucssion and problem statement on the impacts (effort, risk analysis, advantages, etc.).

As much as I would like to use Jenkins everywhere in term of "public image", as much the effort for using it on a public project is a different matter : the impact on public image of code injection on a public artefact is clearly a risk compared to accepting that GHA is not an enemy or a concurent, but a tool that provides its benefit when needed.

For the moment, this is not mandatory. We can revisit this when it is.

No problem, we (jenkins infra) started to brainstorm on the solution we could provide specifically for the plugin health to map it to other components that are deployed.
If you have another of the jenkinsci or jenkins-infra projects in mind that already deploys to JFrog, we could check it to build a nice solution for these "exceptions" (e.g. not plugin, not core).

@alecharp do you know if Maven can use a GitHub release's published artifact (or if there could be a Maven repository per repository, that could, then, be mirrored on JFrog) ?

For the moment, I don't think the project is as a state where (almost) all commit to main branch requires a release. So the CD process applied to Jenkins plugins is not suited for the project. This might evolves later but for now, I prefer to do the releases myself.

As the deployment of the project is in fact controlled by infra.ci.jenkins.io, the release process on my laptop is just generating a tag. The CI is then generating the binaries and the Docker image, deploy it to hub and that's it. The process to deploy the binaries could be controlled the same way where only infra.ci.jenkins.io could have to credentials to deploy to JFrog.

@alecharp do you know if Maven can use a GitHub release's published artifact (or if there could be a Maven repository per repository, that could, then, be mirrored on JFrog) ?

it seems to be technically possible (https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-apache-maven-registry) but that would mean to give infra.ci.jenkins.io permissions to write on the repository, no?

Not sure about the mirroring nor if, with the effort to reduce the bandwidth, it is something we should do. Users would just have to mirror the GitHub repository themself or declare it in their pom.xml.