Re: Declarative Pipeline v1.4.0-beta-1 - Matrix stages

This is fantastic to see land - I've been dreaming of matrix in Declarative for years, so thank you, Liam, for making it happen! A. On Tue, Aug 6, 2019 at 4:12 PM Liam Newman wrote: > Hello all! > > I'm pleased to announce the release of Declarative Pipeline 1.4.0-beta-1 > with Matrix Stages.

Pipeline Authoring SIG is now live!

https://jenkins.io/sigs/pipeline-authoring/ - tada! If you'd like to participate, you can join the mailing list ( jenkins-pipeline-authoring-...@googlegroups.com) and/or the Gitter chat ( https://gitter.im/jenkinsci/pipeline-authoring-sig). A. -- You received this message because you are

Announcing the Pipeline Authoring SIG

Hey all! Now that DevOps World/Jenkins World season has wrapped up, I'm officially kicking off the Pipeline Authoring SIG. I proposed it in https://groups.google.com/forum/#!topic/jenkinsci-dev/nJ1XWyzBMSw, but now I've started creating the infrastructure for the SIG, including the

Re: Proposal: Pipeline Authoring SIG

Oh, and here's the registration link for the Contributor Summit - https://www.eventbrite.com/e/jenkins-contributor-summit-nice-tickets-48353733318 A. On Tue, Oct 16, 2018 at 5:00 PM Christian C. wrote: > I'm interested =) > > On Tuesday, October 16, 2018 at 4:20:21 PM UTC+2, Andrew Ba

Re: Proposal: Pipeline Authoring SIG

. wrote: > Hi all! > > On Monday, October 15, 2018 at 11:12:13 AM UTC+2, Andrew Bayer wrote: >> >> If you’d like to be part of the initial group of participants, please >> respond on this thread. >> > > I'd be happy to join up in Nice next week @ Jenkins World! =)

Re: Proposal: Pipeline Authoring SIG

Definitely! Both Liam and myself will be at Nice. A. On Mon, Oct 15, 2018 at 9:03 PM Jon Brohauge wrote: > Andrew, > > Very interesting idea. Been desperately trying to test my vars/ groovy > scripts with varying degrees of success. I'd love to contribute where I > can. Maybe we can meet up at

Proposal: Pipeline Authoring SIG

I’d like to propose the creation of a “Pipeline Authoring” SIG, with myself as the lead. The focus of this SIG would be on improving all aspects of the user experience around authoring Jenkins Pipeline. This includes: * Syntax and structure * Extensibility, code reuse, and code sharing *

Re: Jenkins participation in Outreachy

Strong +1. If we have the cash available to approve the budget now, we should definitely move forward. And if we don't, well, we should fundraise specifically for that anyway. A. On Thu, Sep 27, 2018 at 5:57 AM Oleg Nenashev wrote: > The main problem is here: "Oct. 2, 2018 Last date for FOSS

Re: Using JEP process for future design changes to Declarative Pipeline?

fwiw, I am 100% behind the idea of JEP for non-trivial changes to Declarative. A. On Tue, May 1, 2018 at 8:30 PM Liam Newman <bitwise...@gmail.com> wrote: > Andrew Bayer has been doing great work on Declarative pipeline. He's done > excellent work creating clear and understan

Re: Adopting xUnit plugin

That'd be fine by me. A. On Mon, Apr 9, 2018 at 6:35 AM, 'Nikolas Falco' via Jenkins Developers < jenkinsci-dev@googlegroups.com> wrote: > I know that the xUnit plugin was already adopted on 15/11/2017 ( > https://groups.google.com/forum/#!searchin/jenkinsci- >

Re: Nullable single constructor parameter with declarative pipeline

So, there is a ticket for this in Declarative - https://issues.jenkins-ci.org/browse/JENKINS-42772 - but I have yet to be happy with a solution. I can’t, so far as I’m aware, check the DescribableModel for the class in question, and see it’s got a sole required argument *and* see that it could be

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

at 5:32 PM R. Tyler Croy <ty...@monkeypox.org> wrote: > (replies inline) > > On Fri, 16 Mar 2018, Andrew Bayer wrote: > > > If we???re going to be tracking step invocations anyway, it???d be > interesting > > to count the number of Declarative Pipelines with

Re: [Essentials] Collecting usage telemetry from Jenkins Pipeline

If we’re going to be tracking step invocations anyway, it’d be interesting to count the number of Declarative Pipelines with a script block, maybe? A. On Fri, Mar 16, 2018 at 4:28 PM R. Tyler Croy wrote: > The successful adoption and iterative improvement of Jenkins

Re: Adopting xUnit plugin

...but could someone with ownership rights for github.com/jenkinsci/xunit-plugin update the repo description to https://plugins.jenkins.io/xunit? Thanks. A. On Tue, Nov 14, 2017 at 3:41 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > And yes, I've updated the JIRA component own

Re: Adopting xUnit plugin

And yes, I've updated the JIRA component owner myself. =) A. On Tue, Nov 14, 2017 at 3:38 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > Done - https://github.com/jenkins-infra/repository-permissions- > updater/pull/503 > > On Tue, Nov 14, 2017 at 2:51 PM, Daniel Beck

Re: Adopting xUnit plugin

Done - https://github.com/jenkins-infra/repository-permissions-updater/pull/503 On Tue, Nov 14, 2017 at 2:51 PM, Daniel Beck <m...@beckweb.net> wrote: > > > On 14. Nov 2017, at 18:50, Andrew Bayer <andrew.ba...@gmail.com> wrote: > > > > I guess I'll take it? =) G

Adopting xUnit plugin

Hey - So I want to get some changes into xUnit, and noticed the plugin is up for adoption. So...I guess I'll take it? =) GitHub and Jenkins infra usernames are both abayer. Thanks! A. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To

Re: Administrative paperwork :-)

I dunno, I'm not sure I trust this guy... ;) A. On Sun, May 7, 2017 at 8:58 PM, Olivier Lamy wrote: > Hi Folks, > I have been asked to send an email here because of this > https://github.com/jenkins-infra/repository-permissions-updater/pull/303 > So I do! > Let me know

Re: [Jenkins-infra] Any known consumers of the 'scm' element in update-center.json?

Pretty sure it's just for the wiki. A. On Mar 12, 2017 18:19, "Daniel Beck" wrote: > > > On 13.03.2017, at 02:14, Daniel Beck wrote: > > > > It was introduced in https://github.com/jenkins- >

Re: [ANN] Change to how the update center JSON files are created

Nice improvement, I'd say. A. On Tue, Mar 7, 2017 at 2:35 PM, Daniel Beck wrote: > > > On 07.03.2017, at 23:12, Daniel Beck wrote: > > > > Since we now cannot rely on the wiki pages to exist, how can be > accomplish the goals of having some minimal

RFC - Parallel stages in Declarative Pipelines

FYI - I've got an RFC up for discussion at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/126 on JENKINS-41334, a.k.a. parallel stages in Declarative Pipelines. Comments/discussion welcome. Thanks! A. -- You received this message because you are subscribed to the Google

Re: Declarative RFC: JENKINS-41118 - custom workspace support in Declarative

Oh, and you can comment on the RFC doc in the PR itself at https://github.com/jenkinsci/pipeline-model-definition-plugin/pull/123/files#diff-97b9ea96a3eef68edab62f56858e313d A. On Thu, Feb 23, 2017 at 4:29 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > Hey all - > > W

Declarative RFC: JENKINS-41118 - custom workspace support in Declarative

Hey all - We're trying out a design review/RFC process for Declarative, with an RFC doc added to a PR for discussion. The RFCs will live in the rfcs subdirectory of the pipeline-model-definition-plugin.git repository, and in this case, is included in the already-in-progress PR (

Re: Upgrade guava to at least 18.0

, with Guava relocated. A. On Thu, Feb 23, 2017 at 1:17 PM, Stephen Connolly < stephen.alan.conno...@gmail.com> wrote: > Then you need to shade that dependency... > > On Thu 23 Feb 2017 at 20:53, Oliver Gondža <ogon...@gmail.com> wrote: > >> On 2017-02-23 21:40, Andrew Baye

