Re: Proposal: "Friend Of Jenkins" Revamp

Honestly I'm not even sure it's worth spending the time to upgrade the plugin. It just adds a low res icon and a link. I vote for discontinuing the non distributed plugin. On Mon., May 10, 2021, 11:34 a.m. Mark Waite, wrote: > +1 from me on the proposal as well > > On Monday, May 10, 2021 at

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

Here's the PR submitting JEP for Digester Removal: https://github.com/jenkinsci/jep/pull/361 On Wed, May 5, 2021 at 10:37 AM Oleg Nenashev wrote: > Hi all. Please do not consider JEP as a huge overhead. As discussed in > another thread, we will be working on simplifying the process for >

Re: Jenkins SDLC Security: LFX Security/Snyk adoption status updates

FTR we created the new *#lfx-security-2-pilot-with-snyk* channel in the CDF Slack workspace so that all sides can sync-up in a chat if needed. You can join the workspace by following the guidelines in https://www.jenkins.io/chat/#continuous-delivery-foundation All interested contributors and

Re: Proposal: Adopting Stapler as official Jenkins project

On Mon, May 10, 2021 at 2:04 PM Oleg Nenashev wrote: > Other Stapler related personal repositories can be also moved to the > jenkinsci org > Sure; do you know of any? https://javadoc.jenkins.io/component/stapler/ includes Javadoc only for > https://github.com/stapler/stapler >

Re: Proposal: "Friend Of Jenkins" Revamp

+1 from me on the proposal as well On Monday, May 10, 2021 at 5:20:02 AM UTC-6 timja...@gmail.com wrote: > +1 to proposal > > On Mon, 10 May 2021 at 11:08, Oleg Nenashev wrote: > >> Would appreciate any feedback in this thread from the community >> >> On Wednesday, May 5, 2021 at 9:58:50 AM

Re: Proposal: Adopting Stapler as official Jenkins project

+1 On Mon, 10 May 2021 at 19:10, Basil Crow wrote: > +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

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: Proposal: "Friend Of Jenkins" Revamp

I have submitted https://github.com/jenkins-infra/jenkins.io/pull/4343 with text updates On Monday, May 10, 2021 at 1:20:02 PM UTC+2 timja...@gmail.com wrote: > +1 to proposal > > On Mon, 10 May 2021 at 11:08, Oleg Nenashev wrote: > >> Would appreciate any feedback in this thread from the

Re: Proposal: Evaluating Twitter as code with @memkins

I will go ahead and setup a PoC tomorrow if no negative feedback On Monday, May 10, 2021 at 2:37:27 PM UTC+2 Mark Waite wrote: > +1 from me as well. Thanks for doing it > > On Mon, May 10, 2021 at 5:20 AM Tim Jacomb wrote: > >> +1 >> >> On Mon, 10 May 2021 at 11:57, Oleg Nenashev wrote: >>

Re: Proposal: Adopting Stapler as official Jenkins project

Thanks Jesse! Would also appreciate feedback w.r.t "TBD: We move Stapler repositories to jenkinsci . If there are other related personal repositories, we move them as well". Responded to the rest below > other related personal repositories >> What does this mean? Did not finish the bullet,

Re: External logs storage for Pipeline/FreeStyle jobs

Yes, JEP-207 was abandoned after, ehm some reorg at my company. Great to see my former teammates commenting in this thread :D JEP-207 was indeed abandoned, but there were pull requests submitted to the Jenkins core and reference implementations (see the JEP for links). We had some

Re: HTMLUnit DefaultCssErrorHandler

