Drop 2.319.x

[timja]

This is becoming a large maintenance burden.

So many pinned plugins on this line and lots are failing due to it.

Let's drop it.

See also #1063 (comment)

[jglick]

Hmm, looks like 2.332.x is not in great shape!

[timja]

Started
java.lang.NoSuchMethodError: 'boolean org.kohsuke.groovy.sandbox.SandboxTransformer.mightBePositionalArgumentConstructor(org.codehaus.groovy.ast.expr.VariableExpression)'
at com.cloudbees.groovy.cps.SandboxCpsTransformer.visitAssignmentOrCast(SandboxCpsTransformer.java:93)
at com.cloudbees.groovy.cps.CpsTransformer$42.run(CpsTransformer.java:1171)
at com.cloudbees.groovy.cps.CpsTransformer.makeChildren(CpsTransformer.java:446)
at com.cloudbees.groovy.cps.CpsTransformer.makeNode(CpsTransformer.java:409)
at com.cloudbees.groovy.cps.CpsTransformer.visitDeclarationExpression(CpsTransformer.java:1164)
at org.codehaus.groovy.ast.expr.DeclarationExpression.visit(DeclarationExpression.java:89)
at com.cloudbees.groovy.cps.CpsTransformer.visit(CpsTransformer.java:357)
at com.cloudbees.groovy.cps.CpsTransformer.visitExpressionStatement(CpsTransformer.java:589)
at org.codehaus.groovy.ast.stmt.ExpressionStatement.visit(ExpressionStatement.java:42)

Mean anything to anyone? cc @dwnusbaum ?

[jglick]

#1507 pinned script-security in the 2.332.x line; perhaps it should have also pinned the version of workflow-cps @dwnusbaum?

[dwnusbaum]

Yeah probably, I will take a look. Why would it not have failed in #1507 though?

[dwnusbaum]

Actually no, workflow-cps was already frozen on the 332.x line: https://github.com/dwnusbaum/bom/blob/f2ca765c169a9ee18ba92b4096d19eab2f2ee169/bom-2.332.x/pom.xml#L136, that's why I didn't freeze it in my PR.

[dwnusbaum]

I think #1512 is the problem (A GitHub action specifically filed a PR to update the 332.x line). I do not understand how that passed CI though.

EDIT: I think the issue is that only the newest and oldest lines are tested in the CI build, and both 2.332.x and 2.319.x have frozen versions of script-security and workflow-cps (the versions are distinct in each line), so the CI build didn't really test the effects of #1512.

With this PR, the CI build starts testing 2.332.x, so things fail. #1512 needs to be reverted. IDK if there is some way to configure updatecli to have it ignore everything besides bom-weekly/ to prevent this kind of issue in the future.

[jglick]

some way to configure updatecli to have it ignore everything besides bom-weekly/

So updatecli is being used for two things: core and plugins.

In the case of core, it updates the weekly version, which Dependabot cannot do. That gets tested, so fine.

In the case of plugins, Dependabot handles bom-weekly but the whole point of using updatecli is to propose updates to plugins otherwise pinned on LTS lines because of version constraints, which Dependabot cannot handle. Yet to avoid swamping ci.jenkins.io we only test weekly plus the oldest line, so the proposed updates on intermediate lines are not guaranteed to be correct at all.

We could run updatecli only on the oldest line, though it is actually the newer lines where it is more useful.

Not sure what to do besides just removing the updatecli plugin code. It does not work as nicely as Dependabot anyway. We do not really need this functionality.

[jglick]

Some sort of jakarta-mail problem

FATAL: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype
java.util.ServiceConfigurationError: jakarta.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype
	at java.base/java.util.ServiceLoader.fail(ServiceLoader.java:589)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNextService(ServiceLoader.java:1237)
	at java.base/java.util.ServiceLoader$LazyClassPathLookupIterator.hasNext(ServiceLoader.java:1265)
	at java.base/java.util.ServiceLoader$2.hasNext(ServiceLoader.java:1300)
	at java.base/java.util.ServiceLoader$3.hasNext(ServiceLoader.java:1385)
	at jakarta.mail.Session.loadProviders(Session.java:964)
	at jakarta.mail.Session.<init>(Session.java:254)
	at jakarta.mail.Session.getInstance(Session.java:281)
	at hudson.tasks.Mailer$DescriptorImpl.createSession(Mailer.java:415)
	at hudson.tasks.Mailer$DescriptorImpl.createSession(Mailer.java:353)
	at jenkins.plugins.mailer.tasks.MimeMessageBuilder.buildMimeMessage(MimeMessageBuilder.java:199)
	at hudson.tasks.MailSender.createEmptyMail(MailSender.java:407)
	at hudson.tasks.MailSender.createFailureMail(MailSender.java:274)
	at hudson.tasks.MailSender.createMail(MailSender.java:182)
	at hudson.tasks.MailSender.run(MailSender.java:112)
	at hudson.tasks.Mailer.perform(Mailer.java:175)
	at hudson.tasks.Mailer.perform(Mailer.java:138)

[jglick]

diff --git pom.xml pom.xml
index 34f706b..bdfdd67 100644
--- pom.xml
+++ pom.xml
@@ -103,6 +103,10 @@
           <groupId>org.jenkins-ci.plugins</groupId>
           <artifactId>mailer</artifactId>
         </exclusion>
+        <exclusion>
+            <groupId>com.sun.mail</groupId>
+            <artifactId>javax.mail</artifactId>
+        </exclusion>
       </exclusions>
     </dependency>
     <dependency>

in target/local-test/pct-work/mailer fixes the issue. Trying to figure out if this is related to #1291, or jenkinsci/mailer-plugin#144, or jenkinsci/workflow-basic-steps-plugin#168, etc. CC @basil in case you happen to know what is going on here.

[jglick]

And it is not until jenkinsci/mailer-plugin#183 (as yet unreleased) that dependency:tree omits javax.mail. Why would it matter? None of workflow-basic-steps, javax-mail-api, and jakarta-mail-api are pinned, and jenkinsci/mailer-plugin@435.v79ef3972b_5c7...438.v02c7f0a_12fa_4 only updates the BOM import which should not be relevant since PCT testing overrides everything from the current megawar.

[jglick]

mailer also broken in 2.346.x but working in 2.361.x so I suppose the version bump in #1291 mattered somehow.

[jglick]

 [ERROR] Failed to execute goal org.jenkins-ci.tools:maven-hpi-plugin:3.33:resolve-test-dependencies (default-resolve-test-dependencies) on project antisamy-markup-formatter: Unable to resolve dependencies: Could not resolve dependencies for project org.jenkins-ci.plugins:antisamy-markup-formatter:hpi:2.7: Could not find artifact org.jenkins-ci.plugins:mailer:jar:435.437.vec1ef333b_df7 in repo.jenkins-ci.org (https://repo.jenkins-ci.org/public/) -> [Help 1]

That plugin is JEP-305 (in fact JEP-229) enabled, so I am not sure why it is not looking in incrementals. (PCT passed locally with my personal Maven settings.) 🤷 will assume that is somehow related to using a prerelease version.