[Plugin] [Review needed] logfilesizechecker-plugin pipeline support

I opened a pull request for the logfilesizechecker plugin to make it compatible with pipelines. I haven't gotten a response yet for the past week, as the plugin isn't maintained. Is anyone interested in reviewing the change? https://github.com/jenkinsci/logfilesizechecker-plugin/pull/3 Thanks,

Re: Need help debugging hudson.remoting.ChannelClosedException "channel is already closed" in Remoting (I have logs)

Hi Oleg, Thanks again for your help. On Sun, Feb 4, 2018 at 10:16 PM, Oleg Nenashev wrote: > > Hmm... I am concerned about the Blocking IO (BIO) network layer being used by > your client. This mode is generally not recommended for production use, > timeouts in the

Re: Proposal: Automating dependency management for repositories inside the jenkinsci org

On Wednesday, May 22, 2019 at 11:47:09 PM UTC-7, Oleg Nenashev wrote: > > I am fine with going forward with enabling Dependabot for a wider set of > plugins. > Can you please add the following repositories: https://github.com/jenkinsci/swarm-plugin

Request to be made maintainer of jquery-plugin

See: https://github.com/jenkins-infra/repository-permissions-updater/pull/1263 -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to

[throttle-concurrents] Add basil to throttle-concurrents

I would like to become a maintainer of throttle-concurrents, at minimum to release jenkinsci/throttle-concurrent-builds-plugin#57 and jenkinsci/throttle-concurrent-builds-plugin#58. I have written the following proposal regarding how to mitigate risk as this plugin transitions to a maintained

Re: [throttle-concurrents] Add basil to throttle-concurrents

The last link should have been: https://github.com/jenkins-infra/repository-permissions-updater/pull/1325 On Tue, Nov 12, 2019 at 3:52 PM Basil Crow wrote: > > I would like to become a maintainer of throttle-concurrents, at > minimum to release jenkinsci/throttle-concurrent-builds-

[timestamper-plugin] Add basil to timestamper

I would like to become a co-maintainer of the timestamper plugin to be able to process and release the current PR backlog. See: https://github.com/jenkins-infra/repository-permissions-updater/pull/1308 Thanks, Basil -- You received this message because you are subscribed to the Google Groups

Re: Diamond Dependencies and Upstreams at Scale

On Wed, May 20, 2020 at 8:39 AM Gerald Wiltse wrote: > > it still captures the problem with visuals, and helps demonstrate demand for > a solution. When we were using Build Flow before the creation of Pipeline, my users really liked the visualization provided by the buildgraph-view plugin. I

Re: RCA of memory conditions on Ubuntu EC2 agents on ci.jenkins.io causing test instability

On Fri, Jun 5, 2020 at 1:24 PM Jesse Glick wrote: > The next step would be PRs to infrastructure repositories. I agree. Unfortunately I have spent too much time on this issue already and cannot volunteer to become an infrastructure developer at present. > 256Mb seems low for a Surefire JVM—this

RCA of memory conditions on Ubuntu EC2 agents on ci.jenkins.io causing test instability

I recently stabilized my plugin's test suite on ci.jenkins.io. The following is my root cause analysis. At present there are eight online Ubuntu EC2 agents on ci.jenkins.io. Three of these are high memory and five of these are not: • EC2 (aws) - High memory ubuntu 18.04 (i-067cdb5c4dd6bbc66) •

Re: Script Security check during descriptor load

Hey Alex, Coincidentally, I ran across a very similar circular dependency issue recently in the Copy Artifact plugin (JENKINS-62267 ). On further examination, I also found a similar circular dependency issue in the Folders plugin (JENKINS-60393

Unforking Commons FileUpload

Jenkins core uses a fork of Commons FileUpload 1.3.1. Changes to org.apache.commons.fileupload.FileItem and org.apache.commons.fileupload.disk.DiskFileItem were made in 1.3.1-jenkins-1, and a change to org.apache.commons.fileupload.MultipartStream was made in 1.3.1-jenkins-2. The change made in

Re: Jenkins BOM and base Jenkins version

The documentation says: "Prefer .1 LTS releases over weekly versions and later releases within an LTS line for greater compatibility." cloudbees-folder seems to use 2.204.6 because its dependency snakeyaml-api

Re: JEP-227 & JEP-228: request for assistance

On Fri, Nov 6, 2020 at 1:38 PM Jesse Glick wrote: > > Merged toward 2.266. Nice work on some long-needed changes. As a community member I would like to thank your employer for funding this work and to thank you for implementing it. -- You received this message because you are subscribed to the

Re: Unforking Commons FileUpload

On Tue, Jan 12, 2021 at 7:33 PM Jesse Glick wrote: > > sounds like it would break normal usage from Jenkins The status quo is Commons FileUpload 1.3.1-jenkins-2 (patch in my previous message), which _already_ removed serialization from DiskFileItem. Here is the timeline of events upstream: Feb

Re: ASM in core

On Fri, Jun 11, 2021 at 2:19 AM Robert Sandell wrote: > > Some historical context to know where we "old timers" are coming from :) > https://kohsuke.org/2012/03/03/potd-package-renamed-asm/ Thanks for providing this context, Robert! I have a tremendous amount of respect for all the old-timers in

Re: ASM in core

On Fri, Jun 11, 2021 at 3:45 AM Ullrich Hafner wrote: > > Wouldn’t it be helpful if we would also suggest which option we prefer? > Otherwise every plugin author needs to rethink the same options again and > again. > > E.g., option 1 did break all my integration tests with the token macro

Re: Backporting for LTS 2.289.2 started

On Mon, Jun 14, 2021 at 12:50 AM Tim Jacomb wrote: > > Any thoughts on https://issues.jenkins.io/browse/JENKINS-64347? > It has only been in one weekly version so far. No strong preference here and I am not personally affected by this bug, but it seems like it would affect most users of macOS

Re: ASM in core

On Mon, Jun 14, 2021 at 7:36 PM Jesse Glick wrote: > > JNR may be a similar story. I see all of two usages in core—both disabled > unless you set a system property. Just deleting it all may be easier I had already noticed that as well and thought about opening such a PR to delete all usages of

Re: Windows Tests failing on Timeout

On Fri, Jun 4, 2021 at 2:07 PM Bryan Stopp wrote: > > Yeah, I'd hate to have to disable all windows validation because my restart > validation tests can't get a test runner in 15 seconds after a reboot. Seems > like a limitation of the testing framework... I've similarly given up and disabled

Re: ASM in core

ASM has been shipped by core, unshaded, as a transitive dependency of JNR (_not_ JNA) since JNR was introduced in 2013. Removing core's dependency on JNR (and therefore its transitive dependency on unshaded ASM) is a large and yet unscoped project; similarly, hiding core dependencies from plugins

Re: ASM in core

On Thu, Jun 10, 2021 at 10:03 AM jn...@cloudbees.com wrote: > > 1 -> Which is fine until the library evolves in a binary incompatible way.. > and the ASM library is KNOWN to do this. > 2-> has many pitfalls and this only works if no one else depends on your > plugin otherwise they also get

Re: ASM in core

On Thu, Jun 10, 2021 at 11:28 AM Tim Jacomb wrote: > > It would be good to see a more recent report given we’re on version 9 in core > to see if anything has changed in recent versions Great point, Tim. Core 2.273 shipped with ASM 5.0.3, prior to the upgrade of JNR (and therefore the accidental

Re: ASM in core

Dear James, On Thu, Jun 10, 2021 at 10:34 AM jn...@cloudbees.com wrote: > > Thus care needs to be taken before any library is updated Of course. Yet such care was not taken when JNR was updated in December 2020. That is why nobody noticed that the JNR update also pulled in a new ASM update, and

Re: ASM in core

On Thu, Jun 10, 2021 at 10:48 AM jn...@cloudbees.com wrote: > JenkinsRule / RestartableJenkinsRule and any other junit test not using > `RealisticJenkinsRule` do not use the hierarchical Jenkins classloader and > are hence completely unrealistic when it comes to classloading. They use the >

Error handling in Groovy initialization scripts vs JCasC

After all these years, we finally migrated from Groovy initialization scripts to JCasC on our Jenkins controllers. While any configuration error is a problem, I noticed that the way these errors are reported differs from one mechanism to the next. With Groovy initialization scripts, errors in one

Re: Error handling in Groovy initialization scripts vs JCasC

On Thu, Jun 24, 2021 at 9:07 AM Tim Jacomb wrote: > > There are some flags you can use to tune this behaviour: >

Re: Error handling in Groovy initialization scripts vs JCasC

On Thu, Jun 24, 2021 at 2:18 AM Ullrich Hafner wrote: > This is a very bad user experience (actually I don’t know of any other > application that does not start because of a configuration error). I concur. My initial impression is that JCasC lacks polish, and I was surprised to see it promoted

Re: Using JDK 11 instead of JDK 8 in default docker images

Allow me to append myself to the list of developers who would like access to Java 11 APIs. If we had access to Java 11 APIs, then this

Plugins using removed Guava APIs

I started looking into which plugins use classes or methods from Guava 11 that have been removed in Guava 30. There is plenty of low-hanging fruit if anyone is interested in contributing by rewriting these usages. The list below is far from exhaustive, but it's a start. If you maintain one of

Re: Plugins using removed Guava APIs

I found that we can easily remove Guava usages from SSH Build Agents and Node Label Parameter as well: https://github.com/jenkinsci/ssh-slaves-plugin/pull/228 https://github.com/jenkinsci/nodelabelparameter-plugin/pull/28 -- You received this message because you are subscribed to the Google

Re: Plugins using removed Guava APIs

On Thu, May 6, 2021 at 7:39 PM Basil Crow wrote: > > com/google/common/base/Objects#firstNonNull > - blueocean-pipeline-api-impl > - blueocean-pipeline-scm-api > - ec2-fleet > - gearman-plugin > - github > - jclouds-jenkins > - jira I opened PRs for a few of these: h

Re: Plugins using removed Guava APIs

On Thu, May 6, 2021 at 7:39 PM Basil Crow wrote: > > com/google/common/collect/Ranges > - audit-trail > - elastest > - http_request > - logstash > - scm-httpclient I opened PRs for a few of these: https://github.com/jenkinsci/http-request-plugin/pull/63 https://github.com/

Re: Backporting has started and the RC is scheduled for 19th May

On Mon, May 10, 2021 at 2:35 AM Oleg Nenashev wrote: > > I wonder whether we should also create a Remoting 4.8 backport this time: > https://github.com/jenkinsci/remoting/releases/tag/remoting-4.8 > There are 2 bugfixes which seem important though we could also just embed 4.8 > into the LTS

Re: Plugins using removed Guava APIs

Thank you for sharing this! I posted PRs for Timestamper and Lockable Resources: https://github.com/jenkinsci/timestamper-plugin/pull/116 https://github.com/jenkinsci/lockable-resources-plugin/pull/242 > I am wondering how best we should co-ordinate this work? I suggest writing some developer

Re: [jenkins-infra] Should we bring back wiki.jenkins.io?

On Thu, May 6, 2021 at 9:26 AM Daniel Beck wrote: > > As an example, I remember a contributor summit (FOSDEM 2020?) at which a > topic was discussed and nobody else was aware it was discussed a few years > back because the notes were in some random Google doc long forgotten about > and not

Re: bom 807 fails dependency checks in git client plugin

I already faced the same issue in jenkinsci/email-ext-plugin#291 and worked around it by adding Caffeine to my section. Of course the permanent solution is to adapt Script Security to jenkinsci/bom#505

Re: Proposal: Adopting Stapler as official Jenkins project

+1 for normalizing Stapler as a standard Jenkins sub-project. Keeping it as an independent project complicates maintenance efforts and does not provide a strong benefit. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from

Re: [jenkins-infra] Migrate chat channels from freenode to libera.chat

+1. I opened a PR to cover updating the references on jenkins.io: https://github.com/jenkins-infra/jenkins.io/pull/4384 FYI see the project registration instructions here: https://libera.chat/chanreg#project-registration -- You received this message because you are subscribed to the Google

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

+1 from me -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit

Re: Plugin end-of-life (EOL) policy

To be honest, I was a bit taken by surprise at the intensity of the discussions regarding this topic. I was expecting that we could all agree on some basic criteria, publish a simple statement to that effect on jenkins.io, and refer to that policy as necessary while doing work on new features or

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

Dear Oleg, On Sun, May 30, 2021 at 11:55 AM Oleg Nenashev wrote: > I have commented about the plugins removal in another thread. In particular, you wrote: "From the list, I am particularly concerned about Code Coverage plugins which seemed to be actively used." You expressed concern about

Plugin end-of-life (EOL) policy

Abandoned plugins cause friction for both Jenkins users and contributors alike. They cause friction for users because they are unlikely to be simpatico with newer features like Pipeline. In the worst case, they are downright incompatible with newer features like Configuration Form Modernization

Re: [Heads-up] Removing commons-digester from Jenkins Core (and the link with our plugins EOL policy discussion :-))

On Tue, May 4, 2021 at 2:02 PM Baptiste Mathus wrote: > So the big question is: what do we do? > > I personally think we should NOT make these PRs land if no maintainer steps > up. > In other words, once we merge and release the Core PR, these plugins will > likely just fail loading on newer

Re: Any where from the Run object to find out how much CPU the job is consuming?

On Tue, Mar 30, 2021 at 1:21 PM Michael Carter wrote: > > Which of course causes a lot of CPU usage on the master due to the frequent > lookups to the identical username/password. I suppose you have already concluded that the high CPU usage is caused by the abovementioned credential lookups.

Re: Orphaning the lockable-resources-plugin

Thanks for maintaining this plugin for the past few years, Tobias! I have been using this plugin since 2016 and appreciate your efforts to keep this plugin in good shape. Proper concurrency control is difficult but critical, especially in enterprise settings. Happy to help keep it going - I filed

Re: Optional automated source code formatting - prep for JEP

On Thu, Feb 25, 2021 at 1:46 AM Liam Newman wrote: > > Thanks you two, for clearly describing the issue that I'm attempting to > address. You're welcome! As I mentioned, I've done this a few times and have learned what it takes to make the changes stick across a large number of developers. >

Re: Optional automated source code formatting - prep for JEP

On Wed, Feb 24, 2021 at 3:32 AM jn...@cloudbees.com wrote: > > What I feel is also missing here is what issue is this attempting to solve. > It is proposing a solution - but what is the exact problem maintainers are > seeing; perhaps there are better ways to solve that? The problem, to me, is

Re: Proposal: Jenkins Core PR reviewers team

I'm interested in joining the Core PR reviewers team as well. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com.

Jenkins 2.303.1 LTS RC testing started

Hello everyone, The latest LTS release candidate was made public, and it is ready to be tested. The final release is scheduled for August 25, 2021. Please report your findings in this thread. Download the release from:

Re: Plugins using removed Guava APIs

On Sat, Aug 7, 2021 at 12:12 PM Basil Crow wrote: > > There are at least 25 additional plugins with confirmed Guava > regressions that must be prepared and released. Some of them have > significant adoption. I have enumerated them in this epic: > > https://issues.jenkins.io/br

Re: potential regression in master

Already done in jnr/jnr-ffi#269 jenkinsci/jenkins#5712 On Mon, Sep 6, 2021 at 9:36 AM jn...@cloudbees.com wrote: > You just beat me to it! > > creating the PRs. > > On Monday, September 6, 2021 at 5:28:34 PM UTC+1 m...@basilcrow.com wrote: > >> It's jenkinsci/jenkins#5703, which pulled in

Re: potential regression in master

It's jenkinsci/jenkins#5703, which pulled in jnr/jnr-ffi#252, which updated JUnit from 4 to 5 in jnr-ffi without putting the new JUnit 5 JAR in the test scope. That means the following JARs are now (erroneously) bundled in the Jenkins WAR: [INFO] +-

[gitlab-oauth-plugin] Add basil to gitlab-oauth

Sending this email as requested by Mark Waite. As described in jenkins-infra/repository-permissions-updater#2071, I have no actual interest in maintaining this plugin, but I need jenkinsci/gitlab-oauth-plugin#31 merged and released to facilitate the core Guava upgrade. Since I have not received a

[github-oauth-plugin] Add basil to github-oauth

Sending this email as requested by Mark Waite. As described in jenkins-infra/repository-permissions-updater#2070, I have no actual interest in maintaining this plugin, but I need jenkinsci/github-oauth-plugin#125 merged and released to facilitate the core Guava upgrade. Since I have not received a

Re: Plugins using removed Guava APIs

Thanks to everyone who has reviewed PRs, merged PRs, and shipped releases. As the Jira epic shows, the majority of plugins have been prepared, with a small number of critical PRs still awaiting merge and an even smaller number still awaiting release. These should trickle in over the coming weeks.

Re: Plugins using removed Guava APIs