I vaguely remember when I did the upgrade to htmlunit for crawler that there was a flag to say what version of the browser to act as. I think the default is like Firefox 4 or something. (

Re: Proposal: Adopting Stapler as official Jenkins project

On Mon, May 10, 2021 at 12:06 PM Oleg Nenashev wrote: > >- Stapler is adopted as a Jenkins sub-project, with explicit >expectation that we do not encourage external use > > +1 > >- maybe even target replacing it by another active OSS project later >if not mission impossible > >

Re: Stapler IntelliJ Plugin JetBrains Marketplace listing

FTR I started https://groups.google.com/g/jenkinsci-dev/c/1T3yDHl1nEQ . I have a partially-completed proposal for Stapler in my drafts, so I went ahead and started the discussion On Monday, May 10, 2021 at 2:16:38 PM UTC+2 Jesse Glick wrote: > On Fri, May 7, 2021 at 7:13 PM Oleg Nenashev

Proposal: Adopting Stapler as official Jenkins project

Hi all, I would like to follow-up on the previous discussions about the future of Stapler. De-facto Stapler is a legacy project widely used only in Jenkins (Jenkins core and plugins, and the old account app). I'd guess there are little to no external usages left. Stapler currently resides in a

Re: External logs storage for Pipeline/FreeStyle jobs

On Mon, May 10, 2021 at 11:11 AM kuisathaverat wrote: > it [is] only for pipelines so I have taken a look at JEP-207: External > Build Logging support in the Jenkins Core > > but it seems abandoned > Yes. Something like that

Re: HTMLUnit DefaultCssErrorHandler

On Mon, May 10, 2021 at 10:31 AM Michael Tughan wrote: > I'm betting that it hasn't been updated for new CSS3 syntax > If so, it is worth checking if there is an HtmlUnit update which would correct the problem; and if not,

External logs storage for Pipeline/FreeStyle jobs

Hi, I've started a plugin to send pipeline logs to an Elasticsearch instance using the described API in JEP-210: External log storage for Pipeline It is based on the example implementation pipeline-cloudwatch-logs-plugin

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

Then let's postpone it until .2 at least On Mon, May 10, 2021 at 4:44 PM Basil Crow wrote: > 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:

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

No, because they're not actually errors. It's complaining about the property definitions like "--font-family-sans". I'm betting that it hasn't been updated for new CSS3 syntax, especially around properties. Michael On Monday, May 10, 2021 at 8:15:01 a.m. UTC-4 Jesse Glick wrote: > Rather than

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

What metric would people consider? 0? Few new issues? From personal experience on Java 11 I have never hit the above issues (apart from illegal reflective access log messages) Query I used to look:

Re: Proposal: Evaluating Twitter as code with @memkins

+1 from me as well. Thanks for doing it On Mon, May 10, 2021 at 5:20 AM Tim Jacomb wrote: > +1 > > On Mon, 10 May 2021 at 11:57, Oleg Nenashev > wrote: > >> Dear all, >> >> Last week I created the new Jenkins-related Twitter account: >> https://twitter.com/memkins. The goal of this channel is

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

On Sun, May 9, 2021 at 4:10 AM Tim Jacomb wrote: > encourage existing users to migrate > Feels a bit premature when the list of `java11-compatibility` issues still includes bugs in core and widely used plugins. (The only ones I have personal experience with are JENKINS-61212

Re: Stapler IntelliJ Plugin JetBrains Marketplace listing

On Fri, May 7, 2021 at 7:13 PM Oleg Nenashev wrote: > should we go ahead and move the repository to the jenkinsci org? > Fine with me. We should probably move `stapler/stapler` itself (INFRA-2908); we have already started publishing to the Jenkins Artifactory rather than OSSRH. -- You

Re: HTMLUnit DefaultCssErrorHandler

Rather than silencing the warnings, can the alleged errors be fixed in core? -- 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: Plugins using removed Guava APIs

Hello, I couldn't find the source code of the cloudfoundry-bosh-cli . This plugin can be ignored as it it completely outdated, the BOSH CLI it integrates with has been replaced a long time ago by a BOSH CLI v2. Cyrille On Sunday, May 9, 2021 at 9:40:34 PM UTC+2 m...@basilcrow.com wrote: > I

Re: HTMLUnit DefaultCssErrorHandler

My PR specifically adapted the tests to a reorg of the core CSS. Note the messages I ended up suppressing in my example were different ones. These messages are new and look like they're from the color definitions. I don't know this area well enough to confidently dismiss all warnings as

Re: Proposal: Evaluating Twitter as code with @memkins

+1 On Mon, 10 May 2021 at 11:57, Oleg Nenashev wrote: > Dear all, > > Last week I created the new Jenkins-related Twitter account: > https://twitter.com/memkins. The goal of this channel is to repost funny > memes and comics about Jenkins, while delivering best practices to end > users.

Re: Proposal: "Friend Of Jenkins" Revamp

+1 to proposal On Mon, 10 May 2021 at 11:08, Oleg Nenashev wrote: > Would appreciate any feedback in this thread from the community > > On Wednesday, May 5, 2021 at 9:58:50 AM UTC+2 Oleg Nenashev wrote: > >> Dear all, >> >> We’ve recently had a few discussions with the board and Daniel Beck

Re: HTMLUnit DefaultCssErrorHandler

I thought Daniel already did a PR to the test harness for this? He might have selectively turned things off rather than a full silence though https://github.com/jenkinsci/jenkins-test-harness/pull/275 On Mon, 10 May 2021 at 10:47, Angélique Jard wrote: > spam for me, but it could be silenced

Proposal: Evaluating Twitter as code with @memkins

Dear all, Last week I created the new Jenkins-related Twitter account: https://twitter.com/memkins. The goal of this channel is to repost funny memes and comics about Jenkins, while delivering best practices to end users. Although this channel will include more sarcasm and self-criticism than

Re: Proposal: "Friend Of Jenkins" Revamp

Would appreciate any feedback in this thread from the community On Wednesday, May 5, 2021 at 9:58:50 AM UTC+2 Oleg Nenashev wrote: > Dear all, > > We’ve recently had a few discussions with the board and Daniel Beck about > the “Friend of Jenkins” plugin. This is a plugin referenced from >

Re: HTMLUnit DefaultCssErrorHandler

spam for me, but it could be silenced by default and enabled in specific use case maybe ? On Monday, May 10, 2021 at 11:44:19 AM UTC+2 jn...@cloudbees.com wrote: > Hi all, > > The jenkins-test-harness uses the default HTMLUnit CSS Error handle which > logs two warning for every CSS error it

Re: HTMLUnit DefaultCssErrorHandler

+1 for silencing them by default. Would be nice to have a method in WebClient for those methods which really check the web layouts and hence care bout CSS On Monday, May 10, 2021 at 11:44:19 AM UTC+2 jn...@cloudbees.com wrote: > Hi all, > > The jenkins-test-harness uses the default HTMLUnit

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

On Mon, May 10, 2021 at 11:35 AM Oleg Nenashev wrote: > Thanks to Raihaan for stepping up as the release lead for 2.289.1! > So far the changes look good. We might have a few extra backports to do > before the deadline, and everyone is welcome to expedite potential > backports into the

Applying JavaScript and CSS on f:select

Hi all, In my plugin I have a element with the multiple attribute (multi-select) that is changing according to another field. My problem is that I want to apply JavaScript and CSS to it to make it look better than the standard multi-select element. it currently looks like this: [image:

HTMLUnit DefaultCssErrorHandler

Hi all, The jenkins-test-harness uses the default HTMLUnit CSS Error handle which logs two warning for every CSS error it encounters. Does anyone actually care about these errors? I am about to file a PR to silence them, but thought someone may care and may have a use for them? For example

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

Thanks to Raihaan for stepping up as the release lead for 2.289.1! So far the changes look good. We might have a few extra backports to do before the deadline, and everyone is welcome to expedite potential backports into the tomorrow's weekly. I wonder whether we should also create a Remoting