-
-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Core Release: Staging not working anymore #3143
Comments
About the
|
As per https://maven.apache.org/plugins/maven-deploy-plugin/#major-version-upgrade-to-version-3-0-0:
Which relates to the following Maven settings file used during releases: https://github.com/jenkins-infra/release/blob/master/utils/release.bash#L440 |
Weirdly, https://github.com/apache/maven-deploy-plugin/blob/16541da43c51237cf7183c4500a576108ad946b8/src/test/java/org/apache/maven/plugins/deploy/DeployMojoTest.java#L586-L600 indicates this should still work. |
2.356:
2.370:
So it looks like it silently ignores "invalid" values (because an undefined value fails the build); or something else is wrong. |
I was aware of this change, but based on apache/maven-deploy-plugin#15 I thought that the old format was still supported for backward compatibility purposes. |
Perhaps that backwards compatibility glue in |
Actually local testing shows that this problem wasn't introduced by the upgrade of |
As far as I can tell the |
Bisected to apache/maven-release@419114d / MRELEASE-998 (CC @rfscholte). Can be reproduced with Maven Release Plugin 3.0.0-M6 by running |
Also CC'ing @michael-o as this seems like a fairly serious bug. |
@basil Shit, this change is huge. Can you turn this into an IT by any chance? |
Sorry, the above is all I can offer. I've been testing this locally with https://github.com/basil/simple-maven-project-with-tests and a local copy of Nexus with two different repositories, which is how I was able to bisect the change. |
The combination of jenkins-infra/release#291, jenkinsci/jenkins#7138, and jenkins-infra/release#292 (+ backports) should be sufficient to work around the problem for us. |
Is there a Jira issue, in case we want to backport those to 2.361.3? Otherwise, I'll file one. |
This is the ticket, which is in GitHub rather than Jira, which means our backport process doesn't work with it, a problem I have opined about at length in the past. If we used one issue tracker for everything in the Jenkins project, this would not be a problem. |
would be good to create an issue on Maven project side other this will be lost.... |
As I wrote in #3143 (comment), the above is all I can offer. |
As far as I can see the problem comes from an external project (e.g not a Jenkins project). |
I have notified the Maven developers in this thread, and I do not intend to take any further action. |
Thanks a lot. |
|
The workaround has been backported to |
Service(s)
release.ci.jenkins.io
Summary
The Jenkins Core release process is able to stage part of the release as per https://github.com/jenkins-infra/release#stage.
For instance: https://github.com/jenkins-infra/release/blob/security-2.356/profile.d/security#L32 where the name of the "private maven repository" to be used for staging is specified in the build profile.
With the security release 2.370, the deployment of the Jenkins artifacts was done to the public repository instead of the staging repository specified in https://github.com/jenkins-infra/release/blob/security-2.370/profile.d/security#L32
Previous security release involving staging (security-256) behaved as expected, so something change between both.
@daniel-beck and I tracked the issue to (at first sight) a major bump of the
maven-deploy-plugin
(description to be updated).We have to confirm, diagnose and fix this behavior as soon as possible to avoid any security to be exposed before its end.
Reproduction steps
No response
The text was updated successfully, but these errors were encountered: