Re: how to convert persisted data from old plugin to new one??

[addict . vim]

So I need to hook when job is opened for configuration and when build is 
started -  correct? build started can be handled by RunListener, what about 
opening job configuration page - I can't find a way yet

пятница, 1 августа 2014 г., 10:08:55 UTC+4 пользователь addic...@gmail.com 
написал:
>
> Stephen, you are right - I was not doing thing right -  I have changed the 
> plugin name a little bit - this caused above mentioned issue. now I have 
> returned old name and everything is fine
>
> thinking on how to replace all jobs traversal.
>
> On Thursday, July 31, 2014 6:40:41 PM UTC+4, Stephen Connolly wrote:
>>
>>
>>
>>
>> On 31 July 2014 15:27,  wrote:
>>
>>> thanks again, Stephen. Could  I ask more questions? excerpt from ""
>>> https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
>>>  
>>> says "*Hudson has an automatic data format upgrade capability*" - what 
>>> does it mean?
>>>
>>
>> readResolve() and the fact that XStream doesn't care about matching the 
>> serialVersionUid
>>  
>>
>>>
>>> I have one more issue with my final solution - after plugin update at 
>>> runtime all fields in job configurations appear empty - after restart they 
>>> all are filled  correctly - should I force some kind of job reloading or 
>>> something?
>>>
>>
>> Sounds like you are not doing thing right.
>>  
>>
>>>
>>> thanks in advance
>>>
>>>
>>> On Thursday, July 31, 2014 4:55:04 PM UTC+4, Stephen Connolly wrote:
>>>
 I worry about the startup time scanning all jobs... there can be 1000's 
 of them... better if you can have something that kicks in when the job is 
 being saved... as that way people can revert your upgrade if there is 
 something wrong without loosing data.

 Oh and whatever approach you take, remember to set the 
 compatibleSinceVersion to the first version with the new data layout to 
 give people the scary warning that they never read correctly
  

 On 31 July 2014 13:47,  wrote:

> Finally I have ended with following solution.
>
> 1. add removed fields and mark them as transient
> 2. register static method with @Initializer(after = 
> InitMilestone.JOB_LOADED)
> 3. for each job do check whether new job property exists if not create 
> new one and move transient fields to it and then add new job property to 
> the job
>
> does it go? what do you think guys?
>
>
> On Thursday, July 31, 2014 2:21:05 PM UTC+4, addic...@gmail.com wrote:
>>
>> Thanks, Stephen. nice approach. but what to do if I just moved some 
>> fields from one job property to another new one (not swapping them 
>> entirely)
>>
>> On Tuesday, July 29, 2014 6:36:30 PM UTC+4, Stephen Connolly wrote:
>>>
>>> Note that you need to be swapping like for like... you can swap one 
>>> Publisher for another Publisher, but you cannot swap a Publisher for a 
>>> JobProperty
>>>
>>>
>>> On 29 July 2014 15:35, Stephen Connolly  
>>> wrote:
>>>
 If you are swapping one JobProperty for another just have 
 readResolve return the correctly configured new JobProperty, e.g. see 
 similar https://github.com/jenkinsci/cloudbees-deployer-plug
 in/blob/master/src/main/java/org/jenkins/plugins/cloudbees/
 CloudbeesPublisher.java#L102
  

 On 29 July 2014 14:25,  wrote:

> thanks, slide. I have already gone through it. but I can't figure 
> out the final solution of issue - 
> so I can mark fields as transient and check their values at 
> readResolve, what then? how to move these values to new job property?
>
> вторник, 29 июля 2014 г., 16:36:08 UTC+4 пользователь slide 
> написал:
>>
>> This page, [1], has some good tips.
>>
>> slide
>>
>> 1 - https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retain
>> ing+backward+compatibility
>>
>>
>> On Tue, Jul 29, 2014 at 5:30 AM,  wrote:
>>
>>>  Hi, everyone. Could you please advice me what to do at the 
>>> following case:
>>>
>>> I have one JobProperty at the old version of plugin. after some 
>>> refactoring I have created another one job property and moved 
>>> attributes 
>>> from old job property to new one.
>>> the issue is how to upgrade old job configurations to new one 
>>> seamlessly?
>>>
>>> thanks in advance
>>>
>>>
>>>
>>>  -- 
>>> 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.goog

Re: how to convert persisted data from old plugin to new one??

[addict . vim]

Stephen, you are right - I was not doing thing right -  I have changed the 
plugin name a little bit - this caused above mentioned issue. now I have 
returned old name and everything is fine

thinking on how to replace all jobs traversal.

On Thursday, July 31, 2014 6:40:41 PM UTC+4, Stephen Connolly wrote:
>
>
>
>
> On 31 July 2014 15:27, > wrote:
>
>> thanks again, Stephen. Could  I ask more questions? excerpt from ""
>> https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
>>  
>> says "*Hudson has an automatic data format upgrade capability*" - what 
>> does it mean?
>>
>
> readResolve() and the fact that XStream doesn't care about matching the 
> serialVersionUid
>  
>
>>
>> I have one more issue with my final solution - after plugin update at 
>> runtime all fields in job configurations appear empty - after restart they 
>> all are filled  correctly - should I force some kind of job reloading or 
>> something?
>>
>
> Sounds like you are not doing thing right.
>  
>
>>
>> thanks in advance
>>
>>
>> On Thursday, July 31, 2014 4:55:04 PM UTC+4, Stephen Connolly wrote:
>>
>>> I worry about the startup time scanning all jobs... there can be 1000's 
>>> of them... better if you can have something that kicks in when the job is 
>>> being saved... as that way people can revert your upgrade if there is 
>>> something wrong without loosing data.
>>>
>>> Oh and whatever approach you take, remember to set the 
>>> compatibleSinceVersion to the first version with the new data layout to 
>>> give people the scary warning that they never read correctly
>>>  
>>>
>>> On 31 July 2014 13:47,  wrote:
>>>
 Finally I have ended with following solution.

 1. add removed fields and mark them as transient
 2. register static method with @Initializer(after = 
 InitMilestone.JOB_LOADED)
 3. for each job do check whether new job property exists if not create 
 new one and move transient fields to it and then add new job property to 
 the job

 does it go? what do you think guys?


 On Thursday, July 31, 2014 2:21:05 PM UTC+4, addic...@gmail.com wrote:
>
> Thanks, Stephen. nice approach. but what to do if I just moved some 
> fields from one job property to another new one (not swapping them 
> entirely)
>
> On Tuesday, July 29, 2014 6:36:30 PM UTC+4, Stephen Connolly wrote:
>>
>> Note that you need to be swapping like for like... you can swap one 
>> Publisher for another Publisher, but you cannot swap a Publisher for a 
>> JobProperty
>>
>>
>> On 29 July 2014 15:35, Stephen Connolly  
>> wrote:
>>
>>> If you are swapping one JobProperty for another just have 
>>> readResolve return the correctly configured new JobProperty, e.g. see 
>>> similar https://github.com/jenkinsci/cloudbees-deployer-plug
>>> in/blob/master/src/main/java/org/jenkins/plugins/cloudbees/
>>> CloudbeesPublisher.java#L102
>>>  
>>>
>>> On 29 July 2014 14:25,  wrote:
>>>
 thanks, slide. I have already gone through it. but I can't figure 
 out the final solution of issue - 
 so I can mark fields as transient and check their values at 
 readResolve, what then? how to move these values to new job property?

 вторник, 29 июля 2014 г., 16:36:08 UTC+4 пользователь slide написал:
>
> This page, [1], has some good tips.
>
> slide
>
> 1 - https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retain
> ing+backward+compatibility
>
>
> On Tue, Jul 29, 2014 at 5:30 AM,  wrote:
>
>>  Hi, everyone. Could you please advice me what to do at the 
>> following case:
>>
>> I have one JobProperty at the old version of plugin. after some 
>> refactoring I have created another one job property and moved 
>> attributes 
>> from old job property to new one.
>> the issue is how to upgrade old job configurations to new one 
>> seamlessly?
>>
>> thanks in advance
>>
>>
>>
>>  -- 
>> 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/d/optout.
>>
>
>
>
> -- 
> Website: http://earl-of-code.com 
>
  -- 
 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:/

Re: Changing Console Output to look more like terminal

[Dean Yu]

-∞

But not because I think black on white is better; that is a matter of 
preference.

This change forces the author's preference on everyone with no way to opt 
out of it for people who prefer the existing theme. Furthermore, you would 
then ask the maintainers of other plugins to have to change those plugins 
to work with this new theme.

A better solution would be to add hooks into Jenkins to allow the console 
log to be themed by plugins, but maintain the original. Then you create 
supply the white on black theme as a plugin for people who prefer that.

  -- Dean