Thanks to everyone who has been contributing to this effort, a number of plugins have been prepared for the Guava update and released: - Active Directory - Audit Trail - Blue Ocean (in alpha) - Gearman - Git client - HTTP Request - JUnit - Lockable Resources - Node Label Parameter - Pipeline:

Re: Plugins using removed Guava APIs

Eight CloudBees proprietary plugins appear to require preparation for the Guava upgrade, at least in the latest released versions. I have included my notes below. It would be helpful if a CloudBees employee could prepare these plugins for the Guava upgrade and release new versions. --- CloudBees

Re: Choosing Jenkins September LTS release baseline

On Tue, Aug 10, 2021 at 11:28 PM Daniel Beck wrote: > Core dependency version number semantics means anyone on a weekly release > after the LTS baseline but before the change made it into core regularly, > will not have that API and plugins will fail while appearing compatible. Ah right, I

Re: Choosing Jenkins September LTS release baseline

Thanks for getting this started! I'd like to propose also adding the core API for JENKINS-66001 (to which I just added the "lts-candidate" label) from https://github.com/jenkinsci/jenkins/pull/5599 to this LTS release. This API is intended to be consumed by the Pipeline plugins, and including it

Re: Release team members

On Thu, Oct 14, 2021 at 1:10 AM Oleg Nenashev wrote: > > Better late than never, I would like to join the group indeed. Ditto for me. Happy to help out as I have time. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from

Re: Add Mark Waite to Jep editors

+1 -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit

Re: Core build instability

I see no evidence that jenkinsci/jenkins#5687 has introduced a leak, so I do not think it should be reverted. I _do_ see evidence that registering AntClassLoader (specifically) as parallel-capable has increased the heap size requirement for pipeline-steps-doc-generator: 1280 MiB seems to be

Re: Core build instability

On Mon, Sep 20, 2021 at 12:57 PM Jesse Glick wrote: > > Any notion yet of why that would be? Why do you ask? The maximum heap size seems to have been 1516 MiB in e.g. https://ci.jenkins.io/job/Infra/job/pipeline-steps-doc-generator/job/master/299/consoleFull but had dropped to 954 MiB by e.g.

Re: Core build instability

On Tue, Sep 21, 2021 at 7:04 AM Jesse Glick wrote: > That was my best guess based on running `git bisect`: with the parallel class > loading, the docs generator failed; without it, the generator worked. But this is just _data_; it doesn't mean anything unless we extract the _insights_ out of

Re: Plugins using removed Guava APIs

