Re: License for library plugins

This is a subjective question, but I feel that when the only thing in src/main is src/main/resources/index.jelly the wrapper should be licensed the same way as the library being wrapped, because our own contribution to production code is de minimis. It seems strange to use a different license when

Re: CVE-2023-50164 Struts question

My unofficial answer: Jenkins uses Stapler as its web framework (not Struts), so I strongly suspect there are zero Jenkins plugins distributed on our Update Center that bundle Struts 2 or 3. For an official answer, contact the Security Team at: https://www.jenkins.io/security/team/ -- You

Re: Artifactory brownout Wed 6 Dec 2023 1:00 PM UTC - 3:00 PM UTC

+1, I think we have done all the preparation we can for this change. -- 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

License for library plugins

Library plugins are inconsistently licensed: sometimes, they adopt the license of the wrapped library, while in other cases, they follow the MIT license as normally used by Jenkins plugins. Does anybody have a preference as to what we should recommend? -- You received this message because you

Re: ASM in core

dozen or so PRs to cover plugins with over 1,000 installations, if anyone is interested. On Mon, Aug 22, 2022 at 7:22 PM Basil Crow wrote: > > I think detaching is riskier than I expected: a lot of plugins bundle > old copies of ASM (or depend on other plugins that do). With core's > co

Re: January 8, 2024 Governance Board Agenda

On Mon, Jan 8, 2024 at 11:48 AM 'Gavin Mogan' via Jenkins Developers wrote: > > is that alternatives to locking it down? Alternatives to restoring from backup. We ended up restoring from backup. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers"

Re: 2.440 as Feb 21, 2024 LTS baseline?

+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: How to implement writing to console log in pipeline?

On Sun, Nov 19, 2023 at 2:50 AM tzach@gmail.com wrote: > I'm developing a new plugin and I was able to write to log in FreeStyleJob > but it does not work in pipeline. See https://www.jenkins.io/doc/developer/plugin-development/pipeline-integration/ for more information: Pipeline builds

Re: Error: Could not find or load main class com.mathworks.polyspace.jenkins.PolyspaceHelpers

This seems to assume the build is running on the built-in node, something we no longer recommend: https://www.jenkins.io/doc/book/security/controller-isolation/#not-building-on-the-built-in-node -- You received this message because you are subscribed to the Google Groups "Jenkins Developers"

Re: Error in Javadoc when attempting to publish a new plugin version

You can reproduce locally by running mvn clean verify -Pjenkins-release and on CI by enabling incrementals . Be sure to use the same version of Java you intend to use when doing the release, as different Java versions produce

Jakarta Activation 2.1.3, Jakarta Mail 2.1.3, and Eclipse Angus

A year after I reported https://github.com/jakartaee/mail-api/issues/665 upstream, a fix has finally been released in Jakarta Mail 2.1.3, allowing me to finally migrate the Jenkins ecosystem to Jakarta Activation 2.1.3, Jakarta Mail 2.1.3, and Eclipse Angus. This in turn finally eliminates the

Re: Stop publishing fat plugin aws-java-sdk

The latest release of Pipeline: AWS Steps (which we use on ci.jenkins.io) still uses the fat JAR, although Zbynek updated it to use the new modules in a PR that has been merged but not yet released. -- You received this message because you are subscribed to the Google Groups "Jenkins

Re: Multiple questions on Jenkins plugin repo management

