Remove custom arguments from Maven Release Plugin configuration

[basil]

Fixes a regression exposed by jenkinsci/pom#281 and #6914. In order for release artifacts to be signed by maven-gpg-plugin and maven-jarsigner-plugin during the release:prepare goal, we rely on

jenkins/pom.xml

Lines 521 to 540 in d25704c

	<profile>
	<id>release</id>
	<build>
	<plugins>
	<plugin>
	<artifactId>maven-gpg-plugin</artifactId>
	<!-- Version specified in parent POM -->
	<executions>
	<execution>
	<id>sign-artifacts</id>
	<goals>
	<goal>sign</goal>
	</goals>
	<phase>verify</phase>
	</execution>
	</executions>
	</plugin>
	</plugins>
	</build>
	</profile>

and

jenkins/war/pom.xml

Lines 623 to 648 in d25704c

	<profile>
	<!-- sign war -->
	<id>sign</id>
	<build>
	<plugins>
	<plugin>
	<artifactId>maven-jarsigner-plugin</artifactId>
	<executions>
	<execution>
	<id>signWar</id>
	<goals>
	<goal>sign</goal>
	</goals>
	<phase>pre-integration-test</phase>
	<configuration>
	<archive>${project.build.directory}/${project.build.finalName}.war</archive>
	<arguments>
	<argument>-tsa</argument>
	<argument>http://timestamp.digicert.com</argument>
	</arguments>
	</configuration>
	</execution>
	</executions>
	</plugin>
	</plugins>
	</build>

, activated by the release and sign profiles respectively. To activate these profiles during the release:prepare goal we currently rely on

jenkins/pom.xml

Lines 428 to 429 in d25704c

	<!-- enable release profile during the release, create IPS package, and sign bits. -->
	<arguments>-P release,sign</arguments>

, which happens to expose a serious bug in recent versions of Maven Release Plugin as explained in jenkins-infra/helpdesk#3143 (comment). Fortunately for us, we can work around the problem by omitting any custom arguments from our Maven Release Plugin configuration as in jenkins-infra/release#291 and this PR, instead enabling these profiles via an <activeProfiles> setting in settings-release.xml. Note that we cannot enable these profiles using releaseProfiles because that setting only applies to the release:stage and release:perform goals, not the release:prepare goal.

Proposed changelog entries

Support staging of releases (regression in 2.361).

Proposed upgrade guidelines

N/A

Submitter checklist

• (If applicable) Jira issue is well described
• Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• Appropriate autotests or explanation to why this change has no tests
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadoc, as appropriate.
• New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO") if applicable.
• New or substantially changed JavaScript is not defined inline and does not call eval to ease future introduction of Content-Security-Policy directives (see documentation on jenkins.io).
• For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• There are at least 2 approvals for the pull request and no outstanding requests for change
• Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• Changelog entries in the PR title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood
• Proper changelog labels are set so that the changelog can be generated automatically
• If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[daniel-beck]

Perhaps beyond the immediate scope of this, but given linked PRs and motivation, could we fail the build if it's a release build, and -Darguments is set, or similar? Seems like a year or two from now, nobody will remember this and we'll happily add all sorts of stuff via -Darguments again and will have a much more harmful staging experience -- it was pure luck this happened during a really unusual release where we staged not several days before the intended release, but on the same day. (That seems like the cleaner solution, if possible, than adding comments everywhere we're now removing arguments from to remember not to do this again.)

[basil]

I am hoping the Maven folks will fix their bug, so I see no need to do what you are suggesting.

[daniel-beck]

AFAIUI, depends on jenkins-infra/release#292, which is merged (i.e., this is fine).

[basil]

I plan to monitor the next weekly release to ensure that signing takes place as expected, then backport this to stable-2.361.

---

This PR is now ready for merge. We will merge it after approximately 24 hours if there is no negative feedback. Please see the merge process documentation for more information about the merge process. Thanks!

[daniel-beck]

I am hoping the Maven folks will fix their bug, so I see no need to do what you are suggesting.

FTR another option might be in core to always require an alternative deployment repository. Even regular release builds (pre-2.361) have

02:09:12.888  [INFO] [INFO] --- maven-deploy-plugin:2.8.2:deploy (default-deploy) @ jenkins-parent ---
02:09:12.888  [INFO] [INFO] Using alternate deployment repository releases::default::https://repo.jenkins-ci.org/releases
02:09:12.888  [INFO] [INFO] Uploading to releases: https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-parent/2.360/jenkins-parent-2.360.pom
02:09:13.591  [INFO] [INFO] Uploaded to releases: https://repo.jenkins-ci.org/releases/org/jenkins-ci/main/jenkins-parent/2.360/jenkins-parent-2.360.pom (5.2 kB at 7.7 kB/s)

[basil]

I am hoping the Maven folks will fix their bug, so I see no need to do what you are suggesting.

FTR they did, in 3.0.0-M7.