Re: Upgrade guava to at least 18.0

fwiw, that seems to only work for certain Guava version differences - over in the jclouds plugin, I eventually ran into problems going to anything past Guava 13, I think, and ended up needing to shade Guava. A. On Thu, Feb 23, 2017 at 8:23 AM, tamal wrote: > Thanks Oliver.

Re: Jobs creation on jenkins.ci.cloudbees.com restored

I just disabled https://jenkins.ci.cloudbees.com/job/plugins/job/pipeline-model-definition-plugin/ 'cos I just want the multibranch setup on ci.jenkins.io to run - is there a better way to ensure that a given plugin repo won't get built on jenkins.ci.cloudbees.com? A. On Thu, Jan 19, 2017 at

Re: [Blue Ocean] Dockerfile in Declarative Pipeline building but not running?

Sounds like a bug - could you open a JIRA in the pipeline-model-definition component? On Dec 27, 2016 17:03, "Josh S" wrote: > Jenkins v2.19.4 (running in a Docker container with -v > /var/run/docker.sock:/var/run/docker.sock to help prevent > Docker-in-Docker issues) >

URI is not hierarchical error running tests in Intellij?

I've got a project that's now two plugins as submodules in a Maven project - the plugins inherit from the plugin parent POM, not the aggregator POM. Now Intellij is refusing to run my tests in the second plugin (which depends on the first) with errors like

Re: Can I get on the cert team?

Oh, and I do have my CLA on file and have 2fa on Github. A. On Mon, Oct 10, 2016 at 2:30 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > GitHub username - abayer > jenkins.io username - abayer > email: andrew.ba...@gmail.com > IRC: abayer > > A. > -- You receiv

Can I get on the cert team?

GitHub username - abayer jenkins.io username - abayer email: andrew.ba...@gmail.com IRC: abayer A. -- 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: New Pipeline plugin: Pipeline Model Definition

gt; On Tuesday, August 30, 2016 at 12:33:30 PM UTC-5, Andrew Bayer wrote: >> >> Hey all - >> >> I've released a first preliminary version (0.1) of a new plugin, >> Pipeline: Model Definition. It's intended to provide a more >> config-like/declarative way to define

Re: Speeding up JenkinsRule tests?

Yipes! Even better for the full test run - from 51m47s end-to-end on ci.jenkins.io to 6m8s with @ClassRule. Looks like that actually is the magic bullet here. A. On Mon, Sep 26, 2016 at 1:37 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > huh, initial experiments with turning the Je

Re: Speeding up JenkinsRule tests?

huh, initial experiments with turning the JenkinsRule into a @ClassRule rather than a @Rule have been...surprisingly positive. 4+x decrease in one of the parameterized tests (from 95s to 21s). I'll experiment more in that direction. A. On Mon, Sep 26, 2016 at 1:24 PM, Andrew Bayer <andrew

Speeding up JenkinsRule tests?

My tests in https://github.com/jenkinsci/pipeline-model-definition-plugin take...an ungodly amount of time. In part, that's 'cos I'm doing a *lot* of tests, and I'm using parameterized tests to make sure that failures are clear in some cases. But I gotta feel like things could be sped up. Does

Re: New Pipeline plugin: Pipeline Model Definition

