[ANN]: Snowglobe plugin (CI, CD, Docker, Pipelines, IAC)

Greetings fellow Jenkins users. I have just pushed v0.4 of snowglobe-plugin for jenkins, I thought this is the point at which it is possibly useful for others treading down the same path as us. We develop software which is shipped as Docker images, which is neat. But what starts out as a simple

onDeleted not called when PR closed?

I have a plugin with a listener extending RunListener I have projects using the Github organisation plugin, which creates a build per PR. I was expecting onDeleted to get called for each run when the PR was merged, but it doesn't seem to. Is that a bug, or should I listen for something else?

Re: hello & improving Jenkins & Kubernetes CI / CD

I'd be interested - we rolled our own twine after briefly experimenting with terraform, so I build a groovy/DSL based equivalent that's work-in-progress but more programmable.. On Thu, Mar 1, 2018 at 1:50 PM, James Strachan wrote: > Hello folks! > > I’m James

Updating JIRA fields in a pipeline

I had thought a combination of the >3 JIRA plugins available would do this, but I"m getting stumped. What I want: In my pipeline, for the ticket IDs mentioned in the build (e.g. PROJ-1, PROJ-2, PROJ-xxx) - set a custom field to a value - transition those tickets thorough a jira workflow step

Re: Request to become maintainer on docker-plugin

Please - go for it. I don't have the bandwidth these days to support it in anything like a timely manner. On Tue, 5 Sep 2017 at 18:20, nicolas de loof wrote: > Hi folks, > > docker-plugins as 20 pull requests pending for review and no new commits > since Nov 16th. > I

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

Update already. Those in bizarre AIX, zOS and HPUX universes can continue to use older Jenkins versions. On Thu, Oct 13, 2016 at 1:29 PM, Baptiste Mathus wrote: > Hey folks, > > As we've been discussing that again on IRC recently, we thought it might > be a good time to

Re: [PROPOSAL] Semi-automated detection of unmaintained plugins

This stuff seems very wrong-headed to me, and headed towards exactly the kind of 'governance orgy' I always thought Jenkins eschewed. Really, I can't help but thinking regularly about that proposal. IMO it's > just too simple to not try it. And really it would have value with *very* > few

Re: "checkout scm" in multibranch/pipeline

On Thu, Apr 7, 2016 at 5:22 PM, Jesse Glick <jgl...@cloudbees.com> wrote: > On Wed, Apr 6, 2016 at 10:39 AM, Nigel Magnay <nigel.mag...@gmail.com> > wrote: > > I could probably build a container image with an baseline git > > repo in it > > Or keep a persistent

Re: "checkout scm" in multibranch/pipeline

gt; > Mark Waite > > On Wed, Apr 6, 2016 at 8:39 AM Nigel Magnay <nigel.mag...@gmail.com> > wrote: > >> I'm happily using the Github org folders, with multibranch projects, >> which are very cool. >> >> One issue that we have, is our git project is get

"checkout scm" in multibranch/pipeline

I'm happily using the Github org folders, with multibranch projects, which are very cool. One issue that we have, is our git project is getting pretty big, and our inbound network connection is not particularly fast. This means each fresh build which spins a docker container to run in, when it

