Re: Anything wrong with storing expanded plugin data in var cache?

I think it's a genuinely great proposal and it sounds like most of the things I'd be concerned about have already been thoroughly considered and addressed effectively. There are two remaining points to consider: I think it might be desirable to give plugins some mechanism to interact with the

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

r AtomicXX access) that's probably fine. On Monday, March 19, 2018 at 6:32:01 PM UTC-4, R Tyler Croy wrote: > > (replies inline) > > On Mon, 19 Mar 2018, Samuel Van Oort wrote: > > > Late to the party because I was heads-down on Pipeline bugs a lot of > > Friday

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

I think Google Groups somehow managed to eat a *very* long and detailed reply here, possibly as a result of a message deletion somewhere (or it somehow got kicked into the spam filter) *sigh* so I'm going to give just the TLDR of it. Something on this has been on my want-to-have list for a

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

Late to the party because I was heads-down on Pipeline bugs a lot of Friday, but this is a subject near-and-dear to my heart and in the past I've discussed what metrics might be interesting since this was an explicit intent to surface from my Bismuth (Pipeline Graph Analysis APIs). Some of

Re: Subject: Pipeline Storage Performance Work Available For Beta - Want to kick the tires?

flow-api@2.25-durability-beta"> > PERFORMANCE_OPTIMIZED > DescriptorImpl> > > > > > On Friday, December 22, 2017 at 9:51:14 AM UTC+8, Samuel Van Oort wrote: >> >> Subject: Pipeline Storage Performance Work Available For Beta - Want to >> kick the tires? >> >&

Subject: Pipeline Storage Performance Work Available For Beta - Want to kick the tires?

Subject: Pipeline Storage Performance Work Available For Beta - Want to kick the tires? Hey all, I've just released a set of plugin betas to the Experimental Update Center. They have enhancements to Pipeline which CAN dramatically reduce I/O use and improve performance. Please given them a

Re: [PROPOSAL] Change core logging from Java Utils Logging

> Am I the only one to think it strange that we are discussing using very limited core developer resources to replace a library used pervasively throughout the Jenkins code base with a functionally identical library with no demonstrable benefit to users and rather marginal impact on developers

Re: Altering a plugin - Jenkins Stage view - where to look for in the code

Dear Martin, I am the Stage View maintainer -- there's not an extension point for this, but if you want to add one, you'd have to make a new API like this one:

Re: Does someone maintain parameterized trigger plugin?

Yes, I've been spread too thin to do a proper job of maintaining along with other commitments, unfortunately -- would be happy for someone else to take it up if they've got the time to focus on it more. On Monday, January 30, 2017 at 2:49:59 PM UTC-5, Oleg Nenashev wrote: > > IIRC Sam Van Oort

Re: Proposal: Out-of-order weekly release? Just another attempt

+1 - needs an out of order release. This causes 2 major breakages. A small aspect of JENKINS-39404 is responsible for JENKINS-39555, which badly breaks the whole pipeline plugin suite (and goodness knows what else). I have a fix for that which works, but am ensuring it doesn't have side

Re: Proposal: Out-of-order weekly release? Just another attempt

I'm looking into JENKINS-39555 now -- for some reason the usual JIRA notification wasn't delivered. On Monday, November 7, 2016 at 1:11:19 PM UTC-5, Oleg Nenashev wrote: > > Hi, > > According to my previous experience > , I >

Re: Setting CMS or G1 as the default GC algorithm for Jenkins?

For interested parties, this is tracked in https://issues.jenkins-ci.org/browse/JENKINS-38802 On Tuesday, October 11, 2016 at 12:57:49 PM UTC-4, Samuel Van Oort wrote: > > Baptiste, I completely agree -- GC logs are a gimme for any production > setting IMO (and since it's in the JIRA,

Re: [DISCUSS] Time for Jenkins to require Java 8 to run

I will jump for joy when everything is on Java 8. Functional features or death! Being able to consume the powerful libraries that are now Java 8-only (replacing Guava caches with Caffeine, for example, for a ~3x speed boost on all caching). Also @daniel-beck, this is another argument behind

Re: Setting CMS or G1 as the default GC algorithm for Jenkins?

ct on perf even under high load, and this is invaluable > information when things go wrong.) > > Le 7 oct. 2016 9:45 PM, "Samuel Van Oort" <svan...@cloudbees.com > > a écrit : > >> Kanstanstin, >> >> > suggest collect GC monitoring &