I'm not great at explaining in an intro email. =) It's a new syntax, yes. The intent is to be something closer to a "config" feel and fit more into how people are used to Freestyle jobs working - a more structured form with some default assumptions (like that you'd probably want to send

Re: New Pipeline plugin: Pipeline Model Definition

Oh, and I'll be presenting on this at Jenkins World on Thursday the 15th in the afternoon, with a demo during lunch time, and will be around to chat all week. =) A. On Tue, Aug 30, 2016 at 10:32 AM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > Hey all - > > I've released a fi

New Pipeline plugin: Pipeline Model Definition

Hey all - I've released a first preliminary version (0.1) of a new plugin, Pipeline: Model Definition. It's intended to provide a more config-like/declarative way to define Pipelines, with features like better syntactic/semantic error messages, an easy way to specify notifications or post-build

Lots and lots of ATH failures - looking for Selenium help

Lately, ATH failures have gone crazy - it seems to be either core 2.5 or 2.6 and Firefox just...is bad. Lots of timeouts all over the place. I've opened https://issues.jenkins-ci.org/browse/JENKINS-35134 for this, but I'm pretty much at my limit of expertise - I don't know enough about Selenium

Re: RFC: Plumber - a declarative layer on top of Pipeline

And it's in https://github.com/jenkinsci/plumber-plugin now. =) On Mon, May 23, 2016 at 9:06 AM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > Hey all! > > So I've been working on this in skunkworks form for a while now, and now > it's far enough along that I'd like to brin

RFC: Plumber - a declarative layer on top of Pipeline

Hey all! So I've been working on this in skunkworks form for a while now, and now it's far enough along that I'd like to bring it to all of you for discussion/critiquing/nitpicking/etc. Conceptually, Plumber is a declarative layer on top of Pipeline, allowing you to specify phases of your

Re: Patching Groovy?

You can push to the jenkinsci/groovy repo now. On Fri, May 20, 2016 at 11:14 AM, Daniel Spilker <m...@daniel-spilker.com> wrote: > OK, sounds reasonable. Option 3 it is. Can someone give me the necessary > permissions (see above)? > > Daniel > > On Fri, May 20, 2016

Re: Patching Groovy?

I'm pro #3 given timeframes - it'll be at least a week or so for 2.4.7 to get released (given time to get the vote started/finished, etc) at best, and I'd prefer not to pull in unreleased changes we don't know we *need*. A. On Fri, May 20, 2016 at 7:58 AM, Daniel Beck wrote:

Re: Statistics generation disappeared?

Yup, a casualty of the infra craziness - Tyler's deciding whether we should just move what we used to have into the new infra or if I should rewrite it. =) A. On Tue, May 10, 2016 at 11:54 AM, Kanstantsin Shautsou < kanstantsin@gmail.com> wrote: > Hi, stats is missing statistics for

Forcing Pipeline "node" blocks to run on the same agent/in the same workspace?

i.e., something like https://wiki.jenkins-ci.org/display/JENKINS/Node+Stalker+Plugin - is there any way to do this sort of thing in Pipeline as it exists today? I *think* I'd like to be able to inspect an executed "node" block and see where it ran, and then pass that onward to a future "node"

Re: Can script-security be used to validate/reject Pipeline code with disallowed steps?

Forget this - for what I need, SecureASTCustomizer is perfect - I'm not worried about malicious use of those steps, just keeping people from stepping on their toes. A. On Wed, Apr 6, 2016 at 2:07 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > For my various experiments, I've

Can script-security be used to validate/reject Pipeline code with disallowed steps?

For my various experiments, I've got a way to contribute Pipeline code as functions either from plugins or the global library, but I'd really like to apply some restrictions to the code that can be included in those functions - i.e., no "stage", no "node", no "parallel" most notably. It *feels*

Re: Plugin installation stats broken?

The numbers are going to look lower than they should for a while - due to https://jenkins.io/blog/2016/03/30/usage-statistics-privacy-advisory/, Jenkins instances of releases 1.645 through 1.652 (and LTS releases 1.642.2 and 1.642.3) will never show up in the usage stats, so we won't have any data

Re: Any way to access the WorkflowLibRepository from another plugin?

Fair enough, but in the meantime, how would I get access to the repository from another plugin? =) A. On Sun, Mar 27, 2016 at 10:32 AM, Jesse Glick wrote: > Accessing the existing repository is easy enough, but do you really want > to? I expect to deprecate the whole

Re: CPS transforming at compile time?

and then returning that method as the argument to the step. A. On Mar 30, 2016 11:25, "Jesse Glick" <jgl...@cloudbees.com> wrote: > On Wed, Mar 30, 2016 at 2:08 PM, Andrew Bayer <andrew.ba...@gmail.com> > wrote: > > if you try to pass a Closure from CPS > >

Re: CPS transforming at compile time?