Re: [PROPOSAL] Clarify the source code canonical place is required to be under the GH org (was:[DISCUSS] Hide from the update center plugins without source code under the Jenkinsci github organization

> > > > > I think it is important to be clear what we're talking about here. We're > not > forcing people to use github.com/jenkinsci for plugins, ​Ok then - I'm confused. The title of this email thread is : "​[PROPOSAL] Clarify the source code canonical place is required to be under the GH org

Re: [PROPOSAL] Clarify the source code canonical place is required to be under the GH org (was:[DISCUSS] Hide from the update center plugins without source code under the Jenkinsci github organization

I am strongly -1 in the idea of forcing plugins to be hosted with jenkinsci. You will already have seen instances where those "granted power" hold an effective veto over forking plugins into that organisation. That *is* raising a barrier (and one that does not exist if I want to, for example,

Re: Plugin Hosting Request: Violations Reboot Plugin

> > > Can't we let people do what they want instead of forcing people to deal > with code they don't want to. We are actively harming jenkins community by > overly policing plugins. > > ​A thousand times this. I was about to say "you can, there's no need to fork into jenkinsci, just release from

Re: (another) docker slaves plugin - review request

I haven't fully grokked how the alternative launch scheme works (I assume it's operating as a launcher higher up the food chain). I don't know if this is giving you options of controlling the build environment before it is launched based on the build it is about to execute. I would imagine you

Re: (another) docker slaves plugin - review request

> > > > nigelm, > > It uses queue listener to look for a label and add a slave . > > Docker has many, many load balancing tools , docker swarm for example. You > can simply point jenkins to your swarm instance for docker. > > I see no reasons why Jenkins would be doing load balancing with docker >

Re: (another) docker slaves plugin - review request

> I agree that independent Docker slave makes sense. > IIRC such functionality is provided by one of existing Docker plugins, but > I'm not sure. There're too many of them :( > > If no, I would vote for integrating the proposal into Docker-plugin if > there is no showstoppers. > > ​docker-plugin

influencing workspace name

Hi - I have projects building with workflow multibranch. The directory these build in, chosen by jenkins, is /home/jenkins/projectname/branchname Since my branch is called dev/main, I get /home/jenkins/foo/dev%2fmain Which is fine, but turns out quite a few maven things dislike having a % in

Re: Re: Highcharts usage in Jenkins Plugin - Licence

> (unintentional) violation of the license by end users. > > ​Oh, it will be. You're asking an awful lot of end-users to be going through plugin detail (the vast majority are entirely unencumbered by transitive licensing issues) to determine if they're 'allowed to use it' or not. They're just not

Re: Highcharts usage in Jenkins Plugin - Licence

at 10:10 AM, Ullrich Hafner <ullrich.haf...@gmail.com> wrote: > Wouldn’t it make sense to ask what a commercial license would cost for the > Jenkins project so that users of Jenkins don’t need to bother about the > license at all? > > Am 25.11.2015 um 10:59 sch

Re: Highcharts usage in Jenkins Plugin - Licence

<ullrich.haf...@gmail.com> wrote: > > Am 25.11.2015 um 11:27 schrieb Nigel Magnay <nigel.mag...@gmail.com>: > > The concern isn't the "Jenkins Project" - that's non-profit and can use it > at will. It's the *end users*. Their FAQ claims: > > NON-COM

Re: Why doesn't this jelly page show the configuration

On Wed, Nov 18, 2015 at 4:48 PM, 'Jesse Glick' via Jenkins Developers < jenkinsci-dev@googlegroups.com> wrote: > On Wed, Nov 18, 2015 at 9:56 AM, Nigel Magnay <nigel.mag...@gmail.com> > wrote: > > public class HelloWorldPlugin extends Plugin implements > Describab

Re: New Plugin hosting request: Docker Ephemeral Cloud

> > > To be honest, the whole list of jenkins docker plugins feels like a zoo > and there is no way a normal user can keep up and make the right choice. > I think this work should be coordinated better and an uptodate comparison > should be kept at a central place. > ..my 2cents > /Domi > > I

Why doesn't this jelly page show the configuration

I must be having a bad day, but I can't figure out why this isn't working. HPI plugin reduced to *only* 1 class and the jelly file (both below). Config is being correctly set. Config is being correctly saved to the plugin config.xml. Config is *not* being loaded/displayed in the UI, however.

Re: New Plugin hosting request: Docker Ephemeral Cloud

FWIW, I have pushed changes for both TLS and JNLP in docker-plugin, so the comparison can now be reduced to Docker Plugin - Provides additional capabilities beyond slaves, such as Docker build steps. On Tue, Nov 17,

workflow groovy odd result

Script: def a = ["a", "b", "c", 3]; def b = a.find() { x -> x instanceof Integer }; println "$b"; In groovyConsole this prints 3 (as expected) In workflow it prints 'false' ? -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To

Re: [proposal] coding style for core (jenkins 2.0?)

> > > > > You describe things with a very broad brush. Earlier you extrapolated > from a request to format code into a comment about management measuring the > irrelevant. Now you're declaring that the benefits my team of 10+ (using > extreme programming as our methodology, pair programming

Re: [proposal] coding style for core (jenkins 2.0?)

You don't need to trial automatic code formatting it to know it's going to produce a terrible result. Trivial example 101. Which is the more easily parseable to the human eye? periodFormatter = new PeriodFormatterBuilder() .printZeroAlways()

Re: [proposal] coding style for core (jenkins 2.0?)

> That's why automation check should save time and enhance quality. It only “enhances quality” if you agree with the idea that a set of arbitrary syntactic checkstyle rules spat out by tooling represents “quality” rather than merely “conformity". The truth is ‘quality’ is rather hard to measure -

Re: [proposal] coding style for core (jenkins 2.0?)

t;m").toFormatter(); > <——— scroll ——> > > P.S. Am i alone who receives emails from Nigel with small blue font? > On Oct 27, 2015, at 01:02, Nigel Magnay <nigel.mag...@gmail.com> wrote: > > You don't need to trial automatic code formatting it to know i

Re: [proposal] coding style for core (jenkins 2.0?)

-1. Automated code formatting in general makes a total pigs breakfast of fluent APIs. I find it hard to get inside the heads of people that love to spend time worrying about how many spaces come before and after the brackets in an "if" statement. Sure, have some guidelines, make sure you don't

Re: [2.0] Website rebump

+1 I'd imagined something like www.git-scm.com. They've had over 100 individual contributors. I'd completely bin comments. I don't see why the site needs to *host* a blog - why can't it just be links to Jenkins articles elsewhere. Bigger requirements just end up sucking you towards the

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

Re: 2.0 - breaking out into multiple tracks

> > > Ok, I'll bite. > > There are a number of conflicting things we need to balance. > > * There are some bigger UI/UX refreshes that we want to get out to > users. A long standing complaint is that the Jenkins UI/UX is dated. > Moving to a 2.0 label corresponding to the visible UI changes helps

Re: Jenkins 2.0 proposal

> > Personally still trying to decide if it's visionnary or weird ;-). > But indeed, jenkins.cd is also growing on me. Maybe others system will > just follow The Jenkins Way like they all struggle to do currently ;-). > > ​Until continuous-X becomes the 'new hotness'. http://jenkins.build ? (see

Re: Jenkins 2.0 proposal

Would 2.0 be an appropriate juncture to revisit the plugin architecture? I've often gotten bitten by classloader issues in 2nd/3rd party dependencies (e.g: plugin wants newer version of guava than jenkins-core). Shading is a reasonably complicated thing to do for a plugin, and I wonder if

Re: Guidance on how far SECURITY fixes should go

>From the perspective of a plugin developer and Jenkins Instance owner, who often goes months at a time between re-visiting plugin code, I'd like the following (ymmv, of course!): 1) I'd like the interfaces I *build* to, to *not have* *at all* interface methods and fields that are no longer

Re: Guidance on how far SECURITY fixes should go

compiled against an older > jenkins than your oldest until... (we could expose the same logic for > plugin dependencies so that plugins could use the @UnsecureAlternative > annotation also) > > The advantage of @UnsecureAlternative is that we get to move the API > contracts while allowing peo

Git plugin - feature branch frustrations

So I'm trying to set up the git plugin to build feature branches. Features are on branches like feature/foo and feature/blah. This is a common pattern as it's derived from git-flow. I seem to have tried every combination of branch specifiers, and all this results in is jenkins building the same

Re: Git plugin - feature branch frustrations

On Mon, Aug 3, 2015 at 10:04 AM Nigel Magnay nigel.mag...@gmail.com wrote: So I'm trying to set up the git plugin to build feature branches. Features are on branches like feature/foo and feature/blah. This is a common pattern as it's derived from git-flow. I seem to have tried every

Re: Git plugin - feature branch frustrations

, rather than using the maven project type? I think your users will thank you. Mark Waite On Mon, Aug 3, 2015 at 10:30 AM Nigel Magnay nigel.mag...@gmail.com wrote: Multi-branch looks useful, but sadly this project uses the maven project type. I did see some reports about it getting

Re: Kubernetes plugin advice

On Friday, April 24, 2015, Kanstantsin Shautsou kanstantsin@gmail.com wrote: I think all Cloud plugin developers will be glad to know about Cloud API problems and their changes. So my plan is to do a new cloud-api in a plugin. It makes it easier to update and experiment. I have

Re: Proposal : Jenkins to require Java 8

I think there's confusion over 'support' and 'develop'. Going JDK8 should not imply dropping non-JDK6 versions: Take Tomcat as an example. Tomcat 9 requires a newer JDK than Tomcat 8. That does not mean that Tomcat 8 isn't receiving 'support', or that it's stopped working - it's getting fixes,

Re: Proposal : Jenkins to require Java 8

JDK7 is end of life after April 2015, so in May 2015 if we pick the second model then we would be JDK8 but the LTS released in late April will have been JDK7 and JDK8... as technically only at then end of April is JDK7 EOL. The advantage of the second model is that the July LTS will

Re: Jenkins plugin's classloader isolation

What's the current story with guava? I.E: if you're pluginFirstClassLoader and a later-than-core guava in WEB-INF/lib, will this work? Or are you saying this implementation will 'leak' into other plugins? I notice jclouds-plugin goes to lengths to shade its dependency. It'd be nice if the

Re: Cloud slave never provisioned (sometimes)

The API is certainly problematic. For example, on the latest in-dev versions, I can generate (occasionally) a deadlock. You may wish to try upgrading your durable-task plugin Version 1.2 (Jan 13 2015) - issue #26380 http://issues.jenkins-ci.org/browse/JENKINS-26380 Occasional deadlocks

Re: Parameterise slaves launched in a cloud [workflow ?]

: On Sat, Oct 25, 2014 at 8:57 AM, Nigel Magnay nigel.mag...@gmail.com wrote: Being able to really cheaply push entire workspaces around feels like a worthwhile improvement Yes. Probably the API should also cover interactive workspace browsing; I think https://issues.jenkins-ci.org/browse/JENKINS

Re: Parameterise slaves launched in a cloud [workflow ?]

Ah, so what you are getting it is that after running a checkout and some initial steps on a workspace on one machine, you want subsequent steps on other slaves to use either a lightweight clone of the workspace (à la ZFS) or a shared mount of it (à la Docker volumes). This makes sense but

Re: Parameterise slaves launched in a cloud [workflow ?]

This at least is possible, if your Cloud honors a request for a label which was actually a previously used Slave.name. There is not much flexibility here but at least from a Workflow project it might be feasible. I am not sure what it buys you as opposed to doing all the build steps with a

Parameterise slaves launched in a cloud [workflow ?]

I'm thinking out loud here, but I wonder if it would be nice to be able to support the following scenarios in Jenkins (and docker plugin users have been asking for similar features). I use docker to launch slaves on a variety of boxes. This works very nicely. You can tell docker to attach a 'data

Re: Proposal : Jenkins to require Java 8

It is also not just so called esoteric OSes that do not have Java8. Take Ubuntu for example. The current latest release 14.04 still doesn't have Java8 as a native package http://packages.ubuntu.com/search?suite=trusty-updatessearchon=nameskeywords=openjdk. IIUC you currently have to rely

Re: Require JDK 7 to build?

(roll on JDK 8 as min runtime) ​+1 Yes, please. ​ -- 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. For more

Debugging JSON construction logic

Hi. I'm trying to fix this issue: https://github.com/jenkinsci/docker-plugin/issues/5 In my jelly, I have a repeatable section: f:repeatable field=templates // ... config stuff here /f:repeatable From an interaction POV, this works fine. But it bombs out trying to construct the JSON to

Re: Debugging JSON construction logic

/jenkins/plugins/docker/DockerTemplate/config.jelly On Wed, Apr 16, 2014 at 2:02 PM, Jesse Glick jgl...@cloudbees.com wrote: On Wed, Apr 16, 2014 at 8:38 AM, Nigel Magnay nigel.mag...@gmail.com wrote: In my jelly, I have a repeatable section: f:repeatable field=templates Did you mean to use

Re: Debugging JSON construction logic

=${%Push on successful build} field=pushOnSuccess f:checkbox/ /f:entry Fixed it. It'd be nice if there were a test list of invalid field names the testsuite could check against, but I guess it's a reasonably unusual case. On Wed, Apr 16, 2014 at 3:21 PM, Nigel Magnay nigel.mag

Re: Opensourcing a plugin under a different github org

Open source is also about making things together, not just making things public. Not necessarily. There are plenty of projects that are open source, that are not interested in contributions. Google Guava, for one. Putting things in jenkinsci group probably *should* mean 'open to

Re: Opensourcing a plugin under a different github org

+1. I don't like the idea of having some plugins referenced under the official update center that don't actually come from the jenkinsci github organization. The deal seems quite simple to me: either accept to host your plugin under the jenkins github org, or accept it doesn't appear in the

Re: NoClassDefFoundError: com/google/common/cache/CacheBuilder

Aaand... I've just been bitten by this too. Dependency uses guava 15 (and, indeed, 17 in later versions), fails bigtime when running in Jenkins, even though the library gets included in WEB-INF/lib. I understand I could fix this with shading... but shading always sounds to me like a craptastic

Re: mvn release does not work, only publishes SNAPSHOT releases

I've just had this problem too, with two separate plugins. maven-release-plugin is just total crapola. Just do a manual mvn versions:set and deploy. On Sat, Jan 4, 2014 at 4:17 PM, ogondza ogon...@gmail.com wrote: I have seen this problem today using: maven 3.1.1 maven-releas-plugin 2.2.2

SSH slaves broken ?

that job finishes, the queue drains, starting jobs on jenkins-1 jenkins5). This is all very strange.. On Tue, Jul 23, 2013 at 10:54 AM, Nigel Magnay nigel.mag...@gmail.comwrote: I have a job that has been running for a while, and the sidebar reports it as running on slave 'jenkins-2

Re: Maven Integration plugin with maven 3.1.x

Is there a reason why (non-freestyle) maven builds have to have their own build type? It seems very odd that you can have 1, and only 1 'native' maven build, and the rest have to use the 'other', freestyle job type. So if your build requires more than one invocation of mvn, you only get to choose

Re: Maven Integration plugin with maven 3.1.x

type is stupid... But has an alluring per-module reporting that is a sirens call to users. I have been a sting advocate for freestyle+maven build step since 2007 though, so I may be biased... But all the issues I see repeatedly re-enforce my bias :-P On Sunday, 21 July 2013, Nigel Magnay wrote

Re: [VOTE] Bump Jenkins to Java 6

OpenJDK7 can build on 10.5.8: https://wikis.oracle.com/display/OpenJDK/Darwin9Build On Wed, Jun 19, 2013 at 12:31 PM, Jürgen Keller jkel...@gmx.ch wrote: One of our slave machines is a PowerMac G5 computer, running Mac OS X 10.5.8 which is indeed stuck at Java 1.5. We need that slave to test

Re: use JGit in git-plugin

The intent, back in the mists of time, was always to use jGit rather than spawning the git commandline. However, back then, jgit didn't actually support all the necessary functionality. So the idea was to have an interface, and plug-in whatever back-end git implementation was appropriate. Much

Re: experiences with 'cloud' plugins / APIs in Jenkins

AM, Nigel Magnay nigel.mag...@gmail.comwrote: I'm wondering if anyone has gone down this route before, and has any experiences that they can share. We're looking to possibly creating a new build server. It seems (to me) that SmartOS would make an ideal host OS for running builds. (SmartOS

experiences with 'cloud' plugins / APIs in Jenkins

I'm wondering if anyone has gone down this route before, and has any experiences that they can share. We're looking to possibly creating a new build server. It seems (to me) that SmartOS would make an ideal host OS for running builds. (SmartOS is a Joyent-derived Illumos(Solaris) derivative