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 <

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: 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 uses

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 1.3

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: 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 two

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. > For

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 a

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. But

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. T

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 an

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 Jen

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 easi

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 these

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 do

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: 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: 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

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 Grou

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 line

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 t

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 Group

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 https://gr

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 Emma,

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 de

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 W

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 i

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 those

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 > c

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

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 plugin

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: 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 Big

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 J

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 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 s

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: > https://github.com/jenkinsci/configuration-as-code-plugin/blob/a6983ff60e0cf198ce02d7992bcba927197174db/test-harness/src/test/resources/io/jenkins/plugins/casc/validSelfConfig.yml#L1-L5

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

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 permiss

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 unsub

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: Supp

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

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 in

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 hadn

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: https://repo.jenkins-ci.org/incrementals/org/jenkins-ci/main/jenkins-war/2.30

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

[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

[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 r

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] +- org.junit.jupiter:junit-jupiter-engine:jar:5.7.2

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 jnr/jn

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: 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 suffici

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. ht

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 it.

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 sto

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 ran

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 https://groups.goo

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 t

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 2.8

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 ve

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: +-org.jenkins-ci.plugins:nodela

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 spotbugs-a

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 access-modifier-anno

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)

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 Jakart

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 se

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 https://groups.goo

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) F

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 t

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. The

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, Emai

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 b

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 f

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 securit

Re: Migrating username & secret password to credentials plugin

Email Extension did this recently in jenkinsci/email-ext-plugin#325 and the follow-up bug fix jenkinsci/email-ext-plugin#332. -- 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,

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, tran

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 - Remove

Re: Jenkins Security Scan now generally available

I added this to all the plugins I maintain. Very nice! After adding this, new unrelated pull requests (see, for example, jenkinsci/email-ext-plugin#346, which just adds a line to the readme) all seem to fail in the "Run Scan" step with: Interpreting results. […] curl: (22) The requested URL ret

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 cau

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 bel

File Leak Detector

kohsuke/file-leak-detector has not seen commits since 2018. There are a number of open PRs that need to be processed and released, including important PRs to add Java 11 support (see JENKINS-52308). We recently moved mock-javamail from Kohsuke's GitHub organization to the Jenkins GitHub organizati

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 limite

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. Fo

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 typ

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 maint

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 q

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 rep

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 Je

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 infrastructure

Reverting JENKINS-20679

Hi all, As part of my work on Java platform support in Jenkins, I have encountered the subsystem introduced in JENKINS-20679, which allows plugins to request a newer version of Java than the corresponding core. Based on a preliminary search of sources across the ecosystem, this functionality appea

Re: Reverting JENKINS-20679

On Tue, Mar 29, 2022 at 10:25 PM 'Daniel Beck' via Jenkins Developers wrote: > > Seems reasonable if really unused. Thanks. Of course I will verify this systematically before proposing the PRs. > 1. IIRC I've seen plugins requiring Java 11 that just don't declare it. So > it's not unused becaus

Re: Intellij Stapler Framework Support compatibility

On Tue, Mar 29, 2022 at 9:41 PM Denys Digtiar wrote: > > Would anybody be opposed if I bump compatibility to some newer version? Maybe > 2020.x or something like that? +1 -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe fr

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

Hi Cyrille, On Wed, Mar 23, 2022 at 3:39 AM 'Cyrille Le Clerc' via Jenkins Developers wrote: > I would definitely be interested in publishing the syslog-java-client library > to Maven Central from non Jenkins project to easily consume the library. Great! > My understanding of the Sonatype OSS

Jenkins on SQLite

In the past we have talked about our vision and goals for Jenkins 3.0 on this list. Here is one of mine. Has anyone besides me been highly dissatisfied with the way Jenkins does object persistence? I think we are leaving a lot of functionality and performance on the table by using flat files rathe

Re: Jenkins on SQLite

I have never used H2, but I have a strong preference for SQLite. It has been deployed more widely than all other database engines combined and is probably one of the top five most deployed software programs of all time, competing only with zlib, libpng, and libjpeg. It is very high quality code and

Re: Automated plugin release

As Mark wrote in his previous message, it is because https://ci.jenkins.io/job/Plugins/job/bmc-cfa-plugin/job/main/ is failing. -- 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 i

  1   2   3   4   >