I was wondering if there was a way to put Pipeline code in a plugin in src/main/groovy rather than src/main/resources, and/or to get code that gets used by Pipeline code CPS transformed at compile time so that the code would use the same closures (i.e., CpsClosure rather than standard Groovy

CPS transforming at compile time?

I'm doing all kinds of weird stuff with Pipeline scripts delivered by plugins, and I'm beginning to get annoyed at having to have the actual Pipeline script (which is being served similar to a GlobalVariable) in src/main/resources rather than src/main/groovy. I'm assuming the root reason for this

Any way to access the WorkflowLibRepository from another plugin?

I'm trying to figure out if I should just implement my own FileBackedHttpGitRepository or if I can piggy-back on the one for cps-global-lib (using a new directory at the root level for the Pipeline snippets my plugin is consuming). If I were to use the existing WorkflowLibRepository, any idea how

Re: react on failed tests in pipeline script

I think the Junit result archiver should mark the build as unstable if there are failures... On Mar 21, 2016 7:16 PM, "Michael Neale" wrote: > I am assuming that ignoring test failures doesn't make the shell step > fail? (Ie it returns a success code?) > > If so, removing

Re: Hopefully silly Descriptor question...

Okiedokie On Wed, Mar 16, 2016 at 4:29 PM, Jesse Glick <jgl...@cloudbees.com> wrote: > On Wed, Mar 16, 2016 at 6:18 PM, Andrew Bayer <andrew.ba...@gmail.com> > wrote: > > If I've got multiple implementations of an extension point, can I still > have > > just one

Hopefully silly Descriptor question...

If I've got multiple implementations of an extension point, can I still have just one Descriptor for the abstract class they're inheriting from? I ask 'cos I need to keep some transient data there on startup (parsed Pipeline scripts contributed by other plugins) that I don't want to have to

Generalization of parallel special-casing in Pipeline DSL?

So https://github.com/jenkinsci/workflow-plugin/blob/30a80b44ef524333165ed59b25de30daf1b2a99d/cps/src/main/java/org/jenkinsci/plugins/workflow/cps/DSL.java#L116 - right now, the parallel step is the only step that can act as a container for further steps without having those further steps directly

Re: new hadoop-plugin

That said - yeah, start over. I'd suggest maybe calling it "hadoop-integration-plugin" or something like that. A. On Fri, Feb 19, 2016 at 1:18 PM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > Frankly, the old one should just be retired - it was never actuall

Re: new hadoop-plugin

Frankly, the old one should just be retired - it was never actually *useful* per se. =) A. On Thu, Feb 18, 2016 at 11:37 PM, Richard Bywater wrote: > Based on what I've just read about the old plugin (a 2 minute look :) ) I > think that a new plugin might be best as the two

FYI - nuking some empty/unused repos on GitHub.

I just got annoyed at https://github.com/jenkinsci?utf8=%E2%9C%93=jenkinsmobi - five repos with no commits, all over two years old. So, well, I'm nuking 'em from orbit. If/when whoever was intending to use them ever wants to actually push anything there in the future, open a HOSTING JIRA to get

Re: hot reloading - plugin development flow (what is meant to work?)

