date:20170707

Re: Path environment variable not set by SimpleBuildWrapper.Context.env() on Windows slave

2017-07-07 Thread Oleg Nenashev

EnvInject Bug for it: https://issues.jenkins-ci.org/browse/JENKINS-26583
I have a plan to fix it, but right now it is not a top priority for me. The 
plugin is looking for adopters 

четверг, 6 июля 2017 г., 18:30:07 UTC+2 пользователь 15 knots написал:
>
> 2017-07-06 13:45 GMT+02:00 15 knots : 
> > 2017-07-06 0:27 GMT+02:00 Jesse Glick  >: 
> >> On Wed, Jul 5, 2017 at 3:43 PM, Martin Weber  > wrote: 
> > ... 
> >>> Maybe one of the plugins installed on my production Jenkins interferes 
> here? 
> >> 
> >> Conceivable. 
> > 
> > Found the culprit: Environment Injector Plugin 
> > Should I file a bug report? 
>
> This is what happens with SimpleBuildWrapper and the Environment 
> Injector Plugin installed: 
> - CommandInterpreter.perfom() calls AbstractBuild.getEnvironment(). 
> - getEnvironment() assembles all values from its buildEnvironments 
> list -- one of these is SimpleBuildWrapper.EnvironmentWrapper. which 
> inserts my extended value for $Path. Fine. 
> - After that, EnvironmentContributingActions inject their variables. 
> One of them is an EnvInjectPluginAction, it overwrites the $Path 
> variable. 
>
> This EnvironmentContributingAction object will overwrite nearly every 
> variable (Path, JENKINS_URL, ALLUSERSPROFILE, PROCESSOR_ARCHITECTURE, 
> ...). 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/7dfd9eae-0f27-4295-b1b6-e84b97023e58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Proposal] Making all things Stapler more declarative

2017-07-07 Thread Stephen Connolly

Ok, so that people can see code rather than just yapping on the M-L (and
given that we seem to be OK with the annotation names)

https://github.com/stapler/stapler/pull/121

Is where I am working on this proposal. We can continue the discussion in
either place as appropriate (general comments here, specific comments on
specific details of the code in the PR)

On 7 July 2017 at 03:06, Stephen Connolly 
wrote:

> Yes I was thinking that a custom javadoc handler would be useful.
> Especially as there are inheritance of facets and fragments that we'd want
> to see documented correctly.
>
> On 7 July 2017 at 02:37, Robert Sandell  wrote:
>
>> I agree with Stephen here; adding methods seems risky and could break
>> existing plugins, at least in a backwards compat sense.
>>
>> But I at the same time do like the idea of getting javadoc for the facets
>> and fragments. So can we get both somehow?
>> E.g. if there is a @StaplerFacet("login") or @StaplerFragment("main") there
>> should be a corresponding
>>
>> @facet login the login page.
>> @fragment main add this to change the main part of the configuration page.
>>
>> in the javadoc of the class?
>>
>> /B
>>
>> 2017-07-06 13:16 GMT+02:00 Stephen Connolly <
>> stephen.alan.conno...@gmail.com>:
>>
>>>
>>>
>>> On 5 July 2017 at 18:10, Kohsuke Kawaguchi  wrote:
>>>
 FWIW, I've already discussed this offline with Stephen and I'm
 generally +1.

 One suggestion I had for him is to consider using a Java method
 definition instead of @StaplerFacet and @StaplerFragment. That is, instead
 of this:

 @StaplerFacets({
   @StaplerFacet("index"),
   @StaplerFacet("config")
 })
 @StaplerFragments({
   @StaplerFragment("main"),
   @StaplerFragment("side-panel"),
   @StaplerFragment(value="tasks",optional=true)
 })
 public class Widget { ... }

 Consider that:

 public class Widget {
 @StaplerFacet protected void index() {}
 @StaplerFacet protected void config() {}

 @StaplerFragment protected abstract void main();
 @StaplerFragment("side-panel") protected abstract void sidepanel();
 @StaplerFragment protected void tasks();
 }


>>> Well at least this is a better explanation than you gave me verbally ;-)
>>>
>>>
 I liked this better because ...

- It fits with the original design thinking behind Stapler, which
is that views are like methods. Their inheritance and override semantics
are all modeled after methods.
- It avoids a long list of @StaplerFragment/@StaplerFacet at the
top of the class declaration. We have some objects in the core that has
quite a few views.

 So let's see:
>>>
>>> $ ( cd core/src/main/resources ; find . -name \*.jelly -exec dirname {}
>>> \; ; find . -name \*.groovy -exec dirname {} \; ) | sort | uniq -c | grep
>>> -v ./lib/ | sort -n | tail -n 10
>>>7 ./hudson/model/AbstractProject
>>>7 ./hudson/slaves/SlaveComputer
>>>7 ./jenkins/install/SetupWizard
>>>9 ./hudson/model/Run
>>>   11 ./hudson/PluginManager
>>>   11 ./hudson/security/HudsonPrivateSecurityRealm
>>>   12 ./hudson/model/Job
>>>   13 ./hudson/model/View
>>>   14 ./hudson/model/Computer
>>>   25 ./jenkins/model/Jenkins
>>>
>>> So there are not altogether too many classes in Jenkins having lots of
>>> fragments / facets
>>>
>>> I think an argument based on a couple of really big classes like Jenkins
>>> having 25 lines of
>>>
>>> @StaplerObject
>>> @StaplerFacet("_restart")
>>> @StaplerFacet("_safeRestart")
>>> @StaplerFacet("_script")
>>> @StaplerFacet("_scriptText")
>>> @StaplerFacet("accessDenied")
>>> @StaplerFacet("configure")
>>> @StaplerFacet("configureExecutors")
>>> @StaplerFacet("fingerprintCheck")
>>> @StaplerFacet("legend")
>>> @StaplerFacet("load-statistics")
>>> @StaplerFacet("login")
>>> @StaplerFacet("loginError")
>>> @StaplerFacet("manag_")
>>> @StaplerFacet("manage")
>>> @StaplerFacet("newView")
>>> @StaplerFacet("noPrincipal")
>>> @StaplerFacet("oops")
>>> @StaplerFacet("opensearch.xml")
>>> @StaplerFacet("projectRelationship-help")
>>> @StaplerFacet("projectRelationship")
>>> @StaplerFacet("systemInfo")
>>> @StaplerFacet("threadDump")
>>> @StaplerFragment("_api")
>>> @StaplerFragment("downgrade")
>>> @StaplerFragment("sidepanel")
>>> public class Jenkins {
>>>   ...
>>> }
>>>
>>> compared with
>>>
>>> @StaplerObject
>>> public class Jenkins {
>>>   @StaplerFacet protected void _restart() {}
>>>   @StaplerFacet protected void _safeRestart() {}
>>>   @StaplerFacet protected void _script() {}
>>>   @StaplerFacet protected void _scriptText() {}
>>>   @StaplerFacet protected void accessDenied() {}
>>>   @StaplerFacet protected void configure() {}
>>>   @StaplerFacet protected void configureExecutors() {}
>>>   @StaplerFacet protected void fingerprintCheck() {}
>>>   @StaplerFacet protected

Plugin maintenance: slack-plugin

2017-07-07 Thread Gustavo Maia

Hi. I've been talking with Sam Gleske about helping to maintain the
slack-plugin and he asked me to go ahead and submit the request here.
Here's the main conversation:
https://github.com/jenkinsci/slack-plugin/pull/324
I've @ mentioned Kurt on the PR as well, but haven't got a response yet.
Kurt, is it ok if I step up and try to help?

Here's my info:
Github ID: gurumaia
Jenkins infra account: gurumaia

Thanks

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CAC0tQF2ysa%2B0Tx2wWjkhi%2Bf59auWfO_GOHPqKkEycSpwT-UKUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: jenkins jpi plugin problems

2017-07-07 Thread Robert Sandell

Not sure how the gradle plugin works, but createMavenProject was removed
from the jenkins test harness some time ago since MavenProject wasn't part
of core any more.

you should use createProject(MavenProject.class) instead.

/B

2017-07-07 14:36 GMT+02:00 Jeremy Marshall :

> I upgraded my groovy plugin to jpi 0.22.0 but now I get a strange error in
> the tests
>
> ```
> org.jenkinsci.plugins.GroovyScriptMESSpec > two axis success script FAILED
> groovy.lang.MissingMethodException: No signature of method:
> org.jvnet.hudson.test.JenkinsRule.createMatrixProject() is applicable for
> argument types: () values: []
> at org.jenkinsci.plugins.GroovyScriptMESSpec.configure(
> GroovyScriptMESSpec.groovy:26)
> at org.jenkinsci.plugins.GroovyScriptMESSpec.two axis success
> script(GroovyScriptMESSpec.groovy:84)
> ```
>
> As far as I can tell the method is there. Am I missing a test plugin?  Its
> all very odd
>
> repo https://github.com/jenkinsci/matrix-groovy-execution-strategy-plugin/
> tree/groovy3.2.1
>
> I tried it with the very latest Java 8 and its using a gradlew wrapper
>
> Thanks in advance
> Jeremy
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/jenkinsci-dev/14be113f-5fc9-497f-969b-f0769fc30c7c%
> 40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Robert Sandell
*Software Engineer*
*CloudBees Inc.*

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS03KiJESADoqUGqEV0oNz_zZHMRVr7GfmtY2qTa1-sJLA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

jenkins jpi plugin problems

2017-07-07 Thread Jeremy Marshall

I upgraded my groovy plugin to jpi 0.22.0 but now I get a strange error in 
the tests

```
org.jenkinsci.plugins.GroovyScriptMESSpec > two axis success script FAILED
groovy.lang.MissingMethodException: No signature of method: 
org.jvnet.hudson.test.JenkinsRule.createMatrixProject() is applicable for 
argument types: () values: []
at 
org.jenkinsci.plugins.GroovyScriptMESSpec.configure(GroovyScriptMESSpec.groovy:26)
at org.jenkinsci.plugins.GroovyScriptMESSpec.two axis success 
script(GroovyScriptMESSpec.groovy:84)
```

As far as I can tell the method is there. Am I missing a test plugin?  Its 
all very odd

repo 
https://github.com/jenkinsci/matrix-groovy-execution-strategy-plugin/tree/groovy3.2.1

I tried it with the very latest Java 8 and its using a gradlew wrapper

Thanks in advance
Jeremy

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/14be113f-5fc9-497f-969b-f0769fc30c7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Proposal] Making all things Stapler more declarative

