Pull request to seleniumhq-plugin
Hi developers. I send following pull request to seleniumhq-plugin, But it is no response. https://github.com/jenkinsci/seleniumhq-plugin/pull/2 Please review someone and merge or give me committ access. My Github account is hayato1980 regards -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
On Thursday, 3 October 2013 20:37:27 UTC+1, Stephen Connolly wrote: On Thursday, 3 October 2013, teilo wrote: Hi Stephen, Is the literate plugin going to be the only route into the multi-branch job? I am sure somebody may use the branch api to implement other types... I have a freestyle multi branch but there is just too many build differences for it to be useful and a ton of UI glitches because plugins assume they are owned by ? extends Job Reason being for enterprisy software we need to enforce things in a build/release so I can't let my users run abitrary maven invocations that change the build (and make it unreproduceable). e.g. they should not be able to change the settings by using mvn -s $workspace/some_setting_with_external_repo.xml -DskipTests=true But they can just change the pom to skip tests anyway... You have a false sense of security... That was a bit of a bad example - but actually if they want to skip tests in the POM then that is 100% ok - as we know that the tests were not run on a specific build. And if they want to use a different settings... Invoker and an alternative pom file. But you are assuming my maven enforcer rules etc. are the only line of defence here. The MRM can also play an important part :-) Besides that can you configure things that are not reporters? e.g. wipe out workspace, always checkout a fresh copy, enable a release plugin... Plus you can just watch what shit they are committing... You need to do that with the poms anyway No I can't (and actually I don't). If I could do that then we wouldn't need the Template plugin as I could watch all Jenkins job creation :-) You are correct in that there is a little bit of an arms race going on - but most of this is not actively trying to create non-repeatable builds - it's just people not always thinking things through and the system can probably automatically pick up 95+% of that. There are several thousand projects+branches - it would take a full time person to watch all of that - you could say that this could be somewhat automated - but even that has human overhead to setup these jobs when new projects are added, maintain mapping of project/branch to user+manager mapping etc... but at the same time its nice that you just branch and get a job (from say a job that's created from some kind of template, and that should allow the user to specify the properties exposed by that template only...) (you haven't yet beaten my addiction to the maven job type...) I'm not done... There are more tricks up my sleeve -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
On 4 October 2013 08:42, teilo teilo+goo...@teilo.net wrote: On Thursday, 3 October 2013 20:37:27 UTC+1, Stephen Connolly wrote: On Thursday, 3 October 2013, teilo wrote: Hi Stephen, Is the literate plugin going to be the only route into the multi-branch job? I am sure somebody may use the branch api to implement other types... I have a freestyle multi branch but there is just too many build differences for it to be useful and a ton of UI glitches because plugins assume they are owned by ? extends Job Reason being for enterprisy software we need to enforce things in a build/release so I can't let my users run abitrary maven invocations that change the build (and make it unreproduceable). e.g. they should not be able to change the settings by using mvn -s $workspace/some_setting_with_**external_repo.xml -DskipTests=true But they can just change the pom to skip tests anyway... You have a false sense of security... That was a bit of a bad example - but actually if they want to skip tests in the POM then that is 100% ok - as we know that the tests were not run on a specific build. And if they want to use a different settings... Invoker and an alternative pom file. But you are assuming my maven enforcer rules etc. are the only line of defence here. The MRM can also play an important part :-) Yes which is why I have another trick up my sleeve as part of my make maven better on jenkins and get rid of the ugly aberration that is the Maven project type plan... Besides that can you configure things that are not reporters? e.g. wipe out workspace, That is something that does not make sense in SCM, so that is configured from Jenkins always checkout a fresh copy, As for wipe out workspace enable a release plugin... That is awaiting the tasks support that KK has said he will help write... basically the way this will work is you will enable a branch property that defines the promotion tasks to support for that branch... you will specify the heading keyword to identify the steps for that task and the environment to run the task on... so to enable releasing from Maven you would do something like # To make a release mvn release:prepare release:perform -B and then in jenkins you just tell jenkins that, e.g. the master branch has a release task with the keyword release in the heading Thus you will only be able to cut releases from the master branch. Plus you can just watch what shit they are committing... You need to do that with the poms anyway No I can't (and actually I don't). If I could do that then we wouldn't need the Template plugin as I could watch all Jenkins job creation :-) You are correct in that there is a little bit of an arms race going on - but most of this is not actively trying to create non-repeatable builds - it's just people not always thinking things through and the system can probably automatically pick up 95+% of that. What is a non-repeatable build in this context? The SCM revision will still be buildable if Jenkins built it once before. Or is it that you are worries about people injecting alternative settings.xml in the build command? We are nowhere near it works on my machine land, though I suspect you will need to see my maven improvement plans before you fully believe me There are several thousand projects+branches - it would take a full time person to watch all of that - you could say that this could be somewhat automated - but even that has human overhead to setup these jobs when new projects are added, maintain mapping of project/branch to user+manager mapping etc... but at the same time its nice that you just branch and get a job (from say a job that's created from some kind of template, and that should allow the user to specify the properties exposed by that template only...) (you haven't yet beaten my addiction to the maven job type...) I'm not done... There are more tricks up my sleeve -- 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 options, visit https://groups.google.com/groups/opt_out. -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Adventurous users wanted! Literate multi-branch project type
But you are assuming my maven enforcer rules etc. are the only line of defence here. The MRM can also play an important part :-) Yes which is why I have another trick up my sleeve as part of my make maven better on jenkins and get rid of the ugly aberration that is the Maven project type plan... I guess that is the trick I have been waiting for for a while... You've made a lot out of this - I'm expecting the moon on a stick solution :-) Besides that can you configure things that are not reporters? e.g. wipe out workspace, That is something that does not make sense in SCM, so that is configured from Jenkins always checkout a fresh copy, As for wipe out workspace enable a release plugin... That is awaiting the tasks support that KK has said he will help write... basically the way this will work is you will enable a branch property that defines the promotion tasks to support for that branch... you will specify the heading keyword to identify the steps for that task and the environment to run the task on... so to enable releasing from Maven you would do something like # To make a release mvn release:prepare release:perform -B and then in jenkins you just tell jenkins that, e.g. the master branch has a release task with the keyword release in the heading Thus you will only be able to cut releases from the master branch. Plus you can just watch what shit they are committing... You need to do that with the poms anyway No I can't (and actually I don't). If I could do that then we wouldn't need the Template plugin as I could watch all Jenkins job creation :-) You are correct in that there is a little bit of an arms race going on - but most of this is not actively trying to create non-repeatable builds - it's just people not always thinking things through and the system can probably automatically pick up 95+% of that. What is a non-repeatable build in this context? I should have also included traceable so replace with non-repeatable non-traceable it is a build that we can't trace back to the source code, or for which if we checked it out onto a clean machine setup with the correct OS/java/maven could not run mvn install and have identical binaries in the future (we record the JDK version and maven version used to build as well as the build host which will tell us the OS). Obviously there could be cases where some bad unit tests have some dates in them and these could fail if time has moved on - but they should be easily identifiable) The SCM revision will still be buildable if Jenkins built it once before. Not true. If you change the settings, or disable enforcer rules etc you can add a external repository. As we all know some of these external maven repositories have a habit of being here one day and gone the next. That is why we force everything via our MRM which will keep every single release it downloads forever to handle just this case. There are also times when the upstream repo replaces a release version (even sonatype has let this happen on their hosted repositories in the past!) So just because you built something today doesn't mean that the dependencies/plugins you need to build it tomorrow will still be around and at the same place. There are also occasions where someone sets a release version on trunk and would let jenkins mvn deploy - this could be ok as far as the MRM is concerned yet there is no tag in SCM. As there is no tag there it may be on a branch that is a personal branch or a throwaway branch that can be deleted (e.g. you allow deleteion of personal/** but not releases/** - but don;t allow deletion/redefinition of tags) Or is it that you are worries about people injecting alternative settings.xml in the build command? That would be one of my big concerns with this. (Sonar being another root of all evil..) this setup would also allow users to have jars in SCM that they mvn install:installFile... (with maven2 you could have done this with system scope - but the enforcer rules should have prevented this). The above isn't about reproduceability - but to make sure that people don;t check in jars to SCM - and that they go via the 3rd party reposiroty and have their licence/useage tracked. All our main source build jobs use the same template that allows you to specify the following, 1) source location 2) users to email 3) java version 4a) maven version 4b) number of threads (-T...) 5) If you want any findbugs violations to mark the build as unstable 6) if you want any checkstyle violations to mark the build as unstable 7) slave restriction With just that you have a whole host of plugins configured - and just managed. You get reports even if you choose to ignore them so the commands to run are (for a ommit build) always the same mvn install checkstyle:checkstyle findbugs:findbugs, and it prevents you from doing a lot of stuff like adding
Re: Adventurous users wanted! Literate multi-branch project type
On 4 October 2013 09:39, teilo teilo+goo...@teilo.net wrote: But you are assuming my maven enforcer rules etc. are the only line of defence here. The MRM can also play an important part :-) Yes which is why I have another trick up my sleeve as part of my make maven better on jenkins and get rid of the ugly aberration that is the Maven project type plan... I guess that is the trick I have been waiting for for a while... You've made a lot out of this - I'm expecting the moon on a stick solution :-) Besides that can you configure things that are not reporters? e.g. wipe out workspace, That is something that does not make sense in SCM, so that is configured from Jenkins always checkout a fresh copy, As for wipe out workspace enable a release plugin... That is awaiting the tasks support that KK has said he will help write... basically the way this will work is you will enable a branch property that defines the promotion tasks to support for that branch... you will specify the heading keyword to identify the steps for that task and the environment to run the task on... so to enable releasing from Maven you would do something like # To make a release mvn release:prepare release:perform -B and then in jenkins you just tell jenkins that, e.g. the master branch has a release task with the keyword release in the heading Thus you will only be able to cut releases from the master branch. Plus you can just watch what shit they are committing... You need to do that with the poms anyway No I can't (and actually I don't). If I could do that then we wouldn't need the Template plugin as I could watch all Jenkins job creation :-) You are correct in that there is a little bit of an arms race going on - but most of this is not actively trying to create non-repeatable builds - it's just people not always thinking things through and the system can probably automatically pick up 95+% of that. What is a non-repeatable build in this context? I should have also included traceable so replace with non-repeatable non-traceable it is a build that we can't trace back to the source code, or for which if we checked it out onto a clean machine setup with the correct OS/java/maven could not run mvn install and have identical binaries in the future (we record the JDK version and maven version used to build as well as the build host which will tell us the OS). Obviously there could be cases where some bad unit tests have some dates in them and these could fail if time has moved on - but they should be easily identifiable) The SCM revision will still be buildable if Jenkins built it once before. Not true. If you change the settings, or disable enforcer rules etc you can add a external repository. As we all know some of these external maven repositories have a habit of being here one day and gone the next. That is why we force everything via our MRM which will keep every single release it downloads forever to handle just this case. There are also times when the upstream repo replaces a release version (even sonatype has let this happen on their hosted repositories in the past!) So just because you built something today doesn't mean that the dependencies/plugins you need to build it tomorrow will still be around and at the same place. There are also occasions where someone sets a release version on trunk and would let jenkins mvn deploy - this could be ok as far as the MRM is concerned yet there is no tag in SCM. As there is no tag there it may be on a branch that is a personal branch or a throwaway branch that can be deleted (e.g. you allow deleteion of personal/** but not releases/** - but don;t allow deletion/redefinition of tags) Or is it that you are worries about people injecting alternative settings.xml in the build command? That would be one of my big concerns with this. (Sonar being another root of all evil..) this setup would also allow users to have jars in SCM that they mvn install:installFile... (with maven2 you could have done this with system scope - but the enforcer rules should have prevented this). The above isn't about reproduceability - but to make sure that people don;t check in jars to SCM - and that they go via the 3rd party reposiroty and have their licence/useage tracked. All our main source build jobs use the same template that allows you to specify the following, 1) source location 2) users to email 3) java version 4a) maven version 4b) number of threads (-T...) 5) If you want any findbugs violations to mark the build as unstable 6) if you want any checkstyle violations to mark the build as unstable 7) slave restriction With just that you have a whole host of plugins configured - and just managed. You get reports even if you choose to ignore them so the commands to run are (for a ommit build) always the same mvn install checkstyle:checkstyle findbugs:findbugs, and it
Re: Adventurous users wanted! Literate multi-branch project type
I think the idea is great and can see this being fantastic for open source, or where you have a smaller company/team where you can check every commit to the build settings, I'm just not sure I could use it in an enterprise without being bitten by its ultimate flexibility (which is one reason why we use templates - but that gets us a plethora of jobs for the dozens of branches in each project!) Oh way cool you've just given me an idea for another enterprise plugin: multi-branch-templates plugin That should be easy... and because it's templates we don't have the UI glitches we see with my (currently closed source) free-style multi-branch plugin https://rm.cloudbees.com/issues/2111 That should make you happy... now just to convince Harpreet to put it on the backlog... feel free to file a ZD ;-) Raised ZD#13606 -- 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 options, visit https://groups.google.com/groups/opt_out.
[ANN] SSH Slaves 1.3
I found a number of bugs with the upgrade logic for handling pre-credentials integration to post-credentials integration. Version 1.3 of the SSH Slaves plugin should be *much* better at upgrading, and should identify and consolidate duplicate keys correctly (it was previously failing to pick up matches that differed in whitespace, etc) This version needs credentials 1.8.3 and ssh-credentials 1.5.1 (but should be ok with any of the credentials 1.7+ and ssh-credentials 1.4+ or to put it another way, if you forget to upgrade them your instance should not blow up, however you are *strongly* recommended to upgrade them anyway, e.g. ssh-credentials has some logic to help repair previously borked upgrade attempts) -Stephen -- 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 options, visit https://groups.google.com/groups/opt_out.
Repository URL to use for deployment
Hello, I see that [1] still refers to the Nexus [2] instance.for release deployment. I just had an unrelated releasing issue because port 8081 is not allowed from work. For some time now, Artifactory [3] has been set up to be used instead of Nexus (at least for public consumption). In documentation however, it there are still references to the Nexus urls here and there. I guess that what gets deployed on Nexus gets replicated to Artifactory which serves as reference, so for consistency, wouldn't it be better to deploy straight to Artifactory [4] ? Vincent [1] https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins [2] http://maven.jenkins-ci.org:8081/content/repositories/releases/ [3] http://repo.jenkins-ci.org [4] http://repo.jenkins-ci.org/releases -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Backporting 1.509.4 complete
We have https://issues.jenkins-ci.org/browse/JENKINS-15935 in this, which *may* have caused https://issues.jenkins-ci.org/browse/JENKINS-19352 Can someone confirm (or disprove) that JENKINS-19352 is observable in the LTS branch? I'll try to find some time this weekend to confirm myself. cheers Kutzi Am 03.10.2013 14:46, schrieb oliver gondža: Hi, I have finished backporting issues for 1.509.4. On governance meeting, we agreed that this is the very last minor release based on 1.509. We have 5 blockers and 8 critical fixes backported, 35 issues in total[1]. All 4 issues rejected from 1.509.3 will be present in 1.509.4. Kohsuke, please post RC. [1] https://issues.jenkins-ci.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+10172+AND+labels+%3D+%221.509.4-fixed%22 -- oliver -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: @DataBoundSetter
How will the object know that Stapler has completed calling DataBoundSetters
(that all configuration data has been applied)?
- Original Message -
From: jenkinsci-dev@googlegroups.com
To: jenkinsci-dev@googlegroups.com
At: Oct 4 2013 00:38:55
great,
so next step is to be able to directly annotate fields à la hibernate :)
class Foo {
@DataBound
int a,b,c,d;
}
2013/10/4 Kohsuke Kawaguchi k...@kohsuke.org
Today, many complex plugins suffer from a massive constructor annotated with
@DataBoundConstructor.
This is because the form data-binding requires that all the parameters passed
in through the constructor. See xcode plugin [1] for an example of this. The
situation was worse with plugins that are used by other plugins, which needed
to preserve ever-increasing list of constructors to remain backward compatible.
Starting Jenkins 1.535, this problem is no more. Stapler can not only look for
@DataBoundConstructor, but it'll also perform setter injection on methods
annotated with @DataBoundSetter.
So whereas you had to write:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo(int a, int b, int c, int d) {
this.a = a;
this.b = b;
this.c = c;
this.d = d;
}
}
You can now write:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo(int a, int b) {
this.a = a;
this.b = b;
}
@DataBoundSetter
public void setC(int c) { this.c = c; }
@DataBoundSetter
public void setD(int d) { this.d = d; }
}
Or even:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo() {}
@DataBoundSetter
public void setA(int a) { this.a = a; }
@DataBoundSetter
public void setC(int b) { this.b = b; }
@DataBoundSetter
public void setC(int c) { this.c = c; }
@DataBoundSetter
public void setD(int d) { this.d = d; }
}
This will make it easier to evolve plugins that have a large number of
configuration options.
[1]
https://github.com/jenkinsci/xcode-plugin/blob/master/src/main/java/au/com/rayh/XCodeBuilder.java#L165
--
Kohsuke Kawaguchi --
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 options, visit https://groups.google.com/groups/opt_out.
--
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 options, visit https://groups.google.com/groups/opt_out.
--
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 options, visit https://groups.google.com/groups/opt_out.
Why won't my plug-in display updated settings
Hi, I'm trying to write a plug-in that will link to a custom tool to post process my build results and archive them in the Jenkins build directory. I've got the guts of the plug-in working, but I'm having some trouble with the configuration screen... I've created a config.jelly script containing: * f:advanced f:entry title=Results Directory field=resultsDir f:textbox default=target/results// /f:entry /f:advanced /j:jelly * As expected, I the jobs config screen contains a text box with the value target/results. I can update the value in the browser and when I save/apply the change the job's config.xml file is updated. So far so good. The problem occurs when I go back into the config screen - the original value is displayed in text box and if I apply/save the configuration then my modified value is over written. Clearly I'd doing something wrong, but I can't see what! Any ideas? -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Why won't my plug-in display updated settings
I don't know if it helps, but I'm working with Jenkins version 1.532 On 4 October 2013 14:55, RDR forward.my.mai...@gmail.com wrote: Hi, I'm trying to write a plug-in that will link to a custom tool to post process my build results and archive them in the Jenkins build directory. I've got the guts of the plug-in working, but I'm having some trouble with the configuration screen... I've created a config.jelly script containing: * f:advanced f:entry title=Results Directory field=resultsDir f:textbox default=target/results// /f:entry /f:advanced /j:jelly * As expected, I the jobs config screen contains a text box with the value target/results. I can update the value in the browser and when I save/apply the change the job's config.xml file is updated. So far so good. The problem occurs when I go back into the config screen - the original value is displayed in text box and if I apply/save the configuration then my modified value is over written. Clearly I'd doing something wrong, but I can't see what! Any ideas? -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: @DataBoundSetter
maybe using @PostConstruct ?
2013/10/4 Kevin Fleming (BLOOMBERG/ 731 LEXIN) kpflem...@bloomberg.net
How will the object know that Stapler has completed calling
DataBoundSetters (that all configuration data has been applied)?
- Original Message -
From: jenkinsci-dev@googlegroups.com
To: jenkinsci-dev@googlegroups.com
At: Oct 4 2013 00:38:55
great,
so next step is to be able to directly annotate fields à la hibernate :)
class Foo {
@DataBound
int a,b,c,d;
}
2013/10/4 Kohsuke Kawaguchi k...@kohsuke.org
Today, many complex plugins suffer from a massive constructor annotated
with @DataBoundConstructor.
This is because the form data-binding requires that all the parameters
passed in through the constructor. See xcode plugin [1] for an example of
this. The situation was worse with plugins that are used by other plugins,
which needed to preserve ever-increasing list of constructors to remain
backward compatible.
Starting Jenkins 1.535, this problem is no more. Stapler can not only
look for @DataBoundConstructor, but it'll also perform setter injection on
methods annotated with @DataBoundSetter.
So whereas you had to write:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo(int a, int b, int c, int d) {
this.a = a;
this.b = b;
this.c = c;
this.d = d;
}
}
You can now write:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo(int a, int b) {
this.a = a;
this.b = b;
}
@DataBoundSetter
public void setC(int c) { this.c = c; }
@DataBoundSetter
public void setD(int d) { this.d = d; }
}
Or even:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo() {}
@DataBoundSetter
public void setA(int a) { this.a = a; }
@DataBoundSetter
public void setC(int b) { this.b = b; }
@DataBoundSetter
public void setC(int c) { this.c = c; }
@DataBoundSetter
public void setD(int d) { this.d = d; }
}
This will make it easier to evolve plugins that have a large number of
configuration options.
[1]
https://github.com/jenkinsci/xcode-plugin/blob/master/src/main/java/au/com/rayh/XCodeBuilder.java#L165
--
Kohsuke Kawaguchi
--
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 options, visit https://groups.google.com/groups/opt_out.
--
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 options, visit https://groups.google.com/groups/opt_out.
--
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 options, visit https://groups.google.com/groups/opt_out.
--
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 options, visit https://groups.google.com/groups/opt_out.
Re: Why won't my plug-in display updated settings
On Fri, Oct 4, 2013 at 6:55 AM, RDR forward.my.mai...@gmail.com wrote: The problem occurs when I go back into the config screen - the original value is displayed in text box and if I apply/save the configuration then my modified value is over written. Does it work if you remove default=target/results/? If so, it sounds like a bug in textbox.jelly, though the code looks right to me. I would not really recommend using the ‘default’ attribute anyway; it is better not to serialize anything if the user has not made customizations to a field. Just let a blank value be saved, and in your perform() method or whatever, treat a blank value as whatever default makes sense in that context. (And create help-resultsDir.html that explains this.) -- 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 options, visit https://groups.google.com/groups/opt_out.
RE: Tapping into Test Results
Good to know that there will be more than just junit test results. Where can I find a list of these test types documented? Will the test id contain a different prefix (ex: junit/ for junit tests)? Thanks! Cletus Date: Thu, 3 Oct 2013 14:47:13 -0700 From: teilo+goo...@teilo.net To: jenkinsci-dev@googlegroups.com Subject: RE: Tapping into Test Results eep in mind that not all test results are of the junit type. You may be able to get all this information with the test.* classes GetFailedTests is broken so you would likely want to getResult and take Avon depending on the type if object returned -- 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 options, visit https://groups.google.com/groups/opt_out. -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Tapping into Test Results
I don't think there is anything documented as this is done via plugin extensions. if you grabbed all source from githun (including plugins) you could grep for extends AbstractTestResultAction and that may give you an idea (but I'm not sure that the ones that exist are open source. The prefixes (I believe) need to be unique for the different types. The one I am working on at the moment is cucumber and I hope to be able to open source it shortly. /James On Friday, 4 October 2013 16:50:58 UTC+1, Cletus D'Souza wrote: Good to know that there will be more than just junit test results. Where can I find a list of these test types documented? Will the test id contain a different prefix (ex: junit/ for junit tests)? Thanks! Cletus Date: Thu, 3 Oct 2013 14:47:13 -0700 From: teilo+...@teilo.net javascript: To: jenkin...@googlegroups.com javascript: Subject: RE: Tapping into Test Results eep in mind that not all test results are of the junit type. You may be able to get all this information with the test.* classes GetFailedTests is broken so you would likely want to getResult and take Avon depending on the type if object returned -- 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-de...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Tapping into Test Results
I've had to adapt the tap-plugin [1] to display TAP test results in Jenkins, mimicking the JUnit test results. Perhaps taking a look at the code will help you in some way. [1] https://github.com/jenkinsci/tap-plugin Hope that helps, Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com From: teilo teilo+goo...@teilo.net To: jenkinsci-dev@googlegroups.com Cc: cletusdso...@hotmail.com Sent: Friday, October 4, 2013 1:26 PM Subject: Re: Tapping into Test Results I don't think there is anything documented as this is done via plugin extensions. if you grabbed all source from githun (including plugins) you could grep for extends AbstractTestResultAction and that may give you an idea (but I'm not sure that the ones that exist are open source. The prefixes (I believe) need to be unique for the different types. The one I am working on at the moment is cucumber and I hope to be able to open source it shortly. /James On Friday, 4 October 2013 16:50:58 UTC+1, Cletus D'Souza wrote: Good to know that there will be more than just junit test results. Where can I find a list of these test types documented? Will the test id contain a different prefix (ex: junit/ for junit tests)? Thanks! Cletus Date: Thu, 3 Oct 2013 14:47:13 -0700 From: teilo+...@teilo.net To: jenkin...@googlegroups.com Subject: RE: Tapping into Test Results eep in mind that not all test results are of the junit type. You may be able to get all this information with the test.* classes GetFailedTests is broken so you would likely want to getResult and take Avon depending on the type if object returned -- 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-de...@ googlegroups.com. For more options, visit https://groups.google.com/ groups/opt_out. -- 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 options, visit https://groups.google.com/groups/opt_out. -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Why won't my plug-in display updated settings
On Fri, Oct 4, 2013 at 6:55 AM, RDR forward.my.mai...@gmail.com wrote: f:entry title=Results Directory field=resultsDir Does your tool have a public String getResultsDir() method? -- 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 options, visit https://groups.google.com/groups/opt_out.
SDK for Python plugins in development
Hi everyone, my name is Tomáš Bambas and I decided to implement a support for plugins written in Python as my Master's thesis. The goal is to bring a similar SDK like the jenkins.rb https://github.com/jenkinsci/jenkins.rb for Ruby. My consultant is Vojta Juranek (RH) and we hope this work will help involve more Jenkins plugin developers, especially these with no Java experiences, but with great Python skills. You can watch a progress at https://github.com/conyx/jenkins.py, but first some research and proof of concept has to be done. My Master's thesis will be finished in the spring 2014 so as the SDK should be working. Have a nice weekend! Tomáš -- 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 options, visit https://groups.google.com/groups/opt_out.
Winstone is now powered by Jetty
I started using Winstone from the very early days of Jenkins before it was known by its current name. The idea of embedding a small servlet container was a huge hit, and so Winstone really helped Jenkins become popular. But unfortunately, over the last few years, the upstream development of Winstone has ceased and we ended up taking over the maintenance of it. Clearly this is not the best use of our time. At the same time, Winstone is the servlet container used for all of our native pacakges, and people have customized their invocations, so it is very important that the command line switches people use on java -jar jenkins.war keeps working. The way out has been pretty clear for a long time. I wanted to essentially convert Winstone into a command line wrapper of Jetty. We let Jetty do all the actual work, and just use Winstone's command line option processor to remain option compatible with current Winstone. In this way, we can leverage all the features in Jetty, such as SPDY support or Servlet 3.0. Servlet 3.0 in particular should help us take advantages of UI features. (BTW The real deciding factor of choosing Winstone over Jetty in the first place was because Sun had a competing project to Jetty, and I was told it doesn't send the right message for me to use Jetty! I no longer have that problem.) I've suggested this to several people in IRC but all felt that it's bit too much for them to drive the effort, even though they thought they'd be happy to chip in once the effort goes underway. So if you are one of them (and you know who I'm talking about!), now it's time for you to chime in, as I finally took the time yesterday to make this change [1]. At this point, the small number of tests that it has all passes, so it's not completely broken. There's a TODO.txt in the repository that shows what needs to be done. Mainly, I think we need to write some more tests to verify that key features that people rely on works. Other contributions, such as adding SPDY support, would be welcome, too. [1] https://github.com/jenkinsci/winstone/tree/jetty -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: @DataBoundSetter
On 10/03/2013 09:38 PM, nicolas de loof wrote:
great,
so next step is to be able to directly annotate fields à la hibernate :)
class Foo {
@DataBound
int a,b,c,d;
}
Good idea. I should support that.
2013/10/4 Kohsuke Kawaguchi k...@kohsuke.org mailto:k...@kohsuke.org
Today, many complex plugins suffer from a massive constructor annotated
with
@DataBoundConstructor.
This is because the form data-binding requires that all the parameters
passed in through the constructor. See xcode plugin [1] for an example of
this. The situation was worse with plugins that are used by other plugins,
which needed to preserve ever-increasing list of constructors to remain
backward compatible.
Starting Jenkins 1.535, this problem is no more. Stapler can not only look
for @DataBoundConstructor, but it'll also perform setter injection on
methods annotated with @DataBoundSetter.
So whereas you had to write:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo(int a, int b, int c, int d) {
this.a = a;
this.b = b;
this.c = c;
this.d = d;
}
}
You can now write:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo(int a, int b) {
this.a = a;
this.b = b;
}
@DataBoundSetter
public void setC(int c) { this.c = c; }
@DataBoundSetter
public void setD(int d) { this.d = d; }
}
Or even:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo() {}
@DataBoundSetter
public void setA(int a) { this.a = a; }
@DataBoundSetter
public void setC(int b) { this.b = b; }
@DataBoundSetter
public void setC(int c) { this.c = c; }
@DataBoundSetter
public void setD(int d) { this.d = d; }
}
This will make it easier to evolve plugins that have a large number of
configuration options.
[1]
https://github.com/jenkinsci/xcode-plugin/blob/master/src/main/java/au/com/rayh/XCodeBuilder.java#L165
--
Kohsuke Kawaguchi
--
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
mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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 options, visit https://groups.google.com/groups/opt_out.
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins
--
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 options, visit https://groups.google.com/groups/opt_out.
Re: @DataBoundSetter
On 10/04/2013 07:00 AM, nicolas de loof wrote:
maybe using @PostConstruct ?
2013/10/4 Kevin Fleming (BLOOMBERG/ 731 LEXIN) kpflem...@bloomberg.net
mailto:kpflem...@bloomberg.net
How will the object know that Stapler has completed calling
DataBoundSetters
(that all configuration data has been applied)?
Another great idea. Will implement this.
- Original Message -
From: jenkinsci-dev@googlegroups.com
mailto:jenkinsci-dev@googlegroups.com
To: jenkinsci-dev@googlegroups.com mailto:jenkinsci-dev@googlegroups.com
At: Oct 4 2013 00:38:55
great,
so next step is to be able to directly annotate fields à la hibernate
:)
class Foo {
@DataBound
int a,b,c,d;
}
2013/10/4 Kohsuke Kawaguchi k...@kohsuke.org
mailto:k...@kohsuke.org
Today, many complex plugins suffer from a massive constructor
annotated with @DataBoundConstructor.
This is because the form data-binding requires that all the
parameters passed in through the constructor. See xcode plugin [1]
for an example of this. The situation was worse with plugins that
are used by other plugins, which needed to preserve ever-increasing
list of constructors to remain backward compatible.
Starting Jenkins 1.535, this problem is no more. Stapler can not
only look for @DataBoundConstructor, but it'll also perform setter
injection on methods annotated with @DataBoundSetter.
So whereas you had to write:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo(int a, int b, int c, int d) {
this.a = a;
this.b = b;
this.c = c;
this.d = d;
}
}
You can now write:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo(int a, int b) {
this.a = a;
this.b = b;
}
@DataBoundSetter
public void setC(int c) { this.c = c; }
@DataBoundSetter
public void setD(int d) { this.d = d; }
}
Or even:
class Foo {
int a,b,c,d;
@DataBoundConstructor
public Foo() {}
@DataBoundSetter
public void setA(int a) { this.a = a; }
@DataBoundSetter
public void setC(int b) { this.b = b; }
@DataBoundSetter
public void setC(int c) { this.c = c; }
@DataBoundSetter
public void setD(int d) { this.d = d; }
}
This will make it easier to evolve plugins that have a large number
of configuration options.
[1]
https://github.com/jenkinsci/xcode-plugin/blob/master/src/main/java/au/com/rayh/XCodeBuilder.java#L165
--
Kohsuke Kawaguchi
--
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
mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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
mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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
mailto:jenkinsci-dev%2bunsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
--
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 options, visit https://groups.google.com/groups/opt_out.
--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional
Re: Backporting 1.509.4 complete
On 10/03/2013 05:46 AM, oliver gondža wrote: Hi, I have finished backporting issues for 1.509.4. On governance meeting, we agreed that this is the very last minor release based on 1.509. We have 5 blockers and 8 critical fixes backported, 35 issues in total[1]. All 4 issues rejected from 1.509.3 will be present in 1.509.4. Kohsuke, please post RC. Done. See http://mirrors.jenkins-ci.org/ [1] https://issues.jenkins-ci.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+10172+AND+labels+%3D+%221.509.4-fixed%22 -- oliver -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- 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 options, visit https://groups.google.com/groups/opt_out.
Re: Backporting 1.509.4 complete
Note that this is stable-rc. You should look under http://mirrors.jenkins-ci.org/war-stable-rc/ On 10/04/2013 12:32 PM, Mirko Friedenhagen wrote: Hello Kohsuke, when surfing to http://mirrors.jenkins-ci.org/war-stable/ I only see 1.503.3 from September 9th. Regards Mirko Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Fri, Oct 4, 2013 at 9:03 PM, Kohsuke Kawaguchi kkawagu...@cloudbees.com wrote: On 10/03/2013 05:46 AM, oliver gondža wrote: Hi, I have finished backporting issues for 1.509.4. On governance meeting, we agreed that this is the very last minor release based on 1.509. We have 5 blockers and 8 critical fixes backported, 35 issues in total[1]. All 4 issues rejected from 1.509.3 will be present in 1.509.4. Kohsuke, please post RC. Done. See http://mirrors.jenkins-ci.org/ [1] https://issues.jenkins-ci.org/secure/IssueNavigator.jspa?reset=truejqlQuery=project+%3D+10172+AND+labels+%3D+%221.509.4-fixed%22 -- oliver -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- 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 options, visit https://groups.google.com/groups/opt_out. -- Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/ Try Jenkins Enterprise, our professional version of Jenkins -- 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 options, visit https://groups.google.com/groups/opt_out.
Recommended approach with Jenkins for a situation
I am looking for some guidance about something to stick with Jenkins best design principles... .. Here's the scenario. - Build runs and passes. - Executes post-build Notification Step - For some reason the Notification Step cannot complete. - The notification is therefore lost. - The build shows as successful (which of course it is, just the notification step did not complete. I would like the ability to change the build to failed so someone might notice the problem (or record an appropriate message somewhere). Is the recommended to just LOG, set a status, etc. etc. or is there a pre-defined way I could just change the build to Failed (after the fact). I'm would be happy to do the heavy lifting if someone points me to something that already works this way ... Or even better, if I could just figure out the best way to incorporate something that already works. Thanks Mike -- 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 options, visit https://groups.google.com/groups/opt_out.