I've always had problems with the hpi:run ENTER reloading - I think, if I remember correctly, that it's bugged out on OS X... A. On Wed, Feb 3, 2016 at 5:52 AM, Baptiste Mathus wrote: > I /think/ that 2) got some improvement in the maven-hpi-plugin itself > (seem to

Re: [pipeline] Hard to find "Click here to forcibly terminate running steps"

Yeah, that confused me immensely. There really should be a more obvious/intuitive UI there. Thanks for opening the JIRA! On Friday, January 29, 2016, Craig Rodrigues wrote: > Hi, > > I recently had a pipeline running, and had to terminate it from the web > interface by

Re: [PROPOSAL] Separate build logs from Jenkins master

This seems worth discussing for whatever comes after 2.0, for sure. Could you open a JIRA detailing your proposal? A. On Wed, Jan 13, 2016 at 10:10 AM, 'Laurence Bordowitz' via Jenkins Developers wrote: > Just like with abstract artifacts (see VirtualFile,

Re: [PROPOSAL] Split of `jenkins-test-harness` out of `jenkinsci/jenkins`

I'd be a big +1 on this as well. It makes sense to have the harness as a separate project consumed by Jenkins core and plugins for their testing. A nice side effect is that we'd be able to actually move the core tests currently in jenkins.git/test/src/test/... into jenkins.git/core/src/test/..., I

Re: NOTICE: Plugins without wiki pages will stop appearing in the Update Center

They may not have had a wiki page when the overrides were setup initially. A. On Tue, Jan 5, 2016 at 8:12 AM, Jesse Glick <jgl...@cloudbees.com> wrote: > On Mon, Dec 28, 2015 at 10:30 AM, Andrew Bayer <andrew.ba...@gmail.com> > wrote: > > You can find the full list

Script Security plugin dry-run for pre-approval?

So I couldn't figure out a good way to word the subject line, but! I've had a few cases where I've needed to go through multiple iterations of "Run a Workflow via a Jenkinsfile" or "Run a system Groovy step", etc, where each time I run, a new method causes the run to fail and is queued up for

Re: Update center and plugins without wiki pages

Ah, so we'll have to remove those from the properties file... A. On Mon, Dec 28, 2015 at 10:14 AM, Daniel Beck <m...@beckweb.net> wrote: > > > On 28.12.2015, at 16:10, Andrew Bayer <andrew.ba...@gmail.com> wrote: > > > > it should be already excludin

Update center and plugins without wiki pages

So I go to make changes to exclude plugins without wiki pages from the update center, and based on [0], it looks like it's already done? [1] has the call to generate the JSON and for the mainline update center, it's not specifying a cap or core cap, so it should be already excluding wiki-less

NOTICE: Plugins without wiki pages will stop appearing in the Update Center

As of today or tomorrow, depending on when https://github.com/jenkinsci/backend-update-center2/pull/34 is merged, plugins without wiki pages will no longer show up in the Update Center. New plugins without wiki pages added since June already didn't show up, but now already-existing plugins are

Re: Request for hosting: CPWR-PDS-download

Why doesn't it make sense to combine them? A quick glance at the source suggests they're really, really, really similar. A. On Tue, Dec 22, 2015 at 11:35 AM, cpwr_jenkins wrote: > Hi Guys, > > What's the status on the plugins? Are they good to be forked? > > > > --

Re: Proposal: forbid direct commits to master for core

Oh, definitely! On Dec 21, 2015 8:39 AM, "Arnaud Héritier" <aherit...@gmail.com> wrote: > > > On Sun, Dec 20, 2015 at 6:22 PM, Andrew Bayer <andrew.ba...@gmail.com> > wrote: > >> So, addressing a few aspects of this thread: >> >> - I'd stro

Re: Proposal: forbid direct commits to master for core

So, addressing a few aspects of this thread: - I'd strongly oppose ICLA/push permission revocation for pushing directly to master. That's overly harsh. - I do support this policy overall - I'm personally a big fan of a "Review then Commit" policy. - There is a caveat/exception, of course -

Re: pipeline editor plugin

I believe, from a quick look, that it stores the resulting Workflow script in the job's config.xml. On Dec 18, 2015 11:21 AM, "Kanstantsin Shautsou" wrote: > Can it store configuration directly in Jenkinsfile on jenkins side? > > On Friday, December 18, 2015 at 7:08:37

Re: (another) docker slaves plugin - review request

Yeah, it's painful and needs serious revisiting. I'd be up for discussions around that for 2.0 or soon after. I think that'd be valuable. A. On Wed, Dec 16, 2015 at 10:52 AM, Kanstantsin Shautsou < kanstantsin@gmail.com> wrote: > I missed my favorite question :) > > Jenkins Cloud API is not

Re: Request for hosting: CPWR-PDS-download

Out of curiosity, would it make more sense to combine these into one compuware-download plugin rather than splitting it into two plugins? It seems like it'd make things a bit simpler for users. A. On Mon, Dec 14, 2015 at 9:40 AM, cpwr_jenkins wrote: > We have

Re: List of unused code in Jenkins

Yeah. This is really fascinating stuff - thanks for the work! On Monday, December 14, 2015, Oleg Nenashev wrote: > Hi Emeric, > > Thanks a lot for your efforts! +1 from me for forking the additional tool. > > Since we plan to add the API deprecation and removal policy in

Re: Looking for input: Workflow scripting best practices

<d...@fortysix.ch> wrote: > This might be an interesting one: > http://technologyconversations.com/2015/12/08/blue-green-deployment-to-docker-swarm-with-jenkins-workflow-plugin/ > /Domi > > On 10 Dec 2015, at 15:47, Andrew Bayer <andrew.ba...@gmail.com> wrote: > >

Trying to figure out how to add Workflow step support for Throttle Concurrent Builds...

So, https://issues.jenkins-ci.org/browse/JENKINS-31801 - I'm starting to dive into the Workflow code to figure out how to actually *do* this. I'm only really concerned with adding category throttling support for Workflow node blocks - i.e., wrap your node block with "throttle('some-category') {

Re: build-user-vars-plugin: request for new release

> upload hpi to jenkins repo - stuck on deploy (201/201) without error. > I would appreciate if someone could upload artifact, otherwise I'll come > back to this on Sunday. > > > On Thursday, December 10, 2015, Andrew Bayer <andrew.ba...@gmail.com > <javascript:_e(%7B%7D,'c

Re: build-user-vars-plugin: request for new release

Released! Should show up in the Update Center soonish. A. On Fri, Dec 11, 2015 at 8:29 AM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > Great, I'll get it released today - thanks! > > > On Friday, December 11, 2015, Gavriil Konovalenko <gkonovale...@gmail.

Re: build-user-vars-plugin: request for new release

If you haven't heard from Gavriil by mid-next week, ping this thread again and I'll do a release for you. A. On Thu, Dec 10, 2015 at 1:58 PM, martinda wrote: > Hi, > > Is there any objection or any obstacle standing in the way of releasing a > new version of the

Re: Proposal: Deprecate/hide from the update center plugins without wiki pages

Rightie-o, then the clock is starting as of now - four weeks from today (on my birthday!), we'll be turning this on. A. On Tue, Dec 1, 2015 at 8:49 AM, Baptiste Mathus <m...@batmat.net> wrote: > > 2015-12-01 13:47 GMT+01:00 Daniel Beck <m...@beckweb.net>: > >> >>

Re: jclouds-plugin Commit Access for Merging and Releasing v2.8.1

Sure thing - adding you now. A. On Tue, Dec 1, 2015 at 10:02 AM, Michael Fero wrote: > I am interested in receiving commit access to merge and release a version > of the jclouds-plugin (https://github.com/jenkinsci/jclouds-plugin) to > address [JENKINS-31655] ( >

Proposal: Deprecate/hide from the update center plugins without wiki pages

A surprisingly large number of plugins (35 or so at last check) don't have wiki pages on wiki.jenkins-ci.org, and so don't get populated usefully in the update center. Some of them can probably have wiki pages added by their active maintainers, but others are just...orphaned, for lack of a better

Workflow compat and parameters...

I'm poking around at a few plugins to get them Workflow-compatible and have found in at least one of them (groovy) that it's using AbstractBuild to get the build variables, including parameters. Since parameters aren't actually available off Runs directly, I'm not sure how to proceed here - does

Re: Deprecating the Jenkow-plugin?

+1 On Nov 20, 2015 09:56, "Slide" wrote: > +1 > > On Fri, Nov 20, 2015, 07:29 Baptiste Mathus wrote: > >> Hi, >> >> See https://wiki.jenkins-ci.org/display/JENKINS/Jenkow+Plugin >> >> I propose to deprecate this plugin for the following reasons: >> >>

Re: Proposal: Use the same DSL for the job-dsl-plugin and for the workflow-plugin

So this has been brought up before - I think it'd be a good thing if it's viable. I'm honestly not sure how hard it'd be, though... A. On Sat, Oct 17, 2015 at 11:43 PM, Stefan Wolf wrote: > Hi, > > both the job-dsl-plugin and the workflow plugin are using a groovy-DSL to >

Re: performance labs

Yeah, stability is my biggest concern, and an even harder thing to test for than performance. Might be worth scraping through JIRA to find examples of behavior that tends to trigger instability in various ways to come up with some ideas... A. On Wed, Oct 14, 2015 at 1:36 PM, Artur Szostak

2.0 - breaking out into multiple tracks

We have differing visions of what "Jenkins 2.0" would actually mean, and those visions are to a certain extent mutually incompatible - getting 2.0 out in the timeframe Kohsuke has proposed wouldn't be possible if that requires not just the user experience work he has mentioned but also storage

Re: 2.0 - breaking out into multiple tracks

On Thu, Oct 8, 2015 at 11:12 AM, Vojtech Juranek wrote: > in general I agree with your (I'd like to see changes in backend happen as > well), but I'm not sure about this one - you don't expect any API changes > or > you propose to do backward incompatible changes in a minor

Re: Jenkins 2.0 proposal

Tyler did write a jenkins puppet module that can do some of this stuff - https://github.com/jenkinsci/puppet-jenkins. But something on the jenkins side to better support this sort of scenario would definitely be valuable. A. On Thursday, October 8, 2015, domi wrote: > Hey

Re: 2.0 - breaking out into multiple tracks

Fair enough. On Oct 8, 2015 14:04, "Jesse Glick" <jgl...@cloudbees.com> wrote: > On Thu, Oct 8, 2015 at 3:00 AM, Andrew Bayer <andrew.ba...@gmail.com> > wrote: > > Pluggable storage/database backend - Scope to be determined, myself as > > she

Re: 2.0 - breaking out into multiple tracks

re to fix actual longstanding issues) > > My 2 cents > > 2015-10-08 14:08 GMT+02:00 Andrew Bayer <andrew.ba...@gmail.com>: > >> Fair enough. >> On Oct 8, 2015 14:04, "Jesse Glick" <jgl...@cloudbees.com> wrote: >> >>> On Thu, Oct 8

Re: Jenkins 2.0 proposal

So looking back over the thread - my concerns have pretty much all been about missed opportunities to address stability and performance issues that may require more work in core than we normally do in a release (not necessarily compatibility-breaking ones). In the 7 or so years I've been involved

Re: Jenkins 2.0 proposal

Yeah, I'm not shocked - directory traversal + disk i/o is nowhere near as efficient as pretty much any database ever written. =) I'm really excited about the kind of analytics that could be done with build data in a database backend - even if it's just serialized XML and not document-native to

Re: performance labs

boot up, > but something up there would be nice). > > I guess the next step is an initial scope of what we want to measure. To > keep things focussed I am thinking or boot up to job load time, and listing > a few things. > > > > > On Thursday, October 1, 2015 at 5:55:

Re: [2.0] Website rebump

+1. This isn't a website that stands on its own - it's information about Jenkins. That's it. A. On Wednesday, October 7, 2015, Daniel Beck wrote: > > On 07.10.2015, at 19:41, Gus Reiber > > wrote: > > > Bad comments can be corrected, and

Re: [2.0] Website rebump

trap.com/ > ...this is a totally different approach. They just go straight into their > doc, more or less, but still have a little splice where you can find blog > articles and some news. > > ...anyone have any others that are a little closer to our domain? > > > > > On Wed

Re: Jenkins 2.0 proposal

So in re: backend storage - a possible pilot suggestion - unit test results. That's something that'd be really handy to be able to query/report on outside of Jenkins, and is fairly self contained... A. On Tue, Oct 6, 2015 at 2:44 PM, Daniel Beck wrote: > > On 06.10.2015, at

Re: Jenkins 2.0 proposal

On Fri, Oct 2, 2015 at 10:21 PM, Kohsuke Kawaguchi wrote: > > I don't want to get into the CI vs CD definition argument, but I think CD > is less narrow than CI. > > Initially I wasn't very keen on the new domain name myself, but over the > time it growed on me and I started

Re: performance labs

...and I can most likely provide builds.apache.org's jobs/builds/load/etc as a use case. A. On Thu, Oct 1, 2015 at 9:54 AM, Andrew Bayer <andrew.ba...@gmail.com> wrote: > +1 - that'd be fantastic. I'd love to help with that. > > A. > > On Thu, Oct 1, 2015 at 4:50 AM, Mich

  1   2   >