Edited/Blocked Notification

Renovate will not automatically rebase this PR, because it does not recognize the last commit author and assumes somebody else may have edited the PR.

You can manually request rebase by checking the rebase/retry box above.

⚠️ Warning: custom changes will be lost.

I can duplicate the git plugin test failure with the command:

PLUGINS=git TEST=GitSCMTest#trackCredentials LINE=weekly bash ./local-test.sh

The test failure is fixed when I revert pull request:

• Update dependency org.jenkins-ci.plugins:credentials to v1497 #6503

I've submitted the revert to this branch. It may not fix all the test failures, but it is known to fix at least one of the test failures.

I can duplicate the oidc-provider plugin test failure with the command:

PLUGINS=oidc-provider TEST=IdTokenCredentialsTest#persistence LINE=weekly bash ./local-test.sh

That test failure is fixed by reverting pull request:

• Update dependency org.jenkins-ci.plugins:credentials to v1495 #6494

I can duplicate the docker-commons test failure with the command:

PLUGINS=docker-commons TEST=DockerServerCredentialsTest#configRoundTripEmpty LINE=weekly bash ./local-test.sh

The test failure is resolved by reverting the two updates to the credentials plugin. I didn't attempt to isolate the issue to one version or the other, since other test failures seem to indicate we'll need to revert both of them.

I can duplicate the http_request plugin test failure with the command:

PLUGINS=http_request TEST=HttpRequestStepCredentialsTest#trackCredentials  LINE=weekly bash ./local-test.sh

The test passes when both credential releases are removed. Since it is a credential tracking issue, I am reasonably confident that it only requires the most recent credential release to be removed

@timja and @janfaracik it looks like the most recent two releases of the credentials plugin are failing tests in the plugin BOM. Detailed steps to duplicate several of the failures are included in the preceding comments on this pull request.

FTR

org.htmlunit.FailingHttpStatusCodeException: 404 Not Found for http://localhost:46035/jenkins/credentials/store/system/domain/_/credential/test/update
	at org.htmlunit.WebClient.throwFailingHttpStatusCodeExceptionIfNecessary(WebClient.java:762)
	at org.htmlunit.WebClient.getPage(WebClient.java:514)
	at org.htmlunit.WebClient.getPage(WebClient.java:413)
	at org.htmlunit.WebClient.getPage(WebClient.java:550)
	at org.htmlunit.WebClient.getPage(WebClient.java:532)
	at org.jvnet.hudson.test.JenkinsRule$WebClient.goTo(JenkinsRule.java:2729)
	at org.jvnet.hudson.test.JenkinsRule$WebClient.goTo(JenkinsRule.java:2708)
	at io.jenkins.plugins.oidc_provider.IdTokenCredentialsTest.lambda$persistence$1(IdTokenCredentialsTest.java:102)

I'm able to duplicate the matrix-project failure locally with the command:

PLUGINS=matrix-project LINE=weekly TEST=MatrixProjectTest bash ./local-test.sh

Reverting the credentials plugin changes does not fix those failures. Something else is causing them.

I'm able to duplicate the same issue with the matrix-project-plugin repository using the commands:

gh pr checkout 759 # Update parent pom to allow compilation with Jenkins 2.556
mvn clean -Dtest=MatrixProjectTest#deletedLocked* -Djenkins.version=2.556 test

The matrix plugin tests are fixed if I revert Jenkins 2.556 pull request:

• Introduce experimental API for adding actions to experimental Run UI jenkins#11204

I believe that @janfaracik is working to revise that pull request in the new core pull request:

• Fix legacy context menu items not working jenkins#26525

Thanks! Spotted the issue and found another one - working on a fix now, should be up within the hour.

I've added a temporary exclusion of the two known failing tests so that we can update the weekly baseline to 2.556. I'll remove that exclusion when 2.557 is released with the fixes that @janfaracik is implementing.

I also plan to explore further to see if the other test failures in this pull request are related to the same core pull request. That might lobby to exclude those test failures and allow the most recent releases of the credentials plugin to be included in the plugin BOM.

Opened jenkinsci/jenkins#26526 to fix the above

The two failures related to trackCredentials (git plugin and http_request plugin) are due to those plugins testing for the presence of a "usage" HTML id in the individual credentials page. Previous versions of the credentials plugin had an h2 header with id="usage". The most recent releases have a div with id="usage-present". It can either be changed in the plugin tests or changed in the credentials plugin. I've asked for guidance in issue report:

• HTML id for 'usage' has been removed from individual credential pages credentials-plugin#1032

so that we can update the weekly baseline to 2.556. I'll remove that exclusion when 2.557 is released with the fixes

Should we not be checking for regressions in bom before cutting a weekly release?

Should we not be checking for regressions in bom before cutting a weekly release?

That's certainly a good idea, though very few regressions in core have been detected by the plugin BOM. Most of the regressions that are detected by plugin BOM increments of the weekly line are plugin regressions. This particular pull request has cost me multiple hours to identify the issues, but only one of the issues is from Jenkins core. All the other issues are related to changes in plugins.

If you're volunteering to become a plugin BOM release lead, then I'm open to the idea. If you're seeking volunteers or just proposing that it be added to the duties of the plugin BOM release lead, then I'm not ready to volunteer. We have a shrinking pool of plugin BOM release leads (currently 4) and I don't think we'll increase the pool of release leads by adding more tasks.

If other plugin BOM release leads agree, we could run a plugin BOM test of the most recent Jenkins core incremental build on Monday, react to any failures in Jenkins core, and further assure the success of the Tuesday weekly build. I don't have tooling for that, but if someone wants to create tooling that does it, I'm open to use that tooling.

Something similar could be done with the acceptance test harness so that its tests are run on the last incremental build of Jenkins weekly before the weekly release.