On Wed, Mar 20, 2024 at 9:05 AM Stéphane BOBIN wrote: > I am puzzled because the PR was done on jenkinsci repo for my plugin > (https://github.com/jenkinsci/mathworks-polyspace-plugin/actions), which is a > sync of the main repo, and all actions worked fine here. > While on the mathworks repo

Re: Remove Suggestimate from issues.jenkins.io?

+1 On Mon, Mar 11, 2024 at 6:48 AM Mark Waite wrote: > > The Jenkins Jira instance uses a Jira datacenter license that is donated to > the Jenkins project by Atlassian. > > The Suggestimate plugin is installed on the Jenkins Jira instance and is > reporting that its license has expired. The

Re: Aborting pipeline from a plugin

On Fri, Mar 22, 2024 at 2:11 PM zbyne...@gmail.com wrote: > What is the correct way to abort pipeline programmatically? See https://javadoc.jenkins.io/plugin/workflow-step-api/org/jenkinsci/plugins/workflow/steps/FlowInterruptedException.html. -- You received this message because you are

Re: Adoption request for scmskip plugin

+1 On Sun, Mar 24, 2024 at 11:34 AM Verachten Bruno wrote: > > +1 from me, of course. > Thanks, Zbynek. > > On Sun, Mar 24, 2024 at 4:10 PM zbyne...@gmail.com > wrote: > > > > Hi, > > > > the scmskip plugin is up for adoption. I'd like to adopt it in order to > > deliver some bugfixes. > > >

Re: Windows-arm64 native support

On Thu, Mar 28, 2024 at 11:16 PM Pierrick Bouvier wrote: > Thanks for your help, I'll take a look at this. And thanks for your interest! Unfortunately I think https://github.com/jenkinsci/winp/pull/112 is premature, as the repository is not currently in a state where _any_ outside contributions

Re: 2.452 as May 15, 2024 LTS baseline?

+1 for 2.452. Recent weeklies have been solid, and 2.452 is a particularly good choice because it contains the recent Mina SSHD updates. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving

Re: Windows-arm64 native support

I considered writing a similar post myself a few days ago, and I also think it is time for winp to be retired, but there are a lot of challenges associated with removing winp in favor of a simpler implementation using native Java process handling or simpler Windows primitives. The existing native

Re: ASM in core

On Sat, Jan 13, 2024 at 5:09 AM Valentin Delaye (jonesbusy) wrote: > > Jumping into this Are you still interested in removing ASM from core? I checked usage in plugins, and I believe all significant plugins are now linking against the ASM library plugin. The last major blocker was the JaCoCo

Updating detached plugins

Since before my involvement as a core maintainer, we have apparently had a policy to "only update detached plugins when we are forced to, for example because there was a security advisory," and to run LoadDetachedPluginsTest#noUpdateSiteWarnings when updating them. This policy predates my

Re: Updating detached plugins

On Tue, Apr 9, 2024 at 12:33 PM 'Daniel Beck' via Jenkins Developers wrote: > > Are you aware of examples of this problem other than the two Jira issues? Daniel, I am not aware of any such examples. -- You received this message because you are subscribed to the Google Groups "Jenkins

Re: Windows-arm64 native support

On Fri, Apr 5, 2024 at 12:44 AM Pierrick Bouvier wrote: > > If I follow the documentation you sent (container-agents), it seems that > Visual Studio is not available in those containers. > What should be the steps to add Visual Studio into this: > - Create a new container? > - Install it

Re: Windows-arm64 native support

On Fri, Apr 5, 2024 at 1:02 AM Pierrick Bouvier wrote: > > I reiterate politely my demand: Could we merge the changes required, let > someone trusted (you, or any Jenkins core dev, not me) build the binaries, > commit them, make a new release, and call it a day? Is "demand" a bit aggressive? I

Re: Windows-arm64 native support

On Fri, Apr 5, 2024 at 2:40 AM Tim Jacomb wrote: > > From my point of view GitHub actions is fine. > I don’t think we want to add something that takes so long to install to our > image builds. That could be a fair position, if it is the consensus of the Jenkins infrastructure team. But before

Re: Windows-arm64 native support

On Fri, Apr 5, 2024 at 12:53 AM Pierrick Bouvier wrote: > > > Even if there is not a simple solution using the Java Platform, I am > > guessing winp specifically could be removed in favor of executing `wmic` > > commands or something like that, or that could be a fallback in case of an > >

Re: Windows-arm64 native support

I am not aware of anyone who is actively maintaining the winp component. You could take ownership of the winp component, set up CI builds and tests, and then do a release with Windows ARM64 support. -- You received this message because you are subscribed to the Google Groups "Jenkins

Re: Windows-arm64 native support

On Thu, Apr 4, 2024 at 12:24 AM Pierrick Bouvier wrote: > > Thanks for taking the time to answer and give a direction Basil, it's > definitely more constructive than saying "do not ping me". "Do not ping me" definitely still stands from my side regarding questions about the current code, even

Re: Modernize core dependency json-lib library

On Wed, Apr 10, 2024 at 7:50 PM Bob Du wrote: > > Before that, I checked and compared the code and found that the fork > dependency version currently in use should have been built and released from > the rebase-2.4 branch, not master. I confirmed that by comparing the sources JAR on

Re: Updating detached plugins

Thanks, Daniel. I'll plan on proceeding with a lazy consensus decision that from now on, we'll accept the Dependabot PRs that update detached plugins, we'll keep the test ignored, and we won't run the ignored test manually for Dependabot PRs. If nobody objects to this lazy consensus decision by

Re: Modernize core dependency json-lib library

On Thu, Apr 11, 2024 at 6:31 AM 'Jesse Glick' via Jenkins Developers wrote: > > I think it is worse than that Note that I wrote "migrate core *and* plugins", which would mean creating a new method that returns a different type and adjusting consumers accordingly. If we were to upgrade to the

Re: Modernize core dependency json-lib library

Hey Bob, thank you for proposing this! Jenkins core delivers JSON-lib under the net.sf package namespace, consumes it itself, and provides it to many consuming plugins. It looks like Andres Almiray is still maintaining JSON-lib and EZMorph over at https://github.com/kordamp/json-lib and

Re: Plugin with Java 17 minimum dependencies

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

Re: ASM in core

On Thu, Jun 10, 2021 at 1:46 AM jn...@cloudbees.com wrote: > > I have just noticed a few PRs (some merged) to change ASM in core or > libraries that core depdns on (stapler). > I think we need to revert these […]. Thanks, James! Valentin Delaye has removed ASM from Jenkins core in

Re: Spring Security upgrade from 5.x to 6.x

Based on my prototyping in JENKINS-73120, there is quite a bit of work to support Jetty 12 (even just EE 8 with javax imports), blocked on the requirement of Java 17. From my perspective the sooner we require Java 17, the better. Perhaps we can require Java 17 in weeklies two weeks earlier than

Re: Spring Security upgrade from 5.x to 6.x

While still in milestone status, Commons FileUpload 2.x is being recommended on the project's home page and GitHub page , and hopefully it will reach

Re: Spring Security upgrade from 5.x to 6.x

Unlike snapshot releases, milestone releases are tagged and published in Maven Central, so I don't see any issues with upgrading to 2.0.0-M2 immediately. In practice, if a Commons FileUpload v2 API did change between now and GA, it wouldn't be too much work to adapt the few plugins that consume

Re: Plugin with Java 17 minimum dependencies

Yes, I think the default should be changed to Java 17 and a new version released for the reasons already given. Why wasn't the adoption of such a release (along with updating the Java version value in the Jenkins security scan workflow, pending

Re: Spring Security upgrade from 5.x to 6.x

On Sat, May 11, 2024 at 8:43 PM Bob Du wrote: > > I am willing to contribute code to achieve this long-term goal. Great! I have filed https://issues.jenkins.io/browse/JENKINS-73169 with more details about this long-term removal, explaining the reasoning behind the removal, the relevant portions

Re: 2.452.2 Release Lead

+1, thank you Kris! On Thu, May 16, 2024 at 9:31 AM Alyssa Tong wrote: > > +1 from me as well. Thank you, Kris for all you do 﫶 > > On Thu, May 16, 2024 at 9:26 AM 'Bruno Verachten' via Jenkins Developers > wrote: >> >> Thank you Kris for proposing to be the release lead. >> Of course +1 from

<    1   2   3   4