...

• The migration cannot be tested in the Sandbox unfortunatelly.
  • The Sandbox is specifically designed to block Nexus2 pushes and we will not be able to confirm if the artifacts were pushed correctly.
  • The migration changes depend on pom.xml file changes in the source code which cannot be tested unless these changes are merged.
• Please notice that we can't keep both version-java-daily (and similar local templates) and gerrit-maven-stage (from global-jjb) running successfully at the same time.
  • The plugin in question  "nexus-staging-maven-plugin" only works for the old templates and, once we remove it's usage to be able to migrate, it will cause the old jobs to fail.

Triggering the stage release jobs

Please use the comment "stage-release" to trigger. 

Release process

The release process is still the same:
 - The PTL works towards their component development (I believe teams work on JAR artifact changes first and then Docker images)
- Once the PTL has a JAR artifact ready for releasing, they will trigger the gerrit-maven-stage job using the "stage-release" comment in Gerrit.
- The PTL will create a LF support jira ticket with the link of the gerrit-maven-stage job that produced their "autorelease" package (The same way they were already doing for release-java-daily jobs)
- LF will make a release in Nexus2
- PTL works towards their Docker images (which will use the previously released JARs for building)
- Once the PTL has a Docker images ready for releasing, they will trigger the gerrit-maven-docker-stage job using the "stage-release" comment in Gerrit.
- The PTL will create a LF support jira ticket with the link of the gerrit-maven-docker-stage job that produced their images (The same way they were already doing for docker-java-daily jobs)
- LF will make the release in Nexus3