Try matrix-auth 3.1.7-rc416.ad0d7cac657a

[daniel-beck]

Downstream of jenkinsci/matrix-auth-plugin#136

[daniel-beck]

Docs at https://github.com/jenkinsci/bom#incrementals claim this is supposed to work?

[MarkEWaite]

Docs at https://github.com/jenkinsci/bom#incrementals claim this is supposed to work?

Yes, and it will work once the incremental build has been deployed to repo.jenkins-ci.org. The deployment happens as the last step of the Pipeline and the Pipeline job has not yet completed.

[daniel-beck]

The deployment happens as the last step of the Pipeline and the Pipeline job has not yet completed.

Unsure what you mean. https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/plugins/matrix-auth/3.1.7-rc416.ad0d7cac657a/ has been deployed an hour ago. 5 minutes later I filed this PR.

[timja]

may be to do with the artifact caching proxy? Anytime I see do-proxy in a build failure log I'm suspicious

[MarkEWaite]

I can't resolve that version of matrix-auth locally either. I used the git plugin as a test and added an incremental version of the git client, confirmed that it would build. I added a dependency on matrix-auth plugin with the default version and confirmed the git plugin compiles as well. I added a dependency on matrix-auth plugin 3.1.7-rc416.ad0d7cac657a and maven reports that it cannot resolve the dependency.

I'm not sure what it is, but as far as I can tell, it is not specific to the bill of materials and is not specific to the artifact caching proxy.

[MarkEWaite]

There was an issue somewhere with SHA-1 strings that end in the letter a or the letter b and their being misinterpreted by something, but I thought that was specific to dependabot, not anything related to maven.

[MarkEWaite]

@daniel-beck are you able to reference that incremental artifact from the pom file of another project?

[daniel-beck]

Interestingly, this new PR build seems to have passed the initial sample-plugin error.

[MarkEWaite]

Interestingly, this new PR build seems to have passed the initial sample-plugin error.

If that's the case, then it may be the artifact caching proxy. I added the skip-artifact-caching-proxy label to the pull request earlier before the close and reopen.

However, I still can't explain why I can locally resolve the matrix-auth version provided by the plugin bom and the matrix-auth incremental 3.1.7-rc415.1723c7a76490 from the master branch, but cannot resolve the matrix-auth incremental 3.1.7-rc416.ad0d7cac657a from the PR-136 build.

[MarkEWaite]

However, I still can't explain why I can locally resolve the matrix-auth version provided by the plugin bom and the matrix-auth incremental 3.1.7-rc415.1723c7a76490 from the master branch, but cannot resolve the matrix-auth incremental 3.1.7-rc416.ad0d7cac657a from the PR-136 build.

I missed the maven output that warned me that it had cached the earlier lookup failure. When I ran mvn -U clean -DskipTests verify it downloaded the 3.1.7-rc416.ad0d7cac657a incremental dependency from PR-136.

As Daniel has told me before, "caches be caching"...

[basil]

I tested this locally with my recent maven-hpi-plugin changes in PCT and it works fine. Confirming this is sufficient to unblock me.

[daniel-beck]

@basil Why did you abort the CI build?

[basil]

@basil Why did you abort the CI build?

Last night a few BOM builds were stuck after a controller restart, so I aborted some of them to allow at least one of them (workflow-job) to succeed and get auto-merged. In general this repository and ci.jenkins.io appears to be in a pretty bad state right now.

In any case, I wouldn't wait for this PR to go green before merging and releasing your matrix-auth changes, especially because they are needed in order to adopt the latest version of PCT in this repository. I tested this PR locally with PLUGINS=matrix-auth bash local-test.sh and it works just fine.

[basil]

Build is green

[daniel-beck]

So what's the root cause? Based on this experiment and #1435 (comment), I see these candidates:

• configuration-as-code: It provides JenkinsConfiguredWithCodeRule to others in its test harness, which is incompatible with a job-dsl dependency, which is commonly combined with configuration-as-code for job-level configuration.
• job-dsl: It has an optional dependency on config-file-provider, while integrating with configuration-as-code, which provides JenkinsConfiguredWithCodeRule, which doesn't work with the optional dependency.
• jenkins-test-harness or plugin-compat-tester: The classpath not having optional dependencies doesn't match them being installed when running JenkinsRule (in a PCT environment).
• …?

The only thing I know for sure is it's not matrix-auth 😇 (but will still look into creating a release with the workaround).

Having to add a dependency on config-file-provider which is not used at all, or not being able to use JenkinsConfiguredWithCodeRule, is not a good experience as a plugin maintainer. So making the solution the burden of the plugin maintainer shouldn't be the solution.

Either of the following seem fairly simple ways forward:

• Deprecate JenkinsConfiguredWithCodeRule and recommend RealJenkinsRule instead. Based on Switch JCasC test to RealJenkinsRule matrix-auth-plugin#136, it seems like minimal code changes are needed, so it doesn't look like it provides a lot of value.
• job-dsl should be fixed so that this error is caught and treated as if config-file-provider was not installed, to accommodate the affected test environment. (There may be potential here for better developer docs as well.)

[basil]

So what's the root cause?

I don't know Daniel, as I have told you several times I have not investigated this deeply compared to other priorities. This experiment definitely helps. Using RealJenkinsRule in more places is always a good idea and would have caught jenkinsci/configuration-as-code-plugin#2235 and jenkinsci/configuration-as-code-plugin#2236 I think.