Re: design integration tests with JenkinsRule in remote env

I tried to use standard CLI connection from test and it works fine with Describables that comes from core. Custom (plugin) Describable initialised in Callable through channel missing Descriptor because this object doesn't match by java link (more specifically `type` from clazz) for Describable

Tool Installation (and confluence Labels)

Hey everyone, I just saw at the bottom of https://wiki.jenkins-ci.org/display/JENKINS/Tool+Auto-Installation specifically the more tools needed section. Is there a label for this? Is there a list of what labels automatically fill out what pages? So far I've been doing a bunch of grepping in

Re: Proposal: forbid direct commits to master for core

>Jenkinsci project model is bazaar. I see no any reasons for enforcing somebody unrelated to reasons why plugin was created causing delays by asking why some company needs host some plugin. Somebody created plugin and share for mass usage, you may use it or not. Delays for development ends

Re: design integration tests with JenkinsRule in remote env

Finally i got it working with standard CLI, but: 1) commit in master was related to my issue with absent Descriptor for plugin objects created from CLI callables. I defined

Re: Proposal: forbid direct commits to master for core

On 21/12/15 09:33, Oleg Nenashev wrote: > Slightly hijacking this topic: would it be worthwhile having a similar > rule (even if it's may not be technically enforceable) for creating new > plugins? > > > I'm +1 on it. My gut-feeling that there are misusages: forking of > demo-only

Re: Tool Installation (and confluence Labels)

Hi there, On 21/12/15 20:55, Gavin Mogan wrote: > I just saw at the bottom > of https://wiki.jenkins-ci.org/display/JENKINS/Tool+Auto-Installation > specifically the more tools needed section. Is there a label for this? > Is there a list of what labels automatically fill out what pages? Not

Re: Proposal: forbid direct commits to master for core

> > Slightly hijacking this topic: would it be worthwhile having a similar > rule (even if it's may not be technically enforceable) for creating new > plugins? > I'm +1 on it. My gut-feeling that there are misusages: forking of demo-only plugins, bad namings, etc. It's enforceable. We could

Re: Proposal: forbid direct commits to master for core

Oh, definitely! On Dec 21, 2015 8:39 AM, "Arnaud Héritier" wrote: > > > On Sun, Dec 20, 2015 at 6:22 PM, Andrew Bayer > wrote: > >> So, addressing a few aspects of this thread: >> >> - I'd strongly oppose ICLA/push permission revocation for pushing

Re: Proposal: forbid direct commits to master for core

On Sun, Dec 20, 2015 at 6:22 PM, Andrew Bayer wrote: > 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

subclasses of Serialization

Hi, I have sent a PR that removes dead code (https://github.com/jenkinsci/jenkins/pull/1957). Some of the suggested changes are to remove readResolve methods because the classes that contain those methods do not implement java.io.Serializable. XStream, as far as I know, uses the readResolve

InjectedTest failures due to class not found.

I was building a plugin with a very recent parent pom of 1.639 and running the InjectedTest fails: Tests in error: FailedTest.org.jvnet.hudson.test.JellyTestSuiteBuilder$JellyTestSuite » NoClassDefFound

nodes configuration

Hi, tiny question, looks that some time ago there was configuration changes, and nodes configuration is moved to jenkins_home/nodes/$nodename/config.xml great idea, hope that also views will go to views/$viewname/views... but the most important question, how can I migrate configuration? Should

Re: Proposal: forbid direct commits to master for core

A few years ago the Gerrit workflow process was proposed, which can enforce a workflow on specific branches. You can then have GitHub repos synchronised out-of-the-box. See for instance the OpenStack project: - Gerrit reviews: https://review.openstack.org -

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

Hi to everyone, I have created an open source tool called Walkmod for this purpose (link - http://www.walkmod.com). In fact, I executed Walkmod into Jenkins (core module) to remove dead code. This PR contains the results https://github.com/jenkinsci/jenkins/pull/1957. Walkmod allows you

Re: Jclouds openstack instance creation

It's a question to Jenkins-users mailing list. It's also a good practice to add plugin owners to Cc. суббота, 19 декабря 2015 г., 11:02:41 UTC+3 пользователь anoop negi написал: > > Hi, > I'm using Jclouds plugin to create openstack instance on the fly during > job build and terminate as job get

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

> On Dec 21, 2015, at 13:22, Raquel Pau Fernández wrote: > > 1) Ok, no problem, but I think that code style is really related with static > analysis tools, because these tool will be able to validate or fix your code > style. Found, according to wiki, checkstyle is also

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

I hope keep this thread as it named in topic and don’t touch static analysing. PS. You can’t blindly trust to static analysing results, they are only helpers and should never be used in autofix mode. Example of Serialisation fix attempt https://github.com/jenkinsci/jenkins/pull/1945

Re: Proposal: forbid direct commits to master for core

On Monday, December 21, 2015 at 2:58:34 AM UTC+3, Stephen Connolly wrote: > > If we are going to go down the road of forbidding direct committing to > master and forcing people to go through PRs (let's assume we can find a way > to let release commits go through) we'd need a better criteria

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

Sorry, but imho this PR kills code. Will be glad to hear why jenkins should add walkmod that i never saw in any projects instead of mass used checkstyle (this thread is about styling). Modified parts (Serializable, readResolve()) in PR reportable by FindBugs that is static analysing tool. > On

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

(in line) 2015-12-21 11:22 GMT+01:00 Raquel Pau Fernández : > 1) Ok, no problem, but I think that code style is really related with static > analysis tools, because these tool will be able to validate or fix your code > style. +1000. We need rules and guidelines, and

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

Thank you for your opinion, However, If you think is that this PR is not valid for the Serialization, I am creating a convention that automatically makes classes to implement Serializable if contains readResolve. In fact, the problem that walkmod address is autofixing issues that appear over

Re: Can axis have access to build/project information?

Well, before each matrix run rebuild(MatrixBuildExecution context) is called so you could get it there. On the configuration screen you should always have the stapler ancestors available as well. /B On Sat, Dec 19, 2015 at 12:41 AM, Gavin Mogan wrote: > I'm working on

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

1) Ok, no problem, but I think that code style is really related with static analysis tools, because these tool will be able to validate or fix your code style. 2) I understand that you need to validate exactly what are your conventions before setting them as part of your project. After that,

A richer global config for EnvInject?

Hi everyone, I wonder why the EnvInject plugin has lesser global options compared to the job ones. In job config, you can set a properties file, properties content or groovy script. In the global config, it's a properties file or nothing. Is there a reason for this? If there is no particular

Re: Proposal: forbid direct commits to master for core

Jenkins does not resolve around me. So I do not seek to try and make Jenkins community to jump to my timetable. all CloudBees employees know my time constraints anyway, so I do not feel the need to broadcast it in a public forum On Monday 21 December 2015, Kanstantsin Shautsou

Re: Proposal: forbid direct commits to master for core

The current IRC time slot is not compatible with my family. I normally try to ensure somebody who can attend is willing to represent my PoV when I know there is an issue I feel strongly about On Monday 21 December 2015, Kanstantsin Shautsou wrote: > > > On Monday,

Re: Proposal: forbid direct commits to master for core

What slots are suitable for you? Meeting time shift was discussed few times but nothing changed. > On Dec 21, 2015, at 14:58, Stephen Connolly > wrote: > > The current IRC time slot is not compatible with my family. I normally try to > ensure somebody who can

Re: subclasses of Serialization

Hi, Thank you for your response. My answers below: 1) Just checking the source code of the xstream (https://github.com/x-stream/xstream/blob/8ea8038f96c5638315d026d5884603c9ce6cebd3/xstream/src/java/com/thoughtworks/xstream/core/util/SerializationMembers.java) I could verify what you are

Re: Looking for a 'janitor' or 'sanity check' plugin for enterprise use cases

Performing an action when something is found in a build log has been on my todo list for the Build Failure Analyzer Plugin [1] for a long time. Given my current priorities I'll probably not get around to it in the foreseeable future, but as usual I'm open to pull requests ;) [1]

Re: subclasses of Serialization

On Monday 21 December 2015, Raquel Pau Fernández wrote: > Hi, > > I have sent a PR that removes dead code ( > https://github.com/jenkinsci/jenkins/pull/1957). Some of the suggested > changes are to remove readResolve methods because the classes that contain > those methods

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

XStream does not require use of the `Serializable` marker interface. -- 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: subclasses of Serialization

@Stephen: then wouldn't at least a PR to add a comment to the readResolve() like https://github.com/jenkinsci/jenkins/blob/master/core/src/main/java/hudson/model/ListView.java#L112 be beneficial both for the common knowledge and for you not to have to repeat yourself every few weeks? :-)