On Thursday, July 31, 2014 9:41:24 AM UTC-7, Tom Fennelly wrote:
>
> Hi.
>
> Kevin created a PR some time ago re tweaking the Console Output page to 
> make the default output look more like terminal: 
> https://github.com/jenkinsci/jenkins/pull/1272
>
> There was a fair bit of discussion on the PR but consensus was not 
> reached.  Some people felt the changes might effect accessibility but Kev 
> was able to show how the web "norm" seems to be a dark background with 
> lighter colors for the text.
>
> Would be good give this the thumbs up or down.
>

-- 
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/d/optout.

Re: Changing Console Output to look more like terminal

[d...@fortysix.ch]

+ 10 for black


On 31 Jul 2014, at 18:41, Tom Fennelly  wrote:

> Hi.
> 
> Kevin created a PR some time ago re tweaking the Console Output page to make 
> the default output look more like terminal: 
> https://github.com/jenkinsci/jenkins/pull/1272
> 
> There was a fair bit of discussion on the PR but consensus was not reached.  
> Some people felt the changes might effect accessibility but Kev was able to 
> show how the web "norm" seems to be a dark background with lighter colors for 
> the text.
> 
> Would be good give this the thumbs up or down.
> 
> -- 
> 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/d/optout.

-- 
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/d/optout.

Re: "Jenkins Workflow Summit" to go with JUC Bay Area?

[Surya Gaddipati]

I would be very interested in this also. I think its a great idea.

On Wednesday, July 30, 2014 4:31:25 PM UTC-5, Kohsuke Kawaguchi wrote:
>
>
> Some of you were in the Jenkins Scalability Summit last year [1,2,3]. 
> I'm trying to see if we can do a similar one this year back to back with 
> JUC Bay Area. 
>
> To recap, the idea of the scalability summit was to have a small number 
> of serious active users/developers in the room, to deep dive into 
> Jenkins. The last year the event was themed around scalability and was 
> run in part like an unconference, where the attendees have collectively 
> decided on the agenda for the day. 
>
> We could keep the same theme this year, but someone suggested to me that 
> since workflow is a big focus this year, maybe that could be the theme. 
> I can easily picture Jesse and I presenting technical details of various 
> parts of the workflow plugin, people sharing and collecting real-world 
> use cases, brainstorming around enhancements / roadmap, maybe even a 
> workshop of getting extensions implemented. 
>
>
> Is something like this interesting for you? Is it worth doing? 
>
>
> (Another suggestion was to just turn it into a full-blown unconference. 
> Namely, don't have any particular theme, and allow anyone who wants to 
> come to come. We'll just let attendees dictate the topics. The only 
> problem I have with this is that we need a lot bigger venue, which is 
> hard to come by, so unless somebody local in the bay area shows up and 
> sponsors a suitable venue, I don't think this is happening.) 
>
>
> [1] 
> https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+Scalability+Summit+2013 
> [2] http://jenkins-ci.org/content/jenkins-scalability-summit-recap 
> [3] 
>
> https://docs.google.com/document/d/1GqkWPnp-bvuObGlSe7t3k76ZOD2a8Z2M1avggWoYKEs/edit
>  
> -- 
> Kohsuke Kawaguchi  http://kohsuke.org/ 
>

-- 
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/d/optout.

Plugin that generates Jobs based on a template

[Karthik V S]

Hi,

I would like to check whether there exists any plugin that matches the 
following use case

1) Create a parent Job that acts as the template with a specified set of 
User fields

2) On running the plugin, the plugin should spawn new job(child job) of the 
same template.

3) If the new job already exists, then when changing the values of the user 
fields in the parent template, should update the child jobs that were 
spawned by the parent job.


Could you please let me know if there is a plugin that already does this?

Thanks,
Karthik

-- 
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/d/optout.

Re: Require JDK 7 to build?

[Stephen Connolly]

Slippery slope... How can we grease is some more (roll on JDK 8 as min
runtime)

On Friday, 1 August 2014, Kohsuke Kawaguchi  wrote:

>
> +1 for moving up to Java7 as a build requirement. I don't see any problem.
>
> (Just to avoid confusion, the runtime requirement will remain Java6+. We
> are just talking about the build requirement.)
>
> On 07/31/2014 06:56 AM, Jesse Glick wrote:
>
>> Are people still building Jenkins core using JDK 6? I ask because it
>> would be helpful to be able to assume 7+:
>>
>> · We could make use of 7+ APIs, especially java.nio.file.*, without
>> using reflection (just guarding usage via @IgnoreJRERequirement and
>> catching NoClassDefFoundError or the like).
>> · http://findbugs.sourceforge.net/ 3.0.0 *allows* building with JDK 8
>> (otherwise you get errors running FB analysis) but *requires* building
>> with at least 7.
>>
>> Of course the same considerations might apply to plugin builds.
>>
>>
>
> --
> Kohsuke Kawaguchi  http://kohsuke.org/
>
> --
> 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/d/optout.
>


-- 
Sent from my phone

-- 
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/d/optout.

Re: Require JDK 7 to build?

[Kohsuke Kawaguchi]

+1 for moving up to Java7 as a build requirement. I don't see any problem.

(Just to avoid confusion, the runtime requirement will remain Java6+. We 
are just talking about the build requirement.)


On 07/31/2014 06:56 AM, Jesse Glick wrote:

Are people still building Jenkins core using JDK 6? I ask because it
would be helpful to be able to assume 7+:

· We could make use of 7+ APIs, especially java.nio.file.*, without
using reflection (just guarding usage via @IgnoreJRERequirement and
catching NoClassDefFoundError or the like).
· http://findbugs.sourceforge.net/ 3.0.0 *allows* building with JDK 8
(otherwise you get errors running FB analysis) but *requires* building
with at least 7.

Of course the same considerations might apply to plugin builds.




--
Kohsuke Kawaguchi  http://kohsuke.org/

--
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/d/optout.

Re: Changing Console Output to look more like terminal

[Ulli Hafner]

I think the default should not be changed: black text on white is the most 
readable scheme to most humans.

Am 31.07.2014 um 21:08 schrieb Bruno Meneguello :

> I think the actual white page is better because despite the page name is 
> "console" it's actually a log output and not a terminal emulator.
> So put this way, and being the actual Jenkins theme background white, my vote 
> is to keep the actual consult scheme, but not discard some theming options 
> for those who prefer other schemes.
> 
> Em 31/07/2014 13:41, "Tom Fennelly"  escreveu:
> Hi.
> 
> Kevin created a PR some time ago re tweaking the Console Output page to make 
> the default output look more like terminal: 
> https://github.com/jenkinsci/jenkins/pull/1272
> 
> There was a fair bit of discussion on the PR but consensus was not reached.  
> Some people felt the changes might effect accessibility but Kev was able to 
> show how the web "norm" seems to be a dark background with lighter colors for 
> the text.
> 
> Would be good give this the thumbs up or down.
> 
> -- 
> 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/d/optout.
> 
> -- 
> 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/d/optout.



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Changing "Trigger/call builds on other projects" project names via Groovy console

[Amos S]

Thanks.

That's what I was suspecting that I'll have to do but didn't find the code 
to do it.
I'll also have to be able to somehow copy over everything else from the 
existing object except for this change.
Would you know where can I find an example, or at least a class name to 
look for?

Cheers.

On Thursday, 31 July 2014 21:58:42 UTC+10, Robert Sandell wrote:
>
> Construct a new builder object and replace the old one, that is basically 
> what the save button does.
>
> /B
>
>
> 2014-07-31 9:05 GMT+02:00 Amos S >:
>
>> Hello,
>>
>> I'm trying to change the names of projects which will be triggered by a 
>> build via the Groovy console.
>>
>> I got as far as being able to extract the field from the data structures 
>> but didn't find a way to set it with a new value.
>>
>> Here is the code I got so far:
>>
>> import hudson.model.*
>> import hudson.model.FreeStyleProject
>> import jenkins.model.Jenkins
>> import hudson.plugins.parameterizedtrigger.TriggerBuilder
>>
>> def viewName = "v2.9"
>>
>> Jenkins jenkins = Jenkins.getInstance()
>>
>> jenkins.getView(viewName).getItems().each { item ->
>> def jobName = item.getName()
>> FreeStyleProject job = jenkins.getItem(jobName)
>>
>> job.builders.each { builder ->
>> if (builder.metaClass.respondsTo(builder, "getConfigs")) {
>> builder.getConfigs().each { config ->
>> println("projects to build: \"" + config.getProjects() + 
>> "\"")
>> }
>> }
>> }
>> }
>>
>> so "getProjects()" returns to be the content of the field I want to 
>> change, here is the field I want to change:
>>
>>  
>> 
>>
>> How can I achieve this?
>>
>> 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-de...@googlegroups.com .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>

-- 
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/d/optout.

Re: Changing Console Output to look more like terminal

[Bruno Meneguello]

I think the actual white page is better because despite the page name is
"console" it's actually a log output and not a terminal emulator.
So put this way, and being the actual Jenkins theme background white, my
vote is to keep the actual consult scheme, but not discard some theming
options for those who prefer other schemes.
Em 31/07/2014 13:41, "Tom Fennelly"  escreveu:

> Hi.
>
> Kevin created a PR some time ago re tweaking the Console Output page to
> make the default output look more like terminal:
> https://github.com/jenkinsci/jenkins/pull/1272
>
> There was a fair bit of discussion on the PR but consensus was not
> reached.  Some people felt the changes might effect accessibility but Kev
> was able to show how the web "norm" seems to be a dark background with
> lighter colors for the text.
>
> Would be good give this the thumbs up or down.
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

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

[David Karlsen]

For reference, this is the maven release plugin issue:
https://jira.codehaus.org/browse/MRELEASE-812 AFAIK.


2014-07-31 15:12 GMT+02:00 Marco Miller :

> Indeed; and that is basically the info I added to the wiki(*) some weeks
> ago, when I experienced such troubles myself:
>
> (*)
> https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Workingaroundcommonissues
>
> => wiki should have all the needed info by now.
> /Marco
>
> Le mercredi 30 juillet 2014 10:15:00 UTC-4, Stephen Connolly a écrit :
>>
>> there is a much simpler way to get a release:
>>
>> instead of doing
>>
>> $ mvn release:prepare release:perform
>>
>> (with the -B if you are feeling YOLO)
>>
>> you do
>>
>> $ mvn org.apache.maven.plugins:maven-release-plugin:2.5:prepare
>> org.apache.maven.plugins:maven-release-plugin:2.5:perform
>>
>> Simples
>>
>>
>> On 30 July 2014 14:59, Markus Pfeiffer 
>> wrote:
>>
>>> I've run into the same issue using git 1.9.1 + maven 3.2.2 on Ubuntu and
>>> git 1.8.5.2 + maven 3.1.1 on Mac. The release version is never committed
>>> and never appears in the store. I also seem to be in the same boat as
>>> Ulrich Hafner, our Jenkins plugin is in a subfolder of the git repository
>>> and none of the workarounds seem to work.
>>>
>>> I've used nigelm's tip and simply did a manual deploy using a
>>> combination of mvn version:set and mvn deploy. To simplify the process in
>>> the future I've written a simple bash script that others may find useful:
>>>
>>> #!/bin/bash

 # 
> 

 NAME=<>

 echo Preparing $NAME for release


> # Query user for info

 read -p "Enter version number to use for the release: " VERSION_RELEASE

 read -p "Enter name for the release tag [$NAME-$VERSION_RELEASE]: "
> TAG_RELEASE

 read -p "Enter version number for next development iteration: "
> VERSION_SNAPSHOT


> if [[ -z "$TAG_RELEASE" ]]; then

   TAG_RELEASE=$NAME-$VERSION_RELEASE

 fi


> if [[ "$VERSION_SNAPSHOT" != *-SNAPSHOT ]]; then

   VERSION_SNAPSHOT=$VERSION_SNAPSHOT-SNAPSHOT

 fi


> # Show info for review

 echo

 echo "Release version  : $VERSION_RELEASE"

 echo "Tag release with : $TAG_RELEASE"

 echo "Next iteration   : $VERSION_SNAPSHOT"

 read -p "Continue (y/N)? " -s -n1 KEY

 echo


> if [[ "$KEY" != "y" ]]; then

  echo "Aborted"

  exit

 fi


> # Set the new version, commit, create a tag

 mvn versions:set -DnewVersion=$VERSION_RELEASE

 git add pom.xml

 git commit -m "prepare release $TAG_RELEASE"

 git tag $TAG_RELEASE


> # Deploy the new version

 mvn deploy


> # Set the new snapshot version, commit

 mvn versions:set -DnewVersion=$VERSION_SNAPSHOT

 git add pom.xml

 git commit -m "prepare for next development iteration"


> # Push changes and tags

 # git push

 # git push --tags


> # Clean up backup files

 # rm pom.xml.versionsBackup


> echo

 echo "done."


>>> The push is commented out just to be on the save side.
>>>
>>> --
>>> 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/d/optout.
>>>
>>
>>  --
> 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/d/optout.
>



-- 
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

-- 
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/d/optout.

[git-plugin] pull request #245

['Jakob Korherr' via Jenkins Developers]

Hi,

I created a pull request for the git-plugin last week:
https://github.com/jenkinsci/git-plugin/pull/245

This pull request fixes JENKINS-22009 and potentially also some related
issues. I tested the fix locally, and also provided a test case in the pull
request. The code has also been reviewed by a colleague.

Thus I think the pull request should be merged. I hope you think the same
way!

Cheers,
Jakob

-- 
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/d/optout.

Changing Console Output to look more like terminal

[Tom Fennelly]

Hi.

Kevin created a PR some time ago re tweaking the Console Output page to 
make the default output look more like 
terminal: https://github.com/jenkinsci/jenkins/pull/1272

There was a fair bit of discussion on the PR but consensus was not reached. 
 Some people felt the changes might effect accessibility but Kev was able 
to show how the web "norm" seems to be a dark background with lighter 
colors for the text.

Would be good give this the thumbs up or down.

-- 
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/d/optout.

Re: UI Suggestion

[Daniel Beck]

You provide no reasons why this would be an improvement. Here are some why it 
wouldn't be:

1. Will be a regression for everyone parsing console output and assuming a line 
starts with the actual output.

2. I already have to download logs to view them in a editor all the time 
because the browser cannot handle any logs above ~25M or so. Making the 
sidepanel a minefield for blowing up my browser seems like a bad idea. And most 
of the time, the last few lines are sufficient anyway to determine what is 
going on. You might be able to make this work for you by setting the System 
property hudson.consoleTailKB to a ridiculously large value.

On 31.07.2014, at 15:51, Andrew Gray  wrote:

> Hi All,
> 
> I have two proposals:
> 
> 1. Include the LineNumbers plugin in the Jenkins core and make that the 
> default behaviour for the console log screen?
> 
> 2. Make the Console link in the sidebar menu and the progress bar under a 
> running build navigate to:
> 
> http://localhost:8080/job///consoleFull 
> 
> rather than the current:
> 
> http://localhost:8080/job/TimesGuide/86/console
> 
> For your consideration.
> 
> Regards,
> 
> Andrew
> 
> -- 
> 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/d/optout.

-- 
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/d/optout.

Re: how to convert persisted data from old plugin to new one??

[Stephen Connolly]

On 31 July 2014 15:27,  wrote:

> thanks again, Stephen. Could  I ask more questions? excerpt from ""
> https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
> says "*Hudson has an automatic data format upgrade capability*" - what
> does it mean?
>

readResolve() and the fact that XStream doesn't care about matching the
serialVersionUid


>
> I have one more issue with my final solution - after plugin update at
> runtime all fields in job configurations appear empty - after restart they
> all are filled  correctly - should I force some kind of job reloading or
> something?
>

Sounds like you are not doing thing right.


>
> thanks in advance
>
>
> On Thursday, July 31, 2014 4:55:04 PM UTC+4, Stephen Connolly wrote:
>
>> I worry about the startup time scanning all jobs... there can be 1000's
>> of them... better if you can have something that kicks in when the job is
>> being saved... as that way people can revert your upgrade if there is
>> something wrong without loosing data.
>>
>> Oh and whatever approach you take, remember to set the
>> compatibleSinceVersion to the first version with the new data layout to
>> give people the scary warning that they never read correctly
>>
>>
>> On 31 July 2014 13:47,  wrote:
>>
>>> Finally I have ended with following solution.
>>>
>>> 1. add removed fields and mark them as transient
>>> 2. register static method with @Initializer(after =
>>> InitMilestone.JOB_LOADED)
>>> 3. for each job do check whether new job property exists if not create
>>> new one and move transient fields to it and then add new job property to
>>> the job
>>>
>>> does it go? what do you think guys?
>>>
>>>
>>> On Thursday, July 31, 2014 2:21:05 PM UTC+4, addic...@gmail.com wrote:

 Thanks, Stephen. nice approach. but what to do if I just moved some
 fields from one job property to another new one (not swapping them 
 entirely)

 On Tuesday, July 29, 2014 6:36:30 PM UTC+4, Stephen Connolly wrote:
>
> Note that you need to be swapping like for like... you can swap one
> Publisher for another Publisher, but you cannot swap a Publisher for a
> JobProperty
>
>
> On 29 July 2014 15:35, Stephen Connolly 
> wrote:
>
>> If you are swapping one JobProperty for another just have readResolve
>> return the correctly configured new JobProperty, e.g. see similar
>> https://github.com/jenkinsci/cloudbees-deployer-plug
>> in/blob/master/src/main/java/org/jenkins/plugins/cloudbees/
>> CloudbeesPublisher.java#L102
>>
>>
>> On 29 July 2014 14:25,  wrote:
>>
>>> thanks, slide. I have already gone through it. but I can't figure
>>> out the final solution of issue -
>>> so I can mark fields as transient and check their values at
>>> readResolve, what then? how to move these values to new job property?
>>>
>>> вторник, 29 июля 2014 г., 16:36:08 UTC+4 пользователь slide написал:

 This page, [1], has some good tips.

 slide

 1 - https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retain
 ing+backward+compatibility


 On Tue, Jul 29, 2014 at 5:30 AM,  wrote:

>  Hi, everyone. Could you please advice me what to do at the
> following case:
>
> I have one JobProperty at the old version of plugin. after some
> refactoring I have created another one job property and moved 
> attributes
> from old job property to new one.
> the issue is how to upgrade old job configurations to new one
> seamlessly?
>
> thanks in advance
>
>
>
>  --
> 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/d/optout.
>



 --
 Website: http://earl-of-code.com

>>>  --
>>> 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/d/optout.
>>>
>>
>>
>  --
>>> 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/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from

Re: how to convert persisted data from old plugin to new one??

[addict . vim]

thanks again, Stephen. Could  I ask more questions? excerpt from 
""https://wiki.jenkins-ci.org/display/JENKINS/Marking+a+new+plugin+version+as+incompatible+with+older+versions
 
says "*Hudson has an automatic data format upgrade capability*" - what does 
it mean?

I have one more issue with my final solution - after plugin update at 
runtime all fields in job configurations appear empty - after restart they 
all are filled  correctly - should I force some kind of job reloading or 
something?

thanks in advance

On Thursday, July 31, 2014 4:55:04 PM UTC+4, Stephen Connolly wrote:
>
> I worry about the startup time scanning all jobs... there can be 1000's of 
> them... better if you can have something that kicks in when the job is 
> being saved... as that way people can revert your upgrade if there is 
> something wrong without loosing data.
>
> Oh and whatever approach you take, remember to set the 
> compatibleSinceVersion to the first version with the new data layout to 
> give people the scary warning that they never read correctly
>
>
> On 31 July 2014 13:47, > wrote:
>
>> Finally I have ended with following solution.
>>
>> 1. add removed fields and mark them as transient
>> 2. register static method with @Initializer(after = 
>> InitMilestone.JOB_LOADED)
>> 3. for each job do check whether new job property exists if not create 
>> new one and move transient fields to it and then add new job property to 
>> the job
>>
>> does it go? what do you think guys?
>>
>>
>> On Thursday, July 31, 2014 2:21:05 PM UTC+4, addic...@gmail.com wrote:
>>>
>>> Thanks, Stephen. nice approach. but what to do if I just moved some 
>>> fields from one job property to another new one (not swapping them entirely)
>>>
>>> On Tuesday, July 29, 2014 6:36:30 PM UTC+4, Stephen Connolly wrote:

 Note that you need to be swapping like for like... you can swap one 
 Publisher for another Publisher, but you cannot swap a Publisher for a 
 JobProperty


 On 29 July 2014 15:35, Stephen Connolly  
 wrote:

> If you are swapping one JobProperty for another just have readResolve 
> return the correctly configured new JobProperty, e.g. see similar 
> https://github.com/jenkinsci/cloudbees-deployer-
> plugin/blob/master/src/main/java/org/jenkins/plugins/
> cloudbees/CloudbeesPublisher.java#L102
>  
>
> On 29 July 2014 14:25,  wrote:
>
>> thanks, slide. I have already gone through it. but I can't figure out 
>> the final solution of issue - 
>> so I can mark fields as transient and check their values at 
>> readResolve, what then? how to move these values to new job property?
>>
>> вторник, 29 июля 2014 г., 16:36:08 UTC+4 пользователь slide написал:
>>>
>>> This page, [1], has some good tips.
>>>
>>> slide
>>>
>>> 1 - https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retain
>>> ing+backward+compatibility
>>>
>>>
>>> On Tue, Jul 29, 2014 at 5:30 AM,  wrote:
>>>
  Hi, everyone. Could you please advice me what to do at the 
 following case:

 I have one JobProperty at the old version of plugin. after some 
 refactoring I have created another one job property and moved 
 attributes 
 from old job property to new one.
 the issue is how to upgrade old job configurations to new one 
 seamlessly?

 thanks in advance



  -- 
 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/d/optout.

>>>
>>>
>>>
>>> -- 
>>> Website: http://earl-of-code.com 
>>>
>>  -- 
>> 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/d/optout.
>>
>
>
  -- 
>> 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/d/optout.
>>
>
>

-- 
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/d/optout.

Re: UI Suggestion

[Slide]

-1 from me. I like the current behavior and since you can add the line
numbers as a plugin, why make it part of core? I also like seeing only
partial console logs since my build logs can get quite large.
On Jul 31, 2014 6:51 AM, "Andrew Gray"  wrote:

> Hi All,
>
> I have two proposals:
>
> 1. Include the LineNumbers plugin in the Jenkins core and make that the
> default behaviour for the console log screen?
>
> 2. Make the Console link in the sidebar menu and the progress bar under a
> running build navigate to:
>
> http://localhost:8080/job///*consoleFull*
>
> rather than the current:
>
> http://localhost:8080/job/TimesGuide/86/*console*
>
> For your consideration.
>
> Regards,
>
> Andrew
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Require JDK 7 to build?

[Jesse Glick]

Are people still building Jenkins core using JDK 6? I ask because it
would be helpful to be able to assume 7+:

· We could make use of 7+ APIs, especially java.nio.file.*, without
using reflection (just guarding usage via @IgnoreJRERequirement and
catching NoClassDefFoundError or the like).
· http://findbugs.sourceforge.net/ 3.0.0 *allows* building with JDK 8
(otherwise you get errors running FB analysis) but *requires* building
with at least 7.

Of course the same considerations might apply to plugin builds.

-- 
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/d/optout.

UI Suggestion

[Andrew Gray]

Hi All,

I have two proposals:

1. Include the LineNumbers plugin in the Jenkins core and make that the
default behaviour for the console log screen?

2. Make the Console link in the sidebar menu and the progress bar under a
running build navigate to:

http://localhost:8080/job///*consoleFull*

rather than the current:

http://localhost:8080/job/TimesGuide/86/*console*

For your consideration.

Regards,

Andrew

-- 
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/d/optout.

Re: How long should plugins support previous releases?

[Mark Waite]

Thanks.  I think that data from June is already enough to justify moving
the git plugin and the git client plugin from 1.509 to 1.532.


On Thu, Jul 31, 2014 at 6:55 AM, Daniel Beck  wrote:

>
> On 31.07.2014, at 12:51, Mark Waite  wrote:
>
> > How can I find the installed base numbers by version so that I can
> calculate the threshold by version?
>
> The newest numbers I have are from when 1.570 was brand new (end of June).
>
> 86144 total installs
> 74978 on 1.509 or newer (87%)
> 64564 on 1.532 or newer (75%)
> 45632 on 1.554 or newer (53%)
>
> 
>
> Unfortunately there seems to be something wrong with the job[1] generating
> similar stats[2], as it seems to not have run for almost two months,
> despite messages on IRC and the dev list.
>
> And the report generating the information above[3] isn't getting merged
> into the official stats generator.
>
> 1: https://ci.jenkins-ci.org/view/Infrastructure/job/infra_statistics/
> 2:
> http://stats.jenkins-ci.org/plugin-installation-trend/installations.json
> 3: https://github.com/jenkinsci/infra-statistics/pull/3
>
> --
> 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/d/optout.
>



-- 
Thanks!
Mark Waite

-- 
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/d/optout.

How to deactivate some logs

[Arnaud Héritier]

Hi,

  I don't know if it is due to the upgrade to Jenkins ver. 1.565.1
 but I'm noticing in my logs a lot of SEVERE errors
I didn't see before :

Jul 31, 2014 3:14:32 PM
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager
freeConnection

