Add authentication-tokens to the managed set

[MarkEWaite]

Add authentication-tokens plugin to managed set

Use latest release for all versions now included in bom.

Fixes #2095

Testing done

Confirmed that tests work with the following commands:

$ mvn -P 2.375.x --pl sample-plugin verify
$ mvn -P 2.387.x --pl sample-plugin verify
$ mvn -P 2.401.x --pl sample-plugin verify
$ mvn -P weekly  --pl sample-plugin verify
$ PLUGINS=authentication-tokens bash local-test.sh

Submitter checklist

Beta Give feedback

1. Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
2. Ensure that the pull request title represents the desired changelog entry
3. Please describe what you did
4. Link to relevant issues in GitHub or Jira
5. Link to relevant pull requests, esp. upstream and downstream changes
6. Ensure you have provided tests - that demonstrates feature works or fixes the issue

[jglick]

Do you not want to full-test this?

[MarkEWaite]

Do you not want to full-test this?

Thanks for the pointer. Yes, I've labeled it with full-test and started a new run. I expect it to pass the full-test. Once it has passed that, I'll merge it and plan to release the master branch.

[MarkEWaite]

Will require a new release of the plugin compatibility tester before this can be merged. Jenkins 2.375.x needs authentication tokens plugin 1.4 but that release includes the scm URL with a git:// protocol. The git:// protocol is now rejected by GitHub. That prevents checkout of the authentication token plugin 1.4 sources, so the testing fails.

Moving this to draft status, since it can't be merged until after a new release of PCT.

Needs merge and release of

• Adapt to authentication-tokens 1.4 git:// in pom file plugin-compat-tester#566

[jglick]

OK, though normally we would prefer to include it implicitly via some other plugin with visible features.

Ideally we would use dependency:analyze or similar to verify that this POM includes a minimal set of dependencies.

[MarkEWaite]

Thanks. I had not considered that technique. I think that means that the final conclusion would be to resolve the issue:

• Add Docker Commons to the managed set #2096

with pull request

• Add docker-commons to the managed set #2220

and include the Docker Commons API plugin in the sample plugin. It depends on authentication-tokens.

Since docker-commons is an api plugin without visible features, should we consider adding Docker Pipeline to the managed set (110 000 installations) ?

[jglick]

Probably yes.

[MarkEWaite]

Ideally we would use dependency:analyze or similar to verify that this POM includes a minimal set of dependencies

I'm not skilled with maven, but I ran mvn --pl sample-plugin dependency:analyze and it reported many declared but unused dependencies. I tried removing the first one in the list, jsch, and that caused mvn --pl sample-plugin verify to fail with the report that jsch is not listed in the test classpath of the sample plugin.

However, the caffeine-api plugin is not mentioned in the sample-plugin pom file yet is mentioned in the bom-weekly. Apparently some plugins do not need to be listed in sample-plugin/pom.xml but it is not apparent to me which must be listed and which can be skipped.

Clearly I have much more to learn about maven and dependencies.

[jglick]

the caffeine-api plugin is not mentioned in the sample-plugin pom file yet is mentioned in the bom-weekly. Apparently some plugins do not need to be listed in sample-plugin/pom.xml but it is not apparent to me which must be listed and which can be skipped.

Those which would be dependencies of other explicitly listed plugins can be omitted, and preferably should (especially in the case of API-only plugins). Whether this is amenable to mechanical enforcement is another question.

I ran … dependency:analyze and it reported many declared but unused dependencies

Unfortunately it is designed for plain old Java programs and there are numerous subtleties specific to Jenkins plugins.