Re: Can I get on the cert team?

Adding to the train, if I would be able to contribute. Github, IRC, and jenkins.io username: svanoort Email: samvanoort at gmail And yes, of course I have an ICLA and 2FA on for Github. On Tuesday, October 11, 2016 at 11:15:11 AM UTC-4, Baptiste Mathus wrote: > > > 2016-10-10 15:17 GMT+02:00

Re: Setting CMS or G1 as the default GC algorithm for Jenkins?

enkins on jenkins (or whatever it > called now) and compare. Then it will be absolutely clear what is better. > > G1 as default for java9... depends on how much patches and differences are > between java8 and java9 and especially oracle vs openjdk. > > On Friday, October 7, 2016 at 12:29:5

Setting CMS or G1 as the default GC algorithm for Jenkins?

Hi guys, I'd like to propose that we explicitly set the Java args for the Jenkins packages to use either Concurrent Mark Sweep or G1 as the default GC algorithm. The reason for this is that Jenkins is generally used as a long-running server process, and large stop-the-world GC pauses can

Re: Docker workflow runs with user not fully configured

> It is not “known” to me, the plugin maintainer, so as I wrote in PR > 57: if there is a concrete, small, easily reproducible test case that > demonstrates something that does not work which you feel should, > please file it. > To clarify: I'm not saying that this is a result of a

Re: Docker workflow runs with user not fully configured

Oliver, Apologies for the delayed response, but this is a known issue around how docker.inside is implemented. It was very painful when setting up the docker image. This is why the docs and workflow script for the docker image don't use docker.inside --

Re: Easy path for the latest Jenkins in Ubuntu

I took an initial look at this as a maintainer for Jenkins Linux packaging -- I find the snap format itself rather interesting. I am curious to see where it goes now that there's support for non-Ubuntu distros released from Canonical. I like that it makes Jenkins more visible and discoverable

Re: Pipeline View Plugin

Sergei, I love the visualization this provides of the pipeline DAG! One thing worth mentioning: I have been working on a scalable/high-performance & parallel-aware FlowAnalyzer for pipeline stage view that is generalized enough to assist with the data you are visualizing. Since the rest-api

Re: Jenkins 2.0 initial setup plugin selection

On Thursday, March 10, 2016 at 10:58:38 AM UTC-5, Daniel Beck wrote: > > > On 10.03.2016, at 16:17, Samuel Van Oort <svan...@cloudbees.com > > wrote: > > > > Embeddable build status plugin would be a strong candidate for > inclusion. I'm not

Re: Jenkins 2.0 initial setup plugin selection

The list looks generally really solid (as do the recommendations). Looking at it, a couple comments: - Would it make sense to put parameterized trigger in the initial recommended plugins? - Is gradle plugin use strong enough to make it part of the core recommended plugins? - Junit &

Re: Jenkins 2.0 initial setup plugin selection

Would it make sense to add pipeline-stage-view plugin as a candidate for inclusion alongside the pipeline DSL? It provides greatly improved out-of-box experience for new users of pipeline. https://wiki.jenkins-ci.org/display/JENKINS/Pipeline+Stage+View+Plugin As far as the wiki criteria go:

Re: Automatic build and deploy of plugin (CI style)

Hi, As a side note, if you're building out demo machines with a precanned config, there are some really helpful scripts in the Jenkins docker image repo. Even if you're not running docker, the scripts and techniques should work well on demo VMs. To preinstall a list of plugins from the update

Re: Automatic build and deploy of plugin (CI style)

Hi, As a side note, if you're building out demo machines with a precanned config, there are some really helpful scripts in the Jenkins docker image repo. Even if you're not running docker, the scripts and techniques should work well on demo VMs. To preinstall a list of plugins from the update

Re: Request for merge/release of fix for JENKINS-26050 (workflow compatibility for parameterized trigger)

? пятница, 7 августа 2015 г., 4:23:53 UTC+2 пользователь Samuel Van Oort написал: Hi, We have a PR to fix JENKINS-26050, adding support for firing downstream workflow projects to the parameterized trigger plugin. We know that at least some users are specifically waiting

Request for merge/release of fix for JENKINS-26050 (workflow compatibility for parameterized trigger)

Hi, We have a PR to fix JENKINS-26050, adding support for firing downstream workflow projects to the parameterized trigger plugin. We know that at least some users are specifically waiting for this to be available. The PR is https://github.com/jenkinsci/parameterized-trigger-plugin/pull/87