SEVERE: Host connection pool not found, hostConfig=HostConfiguration[host=
https://identity.exoplatform.org]


  It seems they are useless (
https://issues.apache.org/jira/browse/HTTPCLIENT-799) and due to the crowd
plugin which uses commons http client 3.x

  If in jenkins Logs Admin UI I set the logger
org.apache.commons.httpclient.MultiThreadedHttpConnectionManager to OFF it
solves my issue but I loose it when I restart jenkins.

  I tried to use an init.groovy.d script but it doesn't work (I'm not sure
why, I see it is executed but logs are here and I'm not a java logging
fan/expert)

Logger multiThreadedHttpConnectionManagerLoggerStopped = Logger.getLogger(
"org.apache.commons.httpclient.MultiThreadedHttpConnectionManager")

multiThreadedHttpConnectionManagerLoggerStopped.setLevel(Level.OFF)

LogManager.getLogManager().addLogger(multiThreadedHttpConnectionManagerLoggerStopped)

  Is there another solution to set the logger level permanently ?

  Thx.
-- 
-
Arnaud Héritier
http://aheritier.net
Mail/GTalk: aheritier AT gmail DOT com
Twitter/Skype : aheritier

-- 
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/d/optout.

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

[Marco Miller]

Indeed; and that is basically the info I added to the wiki(*) some weeks 
ago, when I experienced such troubles myself:

(*) 
https://wiki.jenkins-ci.org/display/JENKINS/Hosting+Plugins#HostingPlugins-Workingaroundcommonissues

=> wiki should have all the needed info by now.
/Marco

Le mercredi 30 juillet 2014 10:15:00 UTC-4, Stephen Connolly a écrit :
>
> there is a much simpler way to get a release:
>
> instead of doing
>
> $ mvn release:prepare release:perform 
>
> (with the -B if you are feeling YOLO)
>
> you do
>
> $ mvn org.apache.maven.plugins:maven-release-plugin:2.5:prepare 
> org.apache.maven.plugins:maven-release-plugin:2.5:perform
>
> Simples
>
>
> On 30 July 2014 14:59, Markus Pfeiffer  > wrote:
>
>> I've run into the same issue using git 1.9.1 + maven 3.2.2 on Ubuntu and 
>> git 1.8.5.2 + maven 3.1.1 on Mac. The release version is never committed 
>> and never appears in the store. I also seem to be in the same boat as 
>> Ulrich Hafner, our Jenkins plugin is in a subfolder of the git repository 
>> and none of the workarounds seem to work.
>>
>> I've used nigelm's tip and simply did a manual deploy using a 
>> combination of mvn version:set and mvn deploy. To simplify the process in 
>> the future I've written a simple bash script that others may find useful:
>>
>> #!/bin/bash
>>>
>>> # 
 
>>>
>>> NAME=<>
>>>
>>> echo Preparing $NAME for release
>>>
>>>
 # Query user for info
>>>
>>> read -p "Enter version number to use for the release: " VERSION_RELEASE
>>>
>>> read -p "Enter name for the release tag [$NAME-$VERSION_RELEASE]: " 
 TAG_RELEASE
>>>
>>> read -p "Enter version number for next development iteration: " 
 VERSION_SNAPSHOT
>>>
>>>
 if [[ -z "$TAG_RELEASE" ]]; then
>>>
>>>   TAG_RELEASE=$NAME-$VERSION_RELEASE
>>>
>>> fi
>>>
>>>
 if [[ "$VERSION_SNAPSHOT" != *-SNAPSHOT ]]; then
>>>
>>>   VERSION_SNAPSHOT=$VERSION_SNAPSHOT-SNAPSHOT
>>>
>>> fi
>>>
>>>
 # Show info for review
>>>
>>> echo
>>>
>>> echo "Release version  : $VERSION_RELEASE"
>>>
>>> echo "Tag release with : $TAG_RELEASE"
>>>
>>> echo "Next iteration   : $VERSION_SNAPSHOT"
>>>
>>> read -p "Continue (y/N)? " -s -n1 KEY
>>>
>>> echo
>>>
>>>
 if [[ "$KEY" != "y" ]]; then
>>>
>>>  echo "Aborted"
>>>
>>>  exit
>>>
>>> fi
>>>
>>>
 # Set the new version, commit, create a tag
>>>
>>> mvn versions:set -DnewVersion=$VERSION_RELEASE
>>>
>>> git add pom.xml
>>>
>>> git commit -m "prepare release $TAG_RELEASE"
>>>
>>> git tag $TAG_RELEASE
>>>
>>>
 # Deploy the new version
>>>
>>> mvn deploy
>>>
>>>
 # Set the new snapshot version, commit
>>>
>>> mvn versions:set -DnewVersion=$VERSION_SNAPSHOT
>>>
>>> git add pom.xml
>>>
>>> git commit -m "prepare for next development iteration"
>>>
>>>
 # Push changes and tags
>>>
>>> # git push
>>>
>>> # git push --tags
>>>
>>>
 # Clean up backup files
>>>
>>> # rm pom.xml.versionsBackup
>>>
>>>
 echo
>>>
>>> echo "done."
>>>
>>>
>> The push is commented out just to be on the save side.
>>  
>> -- 
>> 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/d/optout.
>>
>
>

-- 
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/d/optout.

Re: How long should plugins support previous releases?

[Daniel Beck]

On 31.07.2014, at 12:51, Mark Waite  wrote:

> How can I find the installed base numbers by version so that I can calculate 
> the threshold by version?

The newest numbers I have are from when 1.570 was brand new (end of June).

86144 total installs
74978 on 1.509 or newer (87%)
64564 on 1.532 or newer (75%)
45632 on 1.554 or newer (53%)



Unfortunately there seems to be something wrong with the job[1] generating 
similar stats[2], as it seems to not have run for almost two months, despite 
messages on IRC and the dev list.

And the report generating the information above[3] isn't getting merged into 
the official stats generator.

1: https://ci.jenkins-ci.org/view/Infrastructure/job/infra_statistics/
2: http://stats.jenkins-ci.org/plugin-installation-trend/installations.json
3: https://github.com/jenkinsci/infra-statistics/pull/3

-- 
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/d/optout.

Re: how to convert persisted data from old plugin to new one??

[Stephen Connolly]

I worry about the startup time scanning all jobs... there can be 1000's of
them... better if you can have something that kicks in when the job is
being saved... as that way people can revert your upgrade if there is
something wrong without loosing data.

Oh and whatever approach you take, remember to set the
compatibleSinceVersion to the first version with the new data layout to
give people the scary warning that they never read correctly


On 31 July 2014 13:47,  wrote:

> Finally I have ended with following solution.
>
> 1. add removed fields and mark them as transient
> 2. register static method with @Initializer(after =
> InitMilestone.JOB_LOADED)
> 3. for each job do check whether new job property exists if not create new
> one and move transient fields to it and then add new job property to the job
>
> does it go? what do you think guys?
>
>
> On Thursday, July 31, 2014 2:21:05 PM UTC+4, addic...@gmail.com wrote:
>>
>> Thanks, Stephen. nice approach. but what to do if I just moved some
>> fields from one job property to another new one (not swapping them entirely)
>>
>> On Tuesday, July 29, 2014 6:36:30 PM UTC+4, Stephen Connolly wrote:
>>>
>>> Note that you need to be swapping like for like... you can swap one
>>> Publisher for another Publisher, but you cannot swap a Publisher for a
>>> JobProperty
>>>
>>>
>>> On 29 July 2014 15:35, Stephen Connolly  wrote:
>>>
 If you are swapping one JobProperty for another just have readResolve
 return the correctly configured new JobProperty, e.g. see similar
 https://github.com/jenkinsci/cloudbees-deployer-
 plugin/blob/master/src/main/java/org/jenkins/plugins/
 cloudbees/CloudbeesPublisher.java#L102


 On 29 July 2014 14:25,  wrote:

> thanks, slide. I have already gone through it. but I can't figure out
> the final solution of issue -
> so I can mark fields as transient and check their values at
> readResolve, what then? how to move these values to new job property?
>
> вторник, 29 июля 2014 г., 16:36:08 UTC+4 пользователь slide написал:
>>
>> This page, [1], has some good tips.
>>
>> slide
>>
>> 1 - https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+retain
>> ing+backward+compatibility
>>
>>
>> On Tue, Jul 29, 2014 at 5:30 AM,  wrote:
>>
>>>  Hi, everyone. Could you please advice me what to do at the
>>> following case:
>>>
>>> I have one JobProperty at the old version of plugin. after some
>>> refactoring I have created another one job property and moved attributes
>>> from old job property to new one.
>>> the issue is how to upgrade old job configurations to new one
>>> seamlessly?
>>>
>>> thanks in advance
>>>
>>>
>>>
>>>  --
>>> 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/d/optout.
>>>
>>
>>
>>
>> --
>> Website: http://earl-of-code.com
>>
>  --
> 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/d/optout.
>


>>>  --
> 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/d/optout.
>

-- 
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/d/optout.

Re: how to convert persisted data from old plugin to new one??

[addict . vim]

Finally I have ended with following solution.

1. add removed fields and mark them as transient
2. register static method with @Initializer(after = 
InitMilestone.JOB_LOADED)
3. for each job do check whether new job property exists if not create new 
one and move transient fields to it and then add new job property to the job

does it go? what do you think guys?

On Thursday, July 31, 2014 2:21:05 PM UTC+4, addic...@gmail.com wrote:
>
> Thanks, Stephen. nice approach. but what to do if I just moved some fields 
> from one job property to another new one (not swapping them entirely)
>
> On Tuesday, July 29, 2014 6:36:30 PM UTC+4, Stephen Connolly wrote:
>>
>> Note that you need to be swapping like for like... you can swap one 
>> Publisher for another Publisher, but you cannot swap a Publisher for a 
>> JobProperty
>>
>>
>> On 29 July 2014 15:35, Stephen Connolly  wrote:
>>
>>> If you are swapping one JobProperty for another just have readResolve 
>>> return the correctly configured new JobProperty, e.g. see similar 
>>> https://github.com/jenkinsci/cloudbees-deployer-plugin/blob/master/src/main/java/org/jenkins/plugins/cloudbees/CloudbeesPublisher.java#L102
>>>  
>>>
>>> On 29 July 2014 14:25,  wrote:
>>>
 thanks, slide. I have already gone through it. but I can't figure out 
 the final solution of issue - 
 so I can mark fields as transient and check their values at 
 readResolve, what then? how to move these values to new job property?

 вторник, 29 июля 2014 г., 16:36:08 UTC+4 пользователь slide написал:
>
> This page, [1], has some good tips.
>
> slide
>
> 1 - https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+
> retaining+backward+compatibility
>
>
> On Tue, Jul 29, 2014 at 5:30 AM,  wrote:
>
>>  Hi, everyone. Could you please advice me what to do at the 
>> following case:
>>
>> I have one JobProperty at the old version of plugin. after some 
>> refactoring I have created another one job property and moved attributes 
>> from old job property to new one.
>> the issue is how to upgrade old job configurations to new one 
>> seamlessly?
>>
>> thanks in advance
>>
>>
>>
>>  -- 
>> 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/d/optout.
>>
>
>
>
> -- 
> Website: http://earl-of-code.com 
>
  -- 
 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/d/optout.

>>>
>>>
>>

-- 
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/d/optout.

Should we come up with a browser support matrix?

[Tom Fennelly]

In particular... how far back do we want to support Internet Explorer.  I 
think IE9 for sure, but what about IE8?  It's a real PITA :)

-- 
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/d/optout.

Re: Hosting for a new plugin

[Vincent Latombe]

Daniel said 1.561, so this is in the latest LTS, which is great!

Vincent


2014-07-31 14:10 GMT+02:00 Stuart Davidson :

> So that identifier, in the example, is queue id 25. If the job is queued,
> cancelled and queued again, a new identifier (26) will be used. Once a job
> leaves the queue and is building, that queue id is still accessible using
> the same restful interface and the build number is now under the
>  tag.
>
> If that's the case, this plugin is redundant - you can do all you need to
> do within the queue api.
>
> Can I ask if this is particularly new, or has it been around for a while -
> if so, when did it come in?
>
>
>  On 31 July 2014 12:59, Daniel Beck  wrote:
>
>>
>> On 31.07.2014, at 12:36, Stuart Davidson 
>> wrote:
>>
>> > As I understand it, a build could be queued, cancelled, queued again
>> and thus end up with the same build id. With this plugin, I'm appending a
>> UUID to the build in order to identify a unique run no matter what happened
>> in the queue.
>> >
>> > However, you've shown a way of uniquely identifying a build by using
>> the inQueueSince information under Location which would probably do the
>> same thing. If you check build 25 and it's got a different inQueueSince,
>> you can assume it's not the droid you are looking for.
>> >
>> > Nothing is likely to change the inQueueSince once a build joins a
>> queue, is it?
>>
>> Queue item ID is NOT the build number (that's basically the whole point
>> of my Jira comment). It's unique Jenkins-wide, probably similar to your
>> UUID.
>>
>> As you can see in the last XML snippet, it will even tell you information
>> about queue items that are no longer in the queue (, the build
>> number is at ). If cancelled from the queue, it'll be
>> true and not have an executable.
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Jenkins Developers" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/jenkinsci-dev/8nph2HKmiJA/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> jenkinsci-dev+unsubscr...@googlegroups.com.
>>
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>  --
> 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/d/optout.
>

-- 
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/d/optout.

Re: Hosting for a new plugin

[Stuart Davidson]

So that identifier, in the example, is queue id 25. If the job is queued,
cancelled and queued again, a new identifier (26) will be used. Once a job
leaves the queue and is building, that queue id is still accessible using
the same restful interface and the build number is now under the
 tag.

If that's the case, this plugin is redundant - you can do all you need to
do within the queue api.

Can I ask if this is particularly new, or has it been around for a while -
if so, when did it come in?


On 31 July 2014 12:59, Daniel Beck  wrote:

>
> On 31.07.2014, at 12:36, Stuart Davidson 
> wrote:
>
> > As I understand it, a build could be queued, cancelled, queued again and
> thus end up with the same build id. With this plugin, I'm appending a UUID
> to the build in order to identify a unique run no matter what happened in
> the queue.
> >
> > However, you've shown a way of uniquely identifying a build by using the
> inQueueSince information under Location which would probably do the same
> thing. If you check build 25 and it's got a different inQueueSince, you can
> assume it's not the droid you are looking for.
> >
> > Nothing is likely to change the inQueueSince once a build joins a queue,
> is it?
>
> Queue item ID is NOT the build number (that's basically the whole point of
> my Jira comment). It's unique Jenkins-wide, probably similar to your UUID.
>
> As you can see in the last XML snippet, it will even tell you information
> about queue items that are no longer in the queue (, the build
> number is at ). If cancelled from the queue, it'll be
> true and not have an executable.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/8nph2HKmiJA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

Re: Hosting for a new plugin

[Daniel Beck]

On 31.07.2014, at 12:36, Stuart Davidson  wrote:

> As I understand it, a build could be queued, cancelled, queued again and thus 
> end up with the same build id. With this plugin, I'm appending a UUID to the 
> build in order to identify a unique run no matter what happened in the queue.
> 
> However, you've shown a way of uniquely identifying a build by using the 
> inQueueSince information under Location which would probably do the same 
> thing. If you check build 25 and it's got a different inQueueSince, you can 
> assume it's not the droid you are looking for.
> 
> Nothing is likely to change the inQueueSince once a build joins a queue, is 
> it?

Queue item ID is NOT the build number (that's basically the whole point of my 
Jira comment). It's unique Jenkins-wide, probably similar to your UUID.

As you can see in the last XML snippet, it will even tell you information about 
queue items that are no longer in the queue (, the build number is at 
). If cancelled from the queue, it'll be true 
and not have an executable.

-- 
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/d/optout.

Re: Changing "Trigger/call builds on other projects" project names via Groovy console

[Robert Sandell]

Construct a new builder object and replace the old one, that is basically
what the save button does.

/B


2014-07-31 9:05 GMT+02:00 Amos S :

> Hello,
>
> I'm trying to change the names of projects which will be triggered by a
> build via the Groovy console.
>
> I got as far as being able to extract the field from the data structures
> but didn't find a way to set it with a new value.
>
> Here is the code I got so far:
>
> import hudson.model.*
> import hudson.model.FreeStyleProject
> import jenkins.model.Jenkins
> import hudson.plugins.parameterizedtrigger.TriggerBuilder
>
> def viewName = "v2.9"
>
> Jenkins jenkins = Jenkins.getInstance()
>
> jenkins.getView(viewName).getItems().each { item ->
> def jobName = item.getName()
> FreeStyleProject job = jenkins.getItem(jobName)
>
> job.builders.each { builder ->
> if (builder.metaClass.respondsTo(builder, "getConfigs")) {
> builder.getConfigs().each { config ->
> println("projects to build: \"" + config.getProjects() +
> "\"")
> }
> }
> }
> }
>
> so "getProjects()" returns to be the content of the field I want to
> change, here is the field I want to change:
>
>
> 
>
> How can I achieve this?
>
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

Re: Plugin id for Windows Slaves Plugin

[Fredrik Persson]

Thanks for your answer.
The problem was that I had specified the old groupId 'org.hudsonci.plugins'
where it was called windows-slaves-plugin and not 'windows-slaves' as in
the new groupId 'org.jenkins-ci.plugins'.


2014-07-31 2:13 GMT+02:00 Jesse Glick :

> On Mon, Jul 14, 2014 at 4:04 AM, Fredrik Persson 
> wrote:
> > the Jenkins plugin id "windows-slaves" differs from the maven artifact id
> > "windows-slaves-plugin". Is this correct?
>
> https://github.com/jenkinsci/windows-slaves-plugin/blob/master/pom.xml
>
> looks right to me.
>
> (I cannot look at the issue you filed since JIRA is once again dead.)
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/lavm-MKMwBQ/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

Re: How long should plugins support previous releases?

[Mark Waite]

I like the idea of selecting a threshold and not moving to a newer version
until the installed base has adopted at least that release.

How can I find the installed base numbers by version so that I can
calculate the threshold by version?

Thanks
Mark Waite


On Thu, Jul 31, 2014 at 4:24 AM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> I think the question you really need to ask yourself is what is driving
> the update.
>
> So for example there are some changes to the SCM api in 1.568... if you
> want to pick up support for them then there is really only one way to do
> that... now I would advocate waiting for those changes to hit an LTS, i.e.
> wait for the post 1.565 series, but given that the LTS gets its own update
> center it's probably not the worst crime in the world to have updates that
> require a more modern core.
>
> If you are just updating *because you can* well I would say it's best to
> decide a threshold percentage and pick the LTS version that has that sits
> with that cutoff.
>
> Plugin maintainers should pick their own threshold. I'd recommend that you
> target a version that includes at least 50% (perhaps 80-90%) as a lower
> limit to the threshold... but if you want to be a dick and only maintain
> your plugin for the bleeding edge... well see how your users respond!
>
> In CloudBees, our proprietary plugins are agressive, i.e. we will push
> releases with the baseline version being the baseline version we support...
> OTOH where there are OSS plugins and we are pushing changes we tend to be
> quite conservative (e.g. I kept credentials based on 1.424 for a *very*
> long time, only moving off when there was both good reason - to fix some UI
> issues - and switching to the fix version would retain >95% of
> installations) as we recognise that the community has needs that may differ
> from our own.
>
>
> On 31 July 2014 00:18, Mark Waite  wrote:
>
>> The git plugin and the git-client plugin are both currently based on the
>> 1.509 release.  That was first released 15 months ago.
>>
>> Since those two plugins seem to be used in approximately half the
>> reported Jenkins installations, they should support multiple releases.  How
>> long a "back level support" is reasonable?
>>
>> How would I assess the risk to users of switching the base release from
>> 1.509 to 1.532?
>>
>> --
>> Thanks!
>> Mark Waite
>>
>> --
>> 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/d/optout.
>>
>
>  --
> 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/d/optout.
>



-- 
Thanks!
Mark Waite

-- 
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/d/optout.

Re: Hosting for a new plugin

[Stuart Davidson]

As I understand it, a build could be queued, cancelled, queued again and
thus end up with the same build id. With this plugin, I'm appending a UUID
to the build in order to identify a unique run no matter what happened in
the queue.

However, you've shown a way of uniquely identifying a build by using the
inQueueSince information under Location which would probably do the same
thing. If you check build 25 and it's got a different inQueueSince, you can
assume it's not the droid you are looking for.

Nothing is likely to change the inQueueSince once a build joins a queue, is
it?


On 31 July 2014 11:19, Daniel Beck  wrote:

>
> On 31.07.2014, at 12:19, Stuart Davidson 
> wrote:
>
> > I've not touched this in a while Daniel, but I found that if I was
> queuing multiple copies of the same job, I could give it a unique ID -
> whereas /build simply gives you the information it's queuing.
> >
> > That's not to say that the queue API has improved to include information
> like this - like I say, it's been a while :)
>
> This was changed for parameterized builds in 1.561 to match the behavior
> for unparameterized builds. Example how the core API works is in this Jira
> comment:
>
>
> https://issues.jenkins-ci.org/browse/JENKINS-12827?focusedCommentId=201381&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-201381
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/8nph2HKmiJA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

Re: How long should plugins support previous releases?

[Stephen Connolly]

I think the question you really need to ask yourself is what is driving the
update.

So for example there are some changes to the SCM api in 1.568... if you
want to pick up support for them then there is really only one way to do
that... now I would advocate waiting for those changes to hit an LTS, i.e.
wait for the post 1.565 series, but given that the LTS gets its own update
center it's probably not the worst crime in the world to have updates that
require a more modern core.

If you are just updating *because you can* well I would say it's best to
decide a threshold percentage and pick the LTS version that has that sits
with that cutoff.

Plugin maintainers should pick their own threshold. I'd recommend that you
target a version that includes at least 50% (perhaps 80-90%) as a lower
limit to the threshold... but if you want to be a dick and only maintain
your plugin for the bleeding edge... well see how your users respond!

In CloudBees, our proprietary plugins are agressive, i.e. we will push
releases with the baseline version being the baseline version we support...
OTOH where there are OSS plugins and we are pushing changes we tend to be
quite conservative (e.g. I kept credentials based on 1.424 for a *very*
long time, only moving off when there was both good reason - to fix some UI
issues - and switching to the fix version would retain >95% of
installations) as we recognise that the community has needs that may differ
from our own.


On 31 July 2014 00:18, Mark Waite  wrote:

> The git plugin and the git-client plugin are both currently based on the
> 1.509 release.  That was first released 15 months ago.
>
> Since those two plugins seem to be used in approximately half the reported
> Jenkins installations, they should support multiple releases.  How long a
> "back level support" is reasonable?
>
> How would I assess the risk to users of switching the base release from
> 1.509 to 1.532?
>
> --
> Thanks!
> Mark Waite
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

Re: Hosting for a new plugin

[Daniel Beck]

On 31.07.2014, at 12:19, Stuart Davidson  wrote:

> I've not touched this in a while Daniel, but I found that if I was queuing 
> multiple copies of the same job, I could give it a unique ID - whereas /build 
> simply gives you the information it's queuing. 
> 
> That's not to say that the queue API has improved to include information like 
> this - like I say, it's been a while :)

This was changed for parameterized builds in 1.561 to match the behavior for 
unparameterized builds. Example how the core API works is in this Jira comment:

https://issues.jenkins-ci.org/browse/JENKINS-12827?focusedCommentId=201381&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-201381

-- 
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/d/optout.

Re: how to convert persisted data from old plugin to new one??

[addict . vim]

Thanks, Stephen. nice approach. but what to do if I just moved some fields 
from one job property to another new one (not swapping them entirely)

On Tuesday, July 29, 2014 6:36:30 PM UTC+4, Stephen Connolly wrote:
>
> Note that you need to be swapping like for like... you can swap one 
> Publisher for another Publisher, but you cannot swap a Publisher for a 
> JobProperty
>
>
> On 29 July 2014 15:35, Stephen Connolly  > wrote:
>
>> If you are swapping one JobProperty for another just have readResolve 
>> return the correctly configured new JobProperty, e.g. see similar 
>> https://github.com/jenkinsci/cloudbees-deployer-plugin/blob/master/src/main/java/org/jenkins/plugins/cloudbees/CloudbeesPublisher.java#L102
>>  
>>
>> On 29 July 2014 14:25, > wrote:
>>
>>> thanks, slide. I have already gone through it. but I can't figure out 
>>> the final solution of issue - 
>>> so I can mark fields as transient and check their values at readResolve, 
>>> what then? how to move these values to new job property?
>>>
>>> вторник, 29 июля 2014 г., 16:36:08 UTC+4 пользователь slide написал:

 This page, [1], has some good tips.

 slide

 1 - https://wiki.jenkins-ci.org/display/JENKINS/Hint+on+
 retaining+backward+compatibility


 On Tue, Jul 29, 2014 at 5:30 AM,  wrote:

>  Hi, everyone. Could you please advice me what to do at the following 
> case:
>
> I have one JobProperty at the old version of plugin. after some 
> refactoring I have created another one job property and moved attributes 
> from old job property to new one.
> the issue is how to upgrade old job configurations to new one 
> seamlessly?
>
> thanks in advance
>
>
>
>  -- 
> 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/d/optout.
>



 -- 
 Website: http://earl-of-code.com 

>>>  -- 
>>> 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/d/optout.
>>>
>>
>>
>

-- 
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/d/optout.

Re: Hosting for a new plugin

[Stuart Davidson]

I've not touched this in a while Daniel, but I found that if I was queuing
multiple copies of the same job, I could give it a unique ID - whereas
/build simply gives you the information it's queuing.

That's not to say that the queue API has improved to include information
like this - like I say, it's been a while :)


On 31 July 2014 11:08, Daniel Beck  wrote:

>
> On 21.11.2013, at 20:01, Stuart Davidson 
> wrote:
>
> > The plugin allows you to request a build from the API but it returns a
> JSON snippet with a UUID for the job. This allows you to track the status
> of a job (using another part of the API) even before it has left the queue
> and has been assigned a run id - being in the queue is a valid state.
>
> How is this plugin different from the queue item API whose ID/location is
> provided in the Location header from /build?
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/8nph2HKmiJA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

Re: Hosting for a new plugin

[Daniel Beck]

On 21.11.2013, at 20:01, Stuart Davidson  wrote:

> The plugin allows you to request a build from the API but it returns a JSON 
> snippet with a UUID for the job. This allows you to track the status of a job 
> (using another part of the API) even before it has left the queue and has 
> been assigned a run id - being in the queue is a valid state.

How is this plugin different from the queue item API whose ID/location is 
provided in the Location header from /build?

-- 
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/d/optout.

Re: Hosting for a new plugin

[Stuart Davidson]

Hi Vincent!

Thanks for getting in touch. Yeah, I always meant to get round to
officially releasing it - the code was here, I was just tidying it up.

If you want to pass my e-mail along, I can talk to them directly and make
sure it does what they are looking for.

Stu


On 31 July 2014 10:23, Vincent Latombe  wrote:

> Hi Stuart,
>
> some pinged me today about your plugin, it appears very useful. Maybe it
> could be worth to release it properly to have more people know about it and
> let them install it directly from the plugin manager?
>
> If you need some help with that I can give a hand.
>
> Cheers,
>
> Vincent
>
>
> 2013-11-21 22:19 GMT+01:00 Ulli Hafner :
>
> New github repository created at
>> https://github.com/jenkinsci/job-run-uuid-plugin
>>
>> Welcome aboard!
>>
>> Ulli
>>
>> Am 21.11.2013 um 20:01 schrieb Stuart Davidson <
>> stuart.david...@spedge.com>:
>>
>> Hi there,
>>
>> I'd like to use the official Jenkins repo to publish a new plugin for
>> executing a build remotely.
>>
>> The plugin allows you to request a build from the API but it returns a
>> JSON snippet with a UUID for the job. This allows you to track the status
>> of a job (using another part of the API) even before it has left the
>> queue and has been assigned a run id - being in the queue is a valid state.
>>
>> I've found it very useful for executing batches (100+) of the same job
>> but with different parameters, then tracking the status of them as they get
>> completed.
>>
>> Please could you create a jenkins/job-run-uuid repo in Github, my github
>> id is spedge.
>>
>> I'm also happy to listen to any suggestions or recommendations for this :)
>>
>> Thanks,
>>
>> Stuart
>>
>>
>> --
>> 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 a topic in the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/jenkinsci-dev/8nph2HKmiJA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> jenkinsci-dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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/d/optout.

Re: "Jenkins Workflow Summit" to go with JUC Bay Area?

[Emanuele Zattin]

Sounds like a great idea Kohsuke!

Emanuele Zattin
---
-I don't have to know an answer. I don't feel frightened by not knowing
things; by being lost in a mysterious universe without any purpose — which
is the way it really is, as far as I can tell, possibly. It doesn't
frighten me.- Richard Feynman


On Thu, Jul 31, 2014 at 11:41 AM, James Nord (jnord) 
wrote:

> Hi Kohsuke et al.
>
> I'm defiantly interested in the workflow brainstorming/hacking/discussing
> etc. assuming I get travel approval.
>
> Having something focused is easier to get approved rather than a generic
> unconference.
>
> /James
>
> > -Original Message-
> > From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-
> > d...@googlegroups.com] On Behalf Of Kohsuke Kawaguchi
> > Sent: 30 July 2014 22:31
> > To: Jenkins Dev; eve...@lists.jenkins-ci.org
> > Subject: "Jenkins Workflow Summit" to go with JUC Bay Area?
> >
> >
> > Some of you were in the Jenkins Scalability Summit last year [1,2,3].
> > I'm trying to see if we can do a similar one this year back to back with
> JUC Bay
> > Area.
> >
> > To recap, the idea of the scalability summit was to have a small number
> of
> > serious active users/developers in the room, to deep dive into Jenkins.
> The
> > last year the event was themed around scalability and was run in part
> like an
> > unconference, where the attendees have collectively decided on the agenda
> > for the day.
> >
> > We could keep the same theme this year, but someone suggested to me
> > that since workflow is a big focus this year, maybe that could be the
> theme.
> > I can easily picture Jesse and I presenting technical details of various
> parts of
> > the workflow plugin, people sharing and collecting real-world use cases,
> > brainstorming around enhancements / roadmap, maybe even a workshop of
> > getting extensions implemented.
> >
> >
> > Is something like this interesting for you? Is it worth doing?
> >
> >
> > (Another suggestion was to just turn it into a full-blown unconference.
> > Namely, don't have any particular theme, and allow anyone who wants to
> > come to come. We'll just let attendees dictate the topics. The only
> problem I
> > have with this is that we need a lot bigger venue, which is hard to come
> by,
> > so unless somebody local in the bay area shows up and sponsors a suitable
> > venue, I don't think this is happening.)
> >
> >
> > [1]
> > https://wiki.jenkins-
> > ci.org/display/JENKINS/Jenkins+Scalability+Summit+2013
> > [2] http://jenkins-ci.org/content/jenkins-scalability-summit-recap
> > [3]
> > https://docs.google.com/document/d/1GqkWPnp-
> > bvuObGlSe7t3k76ZOD2a8Z2M1avggWoYKEs/edit
> > --
> > Kohsuke Kawaguchi  http://kohsuke.org/
> >
> > --
> > 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/d/optout.
>
> --
> 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/d/optout.
>

-- 
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/d/optout.

RE: "Jenkins Workflow Summit" to go with JUC Bay Area?

[James Nord (jnord)]

Hi Kohsuke et al.

I'm defiantly interested in the workflow brainstorming/hacking/discussing etc. 
assuming I get travel approval.

Having something focused is easier to get approved rather than a generic 
unconference.

/James

> -Original Message-
> From: jenkinsci-dev@googlegroups.com [mailto:jenkinsci-
> d...@googlegroups.com] On Behalf Of Kohsuke Kawaguchi
> Sent: 30 July 2014 22:31
> To: Jenkins Dev; eve...@lists.jenkins-ci.org
> Subject: "Jenkins Workflow Summit" to go with JUC Bay Area?
> 
> 
> Some of you were in the Jenkins Scalability Summit last year [1,2,3].
> I'm trying to see if we can do a similar one this year back to back with JUC 
> Bay
> Area.
> 
> To recap, the idea of the scalability summit was to have a small number of
> serious active users/developers in the room, to deep dive into Jenkins. The
> last year the event was themed around scalability and was run in part like an
> unconference, where the attendees have collectively decided on the agenda
> for the day.
> 
> We could keep the same theme this year, but someone suggested to me
> that since workflow is a big focus this year, maybe that could be the theme.
> I can easily picture Jesse and I presenting technical details of various 
> parts of
> the workflow plugin, people sharing and collecting real-world use cases,
> brainstorming around enhancements / roadmap, maybe even a workshop of
> getting extensions implemented.
> 
> 
> Is something like this interesting for you? Is it worth doing?
> 
> 
> (Another suggestion was to just turn it into a full-blown unconference.
> Namely, don't have any particular theme, and allow anyone who wants to
> come to come. We'll just let attendees dictate the topics. The only problem I
> have with this is that we need a lot bigger venue, which is hard to come by,
> so unless somebody local in the bay area shows up and sponsors a suitable
> venue, I don't think this is happening.)
> 
> 
> [1]
> https://wiki.jenkins-
> ci.org/display/JENKINS/Jenkins+Scalability+Summit+2013
> [2] http://jenkins-ci.org/content/jenkins-scalability-summit-recap
> [3]
> https://docs.google.com/document/d/1GqkWPnp-
> bvuObGlSe7t3k76ZOD2a8Z2M1avggWoYKEs/edit
> --
> Kohsuke Kawaguchi  http://kohsuke.org/
> 
> --
> 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/d/optout.

-- 
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/d/optout.

Re: Hosting for a new plugin

[Vincent Latombe]

Hi Stuart,

some pinged me today about your plugin, it appears very useful. Maybe it
could be worth to release it properly to have more people know about it and
let them install it directly from the plugin manager?

If you need some help with that I can give a hand.

Cheers,

Vincent


2013-11-21 22:19 GMT+01:00 Ulli Hafner :

> New github repository created at
> https://github.com/jenkinsci/job-run-uuid-plugin
>
> Welcome aboard!
>
> Ulli
>
> Am 21.11.2013 um 20:01 schrieb Stuart Davidson  >:
>
> Hi there,
>
> I'd like to use the official Jenkins repo to publish a new plugin for
> executing a build remotely.
>
> The plugin allows you to request a build from the API but it returns a
> JSON snippet with a UUID for the job. This allows you to track the status
> of a job (using another part of the API) even before it has left the
> queue and has been assigned a run id - being in the queue is a valid state.
>
> I've found it very useful for executing batches (100+) of the same job but
> with different parameters, then tracking the status of them as they get
> completed.
>
> Please could you create a jenkins/job-run-uuid repo in Github, my github
> id is spedge.
>
> I'm also happy to listen to any suggestions or recommendations for this :)
>
> Thanks,
>
> Stuart
>
>
> --
> 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/d/optout.

Changing "Trigger/call builds on other projects" project names via Groovy console

[Amos S]

Hello,

I'm trying to change the names of projects which will be triggered by a 
build via the Groovy console.

I got as far as being able to extract the field from the data structures 
but didn't find a way to set it with a new value.

Here is the code I got so far:

import hudson.model.*
import hudson.model.FreeStyleProject
import jenkins.model.Jenkins
import hudson.plugins.parameterizedtrigger.TriggerBuilder

def viewName = "v2.9"

Jenkins jenkins = Jenkins.getInstance()

jenkins.getView(viewName).getItems().each { item ->
def jobName = item.getName()
FreeStyleProject job = jenkins.getItem(jobName)

job.builders.each { builder ->
if (builder.metaClass.respondsTo(builder, "getConfigs")) {
builder.getConfigs().each { config ->
println("projects to build: \"" + config.getProjects() + 
"\"")
}
}
}
}

so "getProjects()" returns to be the content of the field I want to change, 
here is the field I want to change:



How can I achieve this?

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.
For more options, visit https://groups.google.com/d/optout.