2017-07-07 Thread Stephen Connolly

Yes I was thinking that a custom javadoc handler would be useful.
Especially as there are inheritance of facets and fragments that we'd want
to see documented correctly.

On 7 July 2017 at 02:37, Robert Sandell  wrote:

> I agree with Stephen here; adding methods seems risky and could break
> existing plugins, at least in a backwards compat sense.
>
> But I at the same time do like the idea of getting javadoc for the facets
> and fragments. So can we get both somehow?
> E.g. if there is a @StaplerFacet("login") or @StaplerFragment("main") there
> should be a corresponding
>
> @facet login the login page.
> @fragment main add this to change the main part of the configuration page.
>
> in the javadoc of the class?
>
> /B
>
> 2017-07-06 13:16 GMT+02:00 Stephen Connolly  com>:
>
>>
>>
>> On 5 July 2017 at 18:10, Kohsuke Kawaguchi  wrote:
>>
>>> FWIW, I've already discussed this offline with Stephen and I'm
>>> generally +1.
>>>
>>> One suggestion I had for him is to consider using a Java method
>>> definition instead of @StaplerFacet and @StaplerFragment. That is, instead
>>> of this:
>>>
>>> @StaplerFacets({
>>>   @StaplerFacet("index"),
>>>   @StaplerFacet("config")
>>> })
>>> @StaplerFragments({
>>>   @StaplerFragment("main"),
>>>   @StaplerFragment("side-panel"),
>>>   @StaplerFragment(value="tasks",optional=true)
>>> })
>>> public class Widget { ... }
>>>
>>> Consider that:
>>>
>>> public class Widget {
>>> @StaplerFacet protected void index() {}
>>> @StaplerFacet protected void config() {}
>>>
>>> @StaplerFragment protected abstract void main();
>>> @StaplerFragment("side-panel") protected abstract void sidepanel();
>>> @StaplerFragment protected void tasks();
>>> }
>>>
>>>
>> Well at least this is a better explanation than you gave me verbally ;-)
>>
>>
>>> I liked this better because ...
>>>
>>>- It fits with the original design thinking behind Stapler, which is
>>>that views are like methods. Their inheritance and override semantics are
>>>all modeled after methods.
>>>- It avoids a long list of @StaplerFragment/@StaplerFacet at the top
>>>of the class declaration. We have some objects in the core that has 
>>> quite a
>>>few views.
>>>
>>> So let's see:
>>
>> $ ( cd core/src/main/resources ; find . -name \*.jelly -exec dirname {}
>> \; ; find . -name \*.groovy -exec dirname {} \; ) | sort | uniq -c | grep
>> -v ./lib/ | sort -n | tail -n 10
>>7 ./hudson/model/AbstractProject
>>7 ./hudson/slaves/SlaveComputer
>>7 ./jenkins/install/SetupWizard
>>9 ./hudson/model/Run
>>   11 ./hudson/PluginManager
>>   11 ./hudson/security/HudsonPrivateSecurityRealm
>>   12 ./hudson/model/Job
>>   13 ./hudson/model/View
>>   14 ./hudson/model/Computer
>>   25 ./jenkins/model/Jenkins
>>
>> So there are not altogether too many classes in Jenkins having lots of
>> fragments / facets
>>
>> I think an argument based on a couple of really big classes like Jenkins
>> having 25 lines of
>>
>> @StaplerObject
>> @StaplerFacet("_restart")
>> @StaplerFacet("_safeRestart")
>> @StaplerFacet("_script")
>> @StaplerFacet("_scriptText")
>> @StaplerFacet("accessDenied")
>> @StaplerFacet("configure")
>> @StaplerFacet("configureExecutors")
>> @StaplerFacet("fingerprintCheck")
>> @StaplerFacet("legend")
>> @StaplerFacet("load-statistics")
>> @StaplerFacet("login")
>> @StaplerFacet("loginError")
>> @StaplerFacet("manag_")
>> @StaplerFacet("manage")
>> @StaplerFacet("newView")
>> @StaplerFacet("noPrincipal")
>> @StaplerFacet("oops")
>> @StaplerFacet("opensearch.xml")
>> @StaplerFacet("projectRelationship-help")
>> @StaplerFacet("projectRelationship")
>> @StaplerFacet("systemInfo")
>> @StaplerFacet("threadDump")
>> @StaplerFragment("_api")
>> @StaplerFragment("downgrade")
>> @StaplerFragment("sidepanel")
>> public class Jenkins {
>>   ...
>> }
>>
>> compared with
>>
>> @StaplerObject
>> public class Jenkins {
>>   @StaplerFacet protected void _restart() {}
>>   @StaplerFacet protected void _safeRestart() {}
>>   @StaplerFacet protected void _script() {}
>>   @StaplerFacet protected void _scriptText() {}
>>   @StaplerFacet protected void accessDenied() {}
>>   @StaplerFacet protected void configure() {}
>>   @StaplerFacet protected void configureExecutors() {}
>>   @StaplerFacet protected void fingerprintCheck() {}
>>   @StaplerFacet protected void legend() {}
>>   @StaplerFacet @StaplerPath("load-statistics") protected void
>> loadStatistics() {}
>>   @StaplerFacet protected void login() {}
>>   @StaplerFacet protected void loginError() {}
>>   @StaplerFacet protected void manag_() {}
>>   @StaplerFacet protected void manage() {}
>>   @StaplerFacet protected void newView() {}
>>   @StaplerFacet protected void noPrincipal() {}
>>   @StaplerFacet protected void oops() {}
>>   @StaplerFacet @StaplerPath("opensearch.xml") protected void
>> opensearchXml() {}
>>   @StaplerFacet @StaplerPath("projectRelationship-help")

ATTN: Plugin developers who use IntelliJ

2017-07-07 Thread Stephen Connolly

Please vote for https://youtrack.jetbrains.com/issue/IDEA-175538 if you
want to be able to plugin run unit tests from IntelliJ using recent
versions of the plugin parent.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMz27gyi0DXmACTKp9UPaRweqPdjWmPHCkAkYaDgH%3Dsffg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Proposal] Making all things Stapler more declarative