With a new LTS release around the corner, I would like to set a target for the merge and release of the Guava upgrade (i.e., jenkinsci/jenkins#5707 / jenkinsci/jep#375 / JENKINS-65988). The plugin BOM test suite is passing against the incremental from jenkinsci/jenkins#5707 as of today. I also

Re: Proposal: Adding Basil Crow to the Jenkins Core maintainers team

Thanks, everyone. I would be happy to join the core team. It has been a fun ride since jenkinsci/jacoco-plugin#45. Good times, and a lot of work, ahead. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and

Re: Annotation versions

Thanks for the replies! I have been proceeding along the second path as we discussed. I saw an interesting problem in nodelabelparameter-plugin: Require upper bound dependencies error for javax.annotation:javax.annotation-api:1.2 [provided] paths to dependency are:

Re: Annotation versions

On Fri, Dec 17, 2021 at 1:22 PM 'Jesse Glick' via Jenkins Developers wrote: > > This is already in the core BOM. What else would we need to do? Sorry, I should have clarified that I was proposing that we add symbol-annotation to plugin-pom with scope=provided and optional=true matching

Re: Annotation versions

On Fri, Dec 17, 2021 at 2:12 PM 'Jesse Glick' via Jenkins Developers wrote: > > It is just listed as a plain dependency of `jenkins-core`. So it should be in > the plugin classpath already, just like any other library. Good point. I suppose by the same logic we should remove

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

I did some experiments with integrating Eclipse Transformer into Jenkins core and the Maven HPI plugin. It seems to work pretty well: I have not seen any false positives yet, and almost all plugins converted by it seem to work OK in a Jakarta EE 9 environment. I am starting to think that any

Jakarta Mail and Jakarta Activation

Core currently ships JavaMail and JavaBeans Activation Framework (JAF), a dependency of JavaMail. Core only consumes this functionality in a tiny validation routine (JenkinsLocationConfiguration#doCheckAdminAddress), but many plugins consume this functionality via core. Both libraries are subject

Re: Jakarta Mail and Jakarta Activation

On Mon, Jan 3, 2022 at 12:57 PM Basil Crow wrote: > > Yeah, there are 41 such plugins, the most notable of which are Mailer, > Email Extension, and Pipeline: Basic Steps. I maintain Email Extension, so I looked into migrating it to Jakarta Mail. Unfortunately the test suite depend

Re: ASM in core

Once JNR is removed from core in jenkinsci/jenkins#5979 (which is blocked on the merge, release, and widespread adoption of jenkinsci/pam-auth-plugin#20), then the only remaining consumers of ASM in core will be Stapler [1] and access-modifier [2]. It would be nice to eliminate these dependencies

Re: ASM in core

On Tue, Jan 4, 2022 at 1:05 PM 'Jesse Glick' via Jenkins Developers wrote: > > `access-modifier` is not a big deal since it is used only at compile > time—need not be shipped in core. But as of jenkinsci/plugin-pom#480 plugins get their (compile time!) access-modifier-annotation dependency from

Re: ASM in core

On Tue, Jan 4, 2022 at 5:09 PM 'Jesse Glick' via Jenkins Developers wrote: > > That basically takes us back to the unfortunate state we were in with > Kohsuke’s series of shaded & repackaged ASM libraries, where we could not > give a clear answer as to what we were actually bundling, and

Re: Add timja to jep editors

+1 -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

On Tue, Dec 21, 2021 at 12:01 PM Tim Jacomb wrote: > > I think we should target the LTS after next for dropping Java 8 support. +1 > That would be: > > Weekly - 2nd February (week after baseline selection for next LTS) > LTS - approx 7th June (roughly when ths LTS after next will be released)

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

On Tue, Dec 28, 2021 at 11:20 PM Baptiste Mathus wrote: > > I think updating the minimum in Feb 2021 for weeklies and hence June for LTS > is a bit too aggressive. I think we should at least target the LTS _after_ > June. I fail to see any reason why a June target for LTS is too aggressive.

Re: Jakarta Mail and Jakarta Activation

On Mon, Jan 3, 2022 at 12:41 PM 'Jesse Glick' via Jenkins Developers wrote: > > Are there enough plugins actually using one of these javax.* packages that it > would be impractical to just switch them all to Jakarta now? Yeah, there are 41 such plugins, the most notable of which are Mailer,

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

On Tue, Nov 16, 2021 at 2:30 AM Olivier Lamy wrote: > But as it turns EOL, we will have to upgrade to Jetty 10 (or 11 but not > sure at this stage Jenkins will have been migrated to use > jakarta.servlet/jakarta.* namespaces). > I put together a prototype

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

On Mon, Dec 20, 2021 at 1:53 PM 'Jesse Glick' via Jenkins Developers wrote: > > Is this mostly about Servlet API types, or other EE packages? Servlet types and JavaMail were the most common cases I saw in the prototype, along with a new package namespace for FileUpload to go along with the new

Re: Feedback on some analysis I'm doing

Might be interesting to look into adding something like OWASP Dependency-Check to the parent POM and plugin parent POM , with suppressions for existing false positives

Re: Feedback on some analysis I'm doing

On Mon, Dec 13, 2021 at 11:22 AM 'rsomas...@netflix.com' via Jenkins Developers wrote: > > While sometimes […] it is about security […] > Other times, it's mostly about reducing redundant libraries […] Indeed. > Other common libraries are > com.google.code.gson gson

Annotation versions

The Jenkins core BOM currently defines versions for spotbugs-annotations, jcip-annotations, and access-modifier-annotation, and core ships JARs for spotbugs-annotations and access-modifier-annotation (but not jcip-annotations, which is inconsistent). plugin-pom depends on spotbugs-annotations at

Re: Release lead for the next LTS version

I can volunteer for this one. On Tue, Jul 20, 2021 at 12:01 AM Tim Jacomb wrote: > > Hello > > I'm looking for a release lead for the next LTS version (most likely 2.302). > > The release candidate is due on 11th August > The release day is 25th August. > > It doesn't require any specific

Re: Release lead for the next LTS version

On Tue, Jul 20, 2021 at 7:58 AM Tim Jacomb wrote: > > Would you create a new issue for it using the new LTS release option Done: https://github.com/jenkins-infra/release/issues/173 -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To

Re: Java 11 as minimum? (Jetty 9.4.x EOL)

On Mon, Jan 3, 2022 at 12:48 PM Mark Waite wrote: > > I think there are changes that are as yet undiscovered on the removal of Java > 8 support. I believe that finding and fixing those surprises will need more > time. We are already aware of issues with WebSockets (fixed), JAXB (fixed in all

Java 17 / Jakarta Servlet migration

Starting a new thread for Java 17 and the Jakarta Servlet API migration. On Sun, Dec 19, 2021 at 6:12 PM Basil Crow wrote: > > When loading plugins […] in a Jakarta EE 9 > environment, we will probably need to apply some special compatibility > transformations, exempli gratia,

Re: New Year blogpost for Jenkins

Between 2.274 (2021-01-05) and 2.328 (2022-01-03), we removed 9 outdated dependencies, unforked and upgraded 2 outdated dependencies, and upgraded 20 other dependencies: - Removed Akuma - Removed ASM 5 - Removed ASM 6 - Removed Bytecode Compatibility Transformer - Removed Commons Digester -

Sunsetting Georgia bold

Since at least August 10, 2011 , the Jenkins logo has been set in Georgia bold. To me, this is a throwback to a much earlier era in Internet history, when web typography was essentially

Re: Sunsetting Georgia bold

When choosing typefaces, there are two key considerations: How does the type make us *feel* and how does the type *work*? Type can often evoke a feeling from a certain era. For example, Georgia Bold takes me back to the late 2000s, when Jenkins (then Hudson) was first conceived. Now consider a

Re: Sunsetting Georgia bold

On Mon, Mar 7, 2022 at 12:14 PM 'Gavin Mogan' via Jenkins Developers < jenkinsci-dev@googlegroups.com> wrote: > The only condition for me would that they have to be distributable, I don't want Jenkins to reach out to typekit or Google every page hit, it should work the same airgapped. I concur.

Re: [Proposal] Transfer of CloudBees-community/syslog-java-client to jenkinsci Github org

+1 from me as well. Once transferred, we will need to add a new YAML file to repository-permissions-updater (RPU) to grant someone GitHub and Artifactory permissions. I am CC'ing Cyrille Le Clerc as the original author and last

Re: [Proposal] Transfer of CloudBees-community/syslog-java-client to jenkinsci Github org

On Tue, Mar 15, 2022 at 11:00 AM 'Cyrille Le Clerc' via Jenkins Developers wrote: > Did you consider publishing exclusively to Jenkins' own maven repository? I have configured the repositories we have transferred already, like Mock JavaMail and File Leak Detector, to publish exclusively to the

Re: [Proposal] Transfer of CloudBees-community/syslog-java-client to jenkinsci Github org

Cyrille and I both now have access to this repository as members of the syslog-java-client-developers group. I have updated the build to remove any CloudBees-specific parent POMs, run CI builds on Jenkins project

Re: [Proposal] Transfer of CloudBees-community/syslog-java-client to jenkinsci Github org

On Mon, Mar 14, 2022 at 3:08 PM 'Cyrille Le Clerc' via Jenkins Developers < jenkinsci-dev@googlegroups.com> wrote: > It's a great idea to allow the syslog-java-client to progress migrating it to the Jenkins Community. I'm fully supportive. > The MIT License should make it easy. Thank you for the

Re: [Proposal] Transfer of CloudBees-community/syslog-java-client to jenkinsci Github org

On Tue, Mar 15, 2022 at 1:30 AM 'Gavin Mogan' via Jenkins Developers < jenkinsci-dev@googlegroups.com> wrote: > Why do you need to change the group of? I concur with Gavin. I see no reason to change the Maven group ID or artifact ID, and we have historically not changed these when transferring

Re: Linux installers for Jenkins 2.332.1 LTS

While the System V init code from 2.333 and earlier is the least likely to surprise us, it remains full of long-standing bugs (including JENKINS-65809) and depends on third-party daemonization packages, one of which is not available at all in Fedora EPEL 9. This code has caused and continues to

Re: Jenkins Security Scan now generally available

After upgrading a dozen or so plugins to Security Scan v2, the Jenkins Security Scan workflow on the main branch failed with: Called workflows cannot be queued onto self-hosted runners across organisations/enterprises. Failed to queue this job. Labels: 'ubuntu-latest'. List of example plugins

  1   2   3   4   >