2017-07-07 Thread Robert Sandell

I agree with Stephen here; adding methods seems risky and could break
existing plugins, at least in a backwards compat sense.

But I at the same time do like the idea of getting javadoc for the facets
and fragments. So can we get both somehow?
E.g. if there is a @StaplerFacet("login") or @StaplerFragment("main") there
should be a corresponding

@facet login the login page.
@fragment main add this to change the main part of the configuration page.

in the javadoc of the class?

/B

2017-07-06 13:16 GMT+02:00 Stephen Connolly :

>
>
> On 5 July 2017 at 18:10, Kohsuke Kawaguchi  wrote:
>
>> FWIW, I've already discussed this offline with Stephen and I'm
>> generally +1.
>>
>> One suggestion I had for him is to consider using a Java method
>> definition instead of @StaplerFacet and @StaplerFragment. That is, instead
>> of this:
>>
>> @StaplerFacets({
>>   @StaplerFacet("index"),
>>   @StaplerFacet("config")
>> })
>> @StaplerFragments({
>>   @StaplerFragment("main"),
>>   @StaplerFragment("side-panel"),
>>   @StaplerFragment(value="tasks",optional=true)
>> })
>> public class Widget { ... }
>>
>> Consider that:
>>
>> public class Widget {
>> @StaplerFacet protected void index() {}
>> @StaplerFacet protected void config() {}
>>
>> @StaplerFragment protected abstract void main();
>> @StaplerFragment("side-panel") protected abstract void sidepanel();
>> @StaplerFragment protected void tasks();
>> }
>>
>>
> Well at least this is a better explanation than you gave me verbally ;-)
>
>
>> I liked this better because ...
>>
>>- It fits with the original design thinking behind Stapler, which is
>>that views are like methods. Their inheritance and override semantics are
>>all modeled after methods.
>>- It avoids a long list of @StaplerFragment/@StaplerFacet at the top
>>of the class declaration. We have some objects in the core that has quite 
>> a
>>few views.
>>
>> So let's see:
>
> $ ( cd core/src/main/resources ; find . -name \*.jelly -exec dirname {} \;
> ; find . -name \*.groovy -exec dirname {} \; ) | sort | uniq -c | grep -v
> ./lib/ | sort -n | tail -n 10
>7 ./hudson/model/AbstractProject
>7 ./hudson/slaves/SlaveComputer
>7 ./jenkins/install/SetupWizard
>9 ./hudson/model/Run
>   11 ./hudson/PluginManager
>   11 ./hudson/security/HudsonPrivateSecurityRealm
>   12 ./hudson/model/Job
>   13 ./hudson/model/View
>   14 ./hudson/model/Computer
>   25 ./jenkins/model/Jenkins
>
> So there are not altogether too many classes in Jenkins having lots of
> fragments / facets
>
> I think an argument based on a couple of really big classes like Jenkins
> having 25 lines of
>
> @StaplerObject
> @StaplerFacet("_restart")
> @StaplerFacet("_safeRestart")
> @StaplerFacet("_script")
> @StaplerFacet("_scriptText")
> @StaplerFacet("accessDenied")
> @StaplerFacet("configure")
> @StaplerFacet("configureExecutors")
> @StaplerFacet("fingerprintCheck")
> @StaplerFacet("legend")
> @StaplerFacet("load-statistics")
> @StaplerFacet("login")
> @StaplerFacet("loginError")
> @StaplerFacet("manag_")
> @StaplerFacet("manage")
> @StaplerFacet("newView")
> @StaplerFacet("noPrincipal")
> @StaplerFacet("oops")
> @StaplerFacet("opensearch.xml")
> @StaplerFacet("projectRelationship-help")
> @StaplerFacet("projectRelationship")
> @StaplerFacet("systemInfo")
> @StaplerFacet("threadDump")
> @StaplerFragment("_api")
> @StaplerFragment("downgrade")
> @StaplerFragment("sidepanel")
> public class Jenkins {
>   ...
> }
>
> compared with
>
> @StaplerObject
> public class Jenkins {
>   @StaplerFacet protected void _restart() {}
>   @StaplerFacet protected void _safeRestart() {}
>   @StaplerFacet protected void _script() {}
>   @StaplerFacet protected void _scriptText() {}
>   @StaplerFacet protected void accessDenied() {}
>   @StaplerFacet protected void configure() {}
>   @StaplerFacet protected void configureExecutors() {}
>   @StaplerFacet protected void fingerprintCheck() {}
>   @StaplerFacet protected void legend() {}
>   @StaplerFacet @StaplerPath("load-statistics") protected void
> loadStatistics() {}
>   @StaplerFacet protected void login() {}
>   @StaplerFacet protected void loginError() {}
>   @StaplerFacet protected void manag_() {}
>   @StaplerFacet protected void manage() {}
>   @StaplerFacet protected void newView() {}
>   @StaplerFacet protected void noPrincipal() {}
>   @StaplerFacet protected void oops() {}
>   @StaplerFacet @StaplerPath("opensearch.xml") protected void
> opensearchXml() {}
>   @StaplerFacet @StaplerPath("projectRelationship-help") protected void
> projectRelationshipHelp()
>   @StaplerFacet protected void projectRelationship() {}
>   @StaplerFacet protected void systemInfo() {}
>   @StaplerFacet protected void threadDump() {}
>   @StaplerFragment protected void _api() {}
>   @StaplerFragment protected void downgrade() {}
>   @StaplerFragment protected void sidepanel() {}
>   ...
> }
>
> just to get the javadoc comments

Re: Path environment variable not set by SimpleBuildWrapper.Context.env() on Windows slave

Re: [Proposal] Making all things Stapler more declarative

Plugin maintenance: slack-plugin

Re: jenkins jpi plugin problems

jenkins jpi plugin problems

Re: [Proposal] Making all things Stapler more declarative

ATTN: Plugin developers who use IntelliJ

Re: [Proposal] Making all things Stapler more declarative

8 matches

Site Navigation

Mail list logo

Footer information