Bulk updates

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Bulk updates

Arnaud Héritier-2
Hi all,

  I wanted to discuss about a really annoying missing feature : The bulk update of jobs.
  We have plugins to use templates when we create a new job, or to update some fields like in slicing configuration.
  It is good but not enough.
  In theory, we don't have to do a bulk update really often but when we have to do it, it is just a nightmare when you have several dozen of jobs.
  Yesterday I installed the mail-ext plugin to customize emails sent to my teams. The installation was easy, like always, but I add to update all jobs to enable it eveywhere :-( (and I have to end this morning).
  Many tools like Jira, or Bamboo added a bulk update operation which allow to override in a set of jobs a given number of parameters.
  Isn't it something we could imagine to add ?
  I could try to participate if need.

  Another solution instead having a bulk feature is to have an inheritance mechanism with the ability to update one "abstract" parent and to automatically update children.

  I never had a look at your code and your architecture thus it is perhaps impossible or it too expensive to do ?

  I don't know but I'm interested to exchange about this.

  Cheers,

Arnaud Héritier
---
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
Apache Maven PMC
Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Romain Seguy
Hi Arnaud,

To update your jobs, what about using the Groovy script console to run an arbitrary script? ==> https://.../hudson/script

Regards,
Romain

Le 18 février 2010 10:18, Arnaud Héritier <[hidden email]> a écrit :
Hi all,

  I wanted to discuss about a really annoying missing feature : The bulk update of jobs.
  We have plugins to use templates when we create a new job, or to update some fields like in slicing configuration.
  It is good but not enough.
  In theory, we don't have to do a bulk update really often but when we have to do it, it is just a nightmare when you have several dozen of jobs.
  Yesterday I installed the mail-ext plugin to customize emails sent to my teams. The installation was easy, like always, but I add to update all jobs to enable it eveywhere :-( (and I have to end this morning).
  Many tools like Jira, or Bamboo added a bulk update operation which allow to override in a set of jobs a given number of parameters.
  Isn't it something we could imagine to add ?
  I could try to participate if need.

  Another solution instead having a bulk feature is to have an inheritance mechanism with the ability to update one "abstract" parent and to automatically update children.

  I never had a look at your code and your architecture thus it is perhaps impossible or it too expensive to do ?

  I don't know but I'm interested to exchange about this.

  Cheers,

Arnaud Héritier
---
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
Apache Maven PMC

Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Arnaud Héritier
Yes it is also possible.
I already did it but in bash/grep/sed/...
In that case it isn't easy but I think it is possible to do with groovy.

I have to remove this sort of block
  <reporters>
    <hudson.maven.reporters.MavenMailer>
      <recipients>XXXXXXX</recipients>
      <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
      <sendToIndividuals>false</sendToIndividuals>
    </hudson.maven.reporters.MavenMailer>
  </reporters>
And add this one
  <publishers>
    <hudson.plugins.jira.JiraIssueUpdater/>
    <hudson.plugins.emailext.ExtendedEmailPublisher>
      <recipientList></recipientList>
      <configuredTriggers>
        <hudson.plugins.emailext.plugins.trigger.FailureTrigger>
          <email>
            <recipientList></recipientList>
            <subject>$PROJECT_DEFAULT_SUBJECT</subject>
            <body>$PROJECT_DEFAULT_CONTENT</body>
            <sendToDevelopers>true</sendToDevelopers>
            <includeCulprits>false</includeCulprits>
            <sendToRecipientList>true</sendToRecipientList>
          </email>
        </hudson.plugins.emailext.plugins.trigger.FailureTrigger>
      </configuredTriggers>
      <contentType>default</contentType>
      <defaultSubject>$DEFAULT_SUBJECT</defaultSubject>
      <defaultContent>$DEFAULT_CONTENT</defaultContent>
    </hudson.plugins.emailext.ExtendedEmailPublisher>
  </publishers>
After copying the recipient list from the old to the new one

And it must be a little bit different for freestyle jobs (I have few of them because of issues on the maven 2 integration)



On Thu, Feb 18, 2010 at 10:47 AM, Romain Seguy <[hidden email]> wrote:
Hi Arnaud,

To update your jobs, what about using the Groovy script console to run an arbitrary script? ==> https://.../hudson/script

Regards,
Romain

Le 18 février 2010 10:18, Arnaud Héritier <[hidden email]> a écrit :
Hi all,

  I wanted to discuss about a really annoying missing feature : The bulk update of jobs.
  We have plugins to use templates when we create a new job, or to update some fields like in slicing configuration.
  It is good but not enough.
  In theory, we don't have to do a bulk update really often but when we have to do it, it is just a nightmare when you have several dozen of jobs.
  Yesterday I installed the mail-ext plugin to customize emails sent to my teams. The installation was easy, like always, but I add to update all jobs to enable it eveywhere :-( (and I have to end this morning).
  Many tools like Jira, or Bamboo added a bulk update operation which allow to override in a set of jobs a given number of parameters.
  Isn't it something we could imagine to add ?
  I could try to participate if need.

  Another solution instead having a bulk feature is to have an inheritance mechanism with the ability to update one "abstract" parent and to automatically update children.

  I never had a look at your code and your architecture thus it is perhaps impossible or it too expensive to do ?

  I don't know but I'm interested to exchange about this.

  Cheers,

Arnaud Héritier
---
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
Apache Maven PMC


Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Romain Seguy
Re,

I'm not a Groovy expert, but a little script like this can be useful to remove some publishers on a freestyle project:

for(item in hudson.model.Hudson.instance.items) {
  for(publisher in item.publishersList) {
    for(describable in publisher) {
      if(describable.descriptor.displayName == "Continuous Integration game") {
        println("Removing publisher " + describable.descriptor.displayName  + " from " + item.name)
        item.publishersList.remove(describable.descriptor)
      }
    }
  }
}

This one is dirty (and it removes the Continuous Integration Game publisher) since it removed publishers based on their display name, there are also surely some faster paths to access the publishers, but it works fine.

I'm sorry to not help on Maven jobs (knowing that you obviously love it ;-)) but I don't use it.

HTH,
Romain

Le 18 février 2010 11:11, Arnaud Héritier <[hidden email]> a écrit :
Yes it is also possible.
I already did it but in bash/grep/sed/...
In that case it isn't easy but I think it is possible to do with groovy.

I have to remove this sort of block
  <reporters>
    <hudson.maven.reporters.MavenMailer>
      <recipients>XXXXXXX</recipients>
      <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
      <sendToIndividuals>false</sendToIndividuals>
    </hudson.maven.reporters.MavenMailer>
  </reporters>
And add this one
  <publishers>
    <hudson.plugins.jira.JiraIssueUpdater/>
    <hudson.plugins.emailext.ExtendedEmailPublisher>
      <recipientList></recipientList>
      <configuredTriggers>
        <hudson.plugins.emailext.plugins.trigger.FailureTrigger>
          <email>
            <recipientList></recipientList>
            <subject>$PROJECT_DEFAULT_SUBJECT</subject>
            <body>$PROJECT_DEFAULT_CONTENT</body>
            <sendToDevelopers>true</sendToDevelopers>
            <includeCulprits>false</includeCulprits>
            <sendToRecipientList>true</sendToRecipientList>
          </email>
        </hudson.plugins.emailext.plugins.trigger.FailureTrigger>
      </configuredTriggers>
      <contentType>default</contentType>
      <defaultSubject>$DEFAULT_SUBJECT</defaultSubject>
      <defaultContent>$DEFAULT_CONTENT</defaultContent>
    </hudson.plugins.emailext.ExtendedEmailPublisher>
  </publishers>
After copying the recipient list from the old to the new one

And it must be a little bit different for freestyle jobs (I have few of them because of issues on the maven 2 integration)



On Thu, Feb 18, 2010 at 10:47 AM, Romain Seguy <[hidden email]> wrote:
Hi Arnaud,

To update your jobs, what about using the Groovy script console to run an arbitrary script? ==> https://.../hudson/script

Regards,
Romain

Le 18 février 2010 10:18, Arnaud Héritier <[hidden email]> a écrit :
Hi all,

  I wanted to discuss about a really annoying missing feature : The bulk update of jobs.
  We have plugins to use templates when we create a new job, or to update some fields like in slicing configuration.
  It is good but not enough.
  In theory, we don't have to do a bulk update really often but when we have to do it, it is just a nightmare when you have several dozen of jobs.
  Yesterday I installed the mail-ext plugin to customize emails sent to my teams. The installation was easy, like always, but I add to update all jobs to enable it eveywhere :-( (and I have to end this morning).
  Many tools like Jira, or Bamboo added a bulk update operation which allow to override in a set of jobs a given number of parameters.
  Isn't it something we could imagine to add ?
  I could try to participate if need.

  Another solution instead having a bulk feature is to have an inheritance mechanism with the ability to update one "abstract" parent and to automatically update children.

  I never had a look at your code and your architecture thus it is perhaps impossible or it too expensive to do ?

  I don't know but I'm interested to exchange about this.

  Cheers,

Arnaud Héritier
---
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
Apache Maven PMC



Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Arnaud Héritier
On Thu, Feb 18, 2010 at 3:00 PM, Romain Seguy <[hidden email]> wrote:
Re,

I'm not a Groovy expert, but a little script like this can be useful to remove some publishers on a freestyle project:

for(item in hudson.model.Hudson.instance.items) {
  for(publisher in item.publishersList) {
    for(describable in publisher) {
      if(describable.descriptor.displayName == "Continuous Integration game") {
        println("Removing publisher " + describable.descriptor.displayName  + " from " + item.name)
        item.publishersList.remove(describable.descriptor)
      }
    }
  }
}

This one is dirty (and it removes the Continuous Integration Game publisher) since it removed publishers based on their display name, there are also surely some faster paths to access the publishers, but it works fine.

Cool, I will try to adapt it to my own need. I'll publish it.
 
I'm sorry to not help on Maven jobs (knowing that you obviously love it ;-)) but I don't use it.

Current issues are not easy to find and fix.
I'll try to have a look at them.
I would like to be able to use only them
 

HTH,
Romain

Le 18 février 2010 11:11, Arnaud Héritier <[hidden email]> a écrit :

Yes it is also possible.
I already did it but in bash/grep/sed/...
In that case it isn't easy but I think it is possible to do with groovy.

I have to remove this sort of block
  <reporters>
    <hudson.maven.reporters.MavenMailer>
      <recipients>XXXXXXX</recipients>
      <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
      <sendToIndividuals>false</sendToIndividuals>
    </hudson.maven.reporters.MavenMailer>
  </reporters>
And add this one
  <publishers>
    <hudson.plugins.jira.JiraIssueUpdater/>
    <hudson.plugins.emailext.ExtendedEmailPublisher>
      <recipientList></recipientList>
      <configuredTriggers>
        <hudson.plugins.emailext.plugins.trigger.FailureTrigger>
          <email>
            <recipientList></recipientList>
            <subject>$PROJECT_DEFAULT_SUBJECT</subject>
            <body>$PROJECT_DEFAULT_CONTENT</body>
            <sendToDevelopers>true</sendToDevelopers>
            <includeCulprits>false</includeCulprits>
            <sendToRecipientList>true</sendToRecipientList>
          </email>
        </hudson.plugins.emailext.plugins.trigger.FailureTrigger>
      </configuredTriggers>
      <contentType>default</contentType>
      <defaultSubject>$DEFAULT_SUBJECT</defaultSubject>
      <defaultContent>$DEFAULT_CONTENT</defaultContent>
    </hudson.plugins.emailext.ExtendedEmailPublisher>
  </publishers>
After copying the recipient list from the old to the new one

And it must be a little bit different for freestyle jobs (I have few of them because of issues on the maven 2 integration)



On Thu, Feb 18, 2010 at 10:47 AM, Romain Seguy <[hidden email]> wrote:
Hi Arnaud,

To update your jobs, what about using the Groovy script console to run an arbitrary script? ==> https://.../hudson/script

Regards,
Romain

Le 18 février 2010 10:18, Arnaud Héritier <[hidden email]> a écrit :
Hi all,

  I wanted to discuss about a really annoying missing feature : The bulk update of jobs.
  We have plugins to use templates when we create a new job, or to update some fields like in slicing configuration.
  It is good but not enough.
  In theory, we don't have to do a bulk update really often but when we have to do it, it is just a nightmare when you have several dozen of jobs.
  Yesterday I installed the mail-ext plugin to customize emails sent to my teams. The installation was easy, like always, but I add to update all jobs to enable it eveywhere :-( (and I have to end this morning).
  Many tools like Jira, or Bamboo added a bulk update operation which allow to override in a set of jobs a given number of parameters.
  Isn't it something we could imagine to add ?
  I could try to participate if need.

  Another solution instead having a bulk feature is to have an inheritance mechanism with the ability to update one "abstract" parent and to automatically update children.

  I never had a look at your code and your architecture thus it is perhaps impossible or it too expensive to do ?

  I don't know but I'm interested to exchange about this.

  Cheers,

Arnaud Héritier
---
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
Apache Maven PMC




Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Arnaud Héritier
Here is the script I wrote to replace standard notifications in Freestyle and Maven projects by the Mail Ext Publisher. This script also activate the Jira plugin to update issues.
Perhaps it could help someone else in the future
I think I'm not using all the power of Groovy to have a more readable code and I'm not sure I'm using Hudson APIs like I should (It is the first time I'm using it)

import hudson.plugins.emailext.* import hudson.plugins.emailext.plugins.trigger.* import hudson.plugins.jira.* import hudson.model.* import hudson.maven.* import hudson.maven.reporters.* import hudson.tasks.* // For each project for(item in Hudson.instance.items) { def recipients println("JOB : "+item.name); // Find current recipients defined in project if(item instanceof MavenModuleSet) { println(">MAVEN MODULE SET"); // Search for Maven Mailer Reporter println(">>Reporters"); for(reporter in item.reporters) { println(">>> "+reporter); if(reporter instanceof MavenMailer) { recipients = reporter.recipients // remove it item.reporters.remove(reporter) } } } else if(item instanceof FreeStyleProject) { println(">FREESTYLE PROJECT"); } println(">>Publishers"); for(publisher in item.publishersList) { println(">>> "+publisher); // Search for default Mailer Publisher if(publisher instanceof Mailer) { recipients = publisher.recipients // remove it item.publishersList.remove(publisher) } else // Or for Extended Email Publisher if(publisher instanceof ExtendedEmailPublisher) { recipients = publisher.recipientList item.publishers.remove(publisher) // remove it item.publishersList.remove(publisher) } } // If we found recipients list to send mail if(recipients!=null){ println (">CURRENT RECIPIENT : "+recipients) // We create a new Extended Email Publisher def eep = new ExtendedEmailPublisher(); eep.recipientList = recipients eep.defaultSubject = "\$DEFAULT_SUBJECT" eep.defaultContent = "\$DEFAULT_CONTENT" // With some triggers eep.configuredTriggers.add(new FailureTrigger(email : new EmailType(sendToRecipientList : true, body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) eep.configuredTriggers.add(new FixedTrigger(email : new EmailType(sendToRecipientList : true, body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) eep.configuredTriggers.add(new StillFailingTrigger(email : new EmailType(sendToRecipientList : true, body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) eep.configuredTriggers.add(new StillUnstableTrigger(email : new EmailType(sendToRecipientList : true, body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) eep.configuredTriggers.add(new UnstableTrigger(email : new EmailType(sendToRecipientList : true, body : ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject : ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) // And we add/replace it in the project item.publishersList.replace(eep); }else{ println (">NO RECIPIENT") } // We add Jira Publisher item.publishersList.replace(new JiraIssueUpdater()) println("\n=======\n"); }


Cheers,

Arnaud

2010/2/18 Arnaud Héritier <[hidden email]>
On Thu, Feb 18, 2010 at 3:00 PM, Romain Seguy <[hidden email]> wrote:
Re,

I'm not a Groovy expert, but a little script like this can be useful to remove some publishers on a freestyle project:

for(item in hudson.model.Hudson.instance.items) {
  for(publisher in item.publishersList) {
    for(describable in publisher) {
      if(describable.descriptor.displayName == "Continuous Integration game") {
        println("Removing publisher " + describable.descriptor.displayName  + " from " + item.name)
        item.publishersList.remove(describable.descriptor)
      }
    }
  }
}

This one is dirty (and it removes the Continuous Integration Game publisher) since it removed publishers based on their display name, there are also surely some faster paths to access the publishers, but it works fine.

Cool, I will try to adapt it to my own need. I'll publish it.
 
I'm sorry to not help on Maven jobs (knowing that you obviously love it ;-)) but I don't use it.

Current issues are not easy to find and fix.
I'll try to have a look at them.
I would like to be able to use only them
 

HTH,
Romain

Le 18 février 2010 11:11, Arnaud Héritier <[hidden email]> a écrit :

Yes it is also possible.
I already did it but in bash/grep/sed/...
In that case it isn't easy but I think it is possible to do with groovy.

I have to remove this sort of block
  <reporters>
    <hudson.maven.reporters.MavenMailer>
      <recipients>XXXXXXX</recipients>
      <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
      <sendToIndividuals>false</sendToIndividuals>
    </hudson.maven.reporters.MavenMailer>
  </reporters>
And add this one
  <publishers>
    <hudson.plugins.jira.JiraIssueUpdater/>
    <hudson.plugins.emailext.ExtendedEmailPublisher>
      <recipientList></recipientList>
      <configuredTriggers>
        <hudson.plugins.emailext.plugins.trigger.FailureTrigger>
          <email>
            <recipientList></recipientList>
            <subject>$PROJECT_DEFAULT_SUBJECT</subject>
            <body>$PROJECT_DEFAULT_CONTENT</body>
            <sendToDevelopers>true</sendToDevelopers>
            <includeCulprits>false</includeCulprits>
            <sendToRecipientList>true</sendToRecipientList>
          </email>
        </hudson.plugins.emailext.plugins.trigger.FailureTrigger>
      </configuredTriggers>
      <contentType>default</contentType>
      <defaultSubject>$DEFAULT_SUBJECT</defaultSubject>
      <defaultContent>$DEFAULT_CONTENT</defaultContent>
    </hudson.plugins.emailext.ExtendedEmailPublisher>
  </publishers>
After copying the recipient list from the old to the new one

And it must be a little bit different for freestyle jobs (I have few of them because of issues on the maven 2 integration)



On Thu, Feb 18, 2010 at 10:47 AM, Romain Seguy <[hidden email]> wrote:
Hi Arnaud,

To update your jobs, what about using the Groovy script console to run an arbitrary script? ==> https://.../hudson/script

Regards,
Romain

Le 18 février 2010 10:18, Arnaud Héritier <[hidden email]> a écrit :
Hi all,

  I wanted to discuss about a really annoying missing feature : The bulk update of jobs.
  We have plugins to use templates when we create a new job, or to update some fields like in slicing configuration.
  It is good but not enough.
  In theory, we don't have to do a bulk update really often but when we have to do it, it is just a nightmare when you have several dozen of jobs.
  Yesterday I installed the mail-ext plugin to customize emails sent to my teams. The installation was easy, like always, but I add to update all jobs to enable it eveywhere :-( (and I have to end this morning).
  Many tools like Jira, or Bamboo added a bulk update operation which allow to override in a set of jobs a given number of parameters.
  Isn't it something we could imagine to add ?
  I could try to participate if need.

  Another solution instead having a bulk feature is to have an inheritance mechanism with the ability to update one "abstract" parent and to automatically update children.

  I never had a look at your code and your architecture thus it is perhaps impossible or it too expensive to do ?

  I don't know but I'm interested to exchange about this.

  Cheers,

Arnaud Héritier
---
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
Apache Maven PMC





Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Ken Liu
It would be good to put this in the wiki.

2010/2/18 Arnaud Héritier <[hidden email]>:

> Here is the script I wrote to replace standard notifications in Freestyle
> and Maven projects by the Mail Ext Publisher. This script also activate the
> Jira plugin to update issues.
> Perhaps it could help someone else in the future
> I think I'm not using all the power of Groovy to have a more readable code
> and I'm not sure I'm using Hudson APIs like I should (It is the first time
> I'm using it)
> import hudson.plugins.emailext.* import
> hudson.plugins.emailext.plugins.trigger.* import hudson.plugins.jira.*
> import hudson.model.* import hudson.maven.* import hudson.maven.reporters.*
> import hudson.tasks.* // For each project for(item in Hudson.instance.items)
> { def recipients println("JOB : "+item.name); // Find current recipients
> defined in project if(item instanceof MavenModuleSet) { println(">MAVEN
> MODULE SET"); // Search for Maven Mailer Reporter println(">>Reporters");
> for(reporter in item.reporters) { println(">>> "+reporter); if(reporter
> instanceof MavenMailer) { recipients = reporter.recipients // remove it
> item.reporters.remove(reporter) } } } else if(item instanceof
> FreeStyleProject) { println(">FREESTYLE PROJECT"); }
> println(">>Publishers"); for(publisher in item.publishersList) {
> println(">>> "+publisher); // Search for default Mailer Publisher
> if(publisher instanceof Mailer) { recipients = publisher.recipients //
> remove it item.publishersList.remove(publisher) } else // Or for Extended
> Email Publisher if(publisher instanceof ExtendedEmailPublisher) { recipients
> = publisher.recipientList item.publishers.remove(publisher) // remove it
> item.publishersList.remove(publisher) } } // If we found recipients list to
> send mail if(recipients!=null){ println (">CURRENT RECIPIENT : "+recipients)
> // We create a new Extended Email Publisher def eep = new
> ExtendedEmailPublisher(); eep.recipientList = recipients eep.defaultSubject
> = "\$DEFAULT_SUBJECT" eep.defaultContent = "\$DEFAULT_CONTENT" // With some
> triggers eep.configuredTriggers.add(new FailureTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
> eep.configuredTriggers.add(new FixedTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
> eep.configuredTriggers.add(new StillFailingTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
> eep.configuredTriggers.add(new StillUnstableTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
> eep.configuredTriggers.add(new UnstableTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) // And we
> add/replace it in the project item.publishersList.replace(eep); }else{
> println (">NO RECIPIENT") } // We add Jira Publisher
> item.publishersList.replace(new JiraIssueUpdater()) println("\n=======\n");
> }
>
>
> Cheers,
> Arnaud
> 2010/2/18 Arnaud Héritier <[hidden email]>
>>
>> On Thu, Feb 18, 2010 at 3:00 PM, Romain Seguy <[hidden email]>
>> wrote:
>>>
>>> Re,
>>>
>>> I'm not a Groovy expert, but a little script like this can be useful to
>>> remove some publishers on a freestyle project:
>>>
>>> for(item in hudson.model.Hudson.instance.items) {
>>>   for(publisher in item.publishersList) {
>>>     for(describable in publisher) {
>>>       if(describable.descriptor.displayName == "Continuous Integration
>>> game") {
>>>         println("Removing publisher " +
>>> describable.descriptor.displayName  + " from " + item.name)
>>>         item.publishersList.remove(describable.descriptor)
>>>       }
>>>     }
>>>   }
>>> }
>>>
>>> This one is dirty (and it removes the Continuous Integration Game
>>> publisher) since it removed publishers based on their display name, there
>>> are also surely some faster paths to access the publishers, but it works
>>> fine.
>>>
>> Cool, I will try to adapt it to my own need. I'll publish it.
>>
>>>
>>> I'm sorry to not help on Maven jobs (knowing that you obviously love it
>>> ;-)) but I don't use it.
>>
>> Current issues are not easy to find and fix.
>> I'll try to have a look at them.
>> I would like to be able to use only them
>>
>>>
>>> HTH,
>>> Romain
>>>
>>> Le 18 février 2010 11:11, Arnaud Héritier <[hidden email]> a écrit :
>>>>
>>>> Yes it is also possible.
>>>> I already did it but in bash/grep/sed/...
>>>> In that case it isn't easy but I think it is possible to do with groovy.
>>>> I have to remove this sort of block
>>>>   <reporters>
>>>>     <hudson.maven.reporters.MavenMailer>
>>>>       <recipients>XXXXXXX</recipients>
>>>>       <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
>>>>       <sendToIndividuals>false</sendToIndividuals>
>>>>     </hudson.maven.reporters.MavenMailer>
>>>>   </reporters>
>>>> And add this one
>>>>   <publishers>
>>>>     <hudson.plugins.jira.JiraIssueUpdater/>
>>>>     <hudson.plugins.emailext.ExtendedEmailPublisher>
>>>>       <recipientList></recipientList>
>>>>       <configuredTriggers>
>>>>         <hudson.plugins.emailext.plugins.trigger.FailureTrigger>
>>>>           <email>
>>>>             <recipientList></recipientList>
>>>>             <subject>$PROJECT_DEFAULT_SUBJECT</subject>
>>>>             <body>$PROJECT_DEFAULT_CONTENT</body>
>>>>             <sendToDevelopers>true</sendToDevelopers>
>>>>             <includeCulprits>false</includeCulprits>
>>>>             <sendToRecipientList>true</sendToRecipientList>
>>>>           </email>
>>>>         </hudson.plugins.emailext.plugins.trigger.FailureTrigger>
>>>>       </configuredTriggers>
>>>>       <contentType>default</contentType>
>>>>       <defaultSubject>$DEFAULT_SUBJECT</defaultSubject>
>>>>       <defaultContent>$DEFAULT_CONTENT</defaultContent>
>>>>     </hudson.plugins.emailext.ExtendedEmailPublisher>
>>>>   </publishers>
>>>> After copying the recipient list from the old to the new one
>>>> And it must be a little bit different for freestyle jobs (I have few of
>>>> them because of issues on the maven 2 integration)
>>>>
>>>>
>>>> On Thu, Feb 18, 2010 at 10:47 AM, Romain Seguy <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Hi Arnaud,
>>>>>
>>>>> To update your jobs, what about using the Groovy script console to run
>>>>> an arbitrary script? ==> https://.../hudson/script
>>>>>
>>>>> Regards,
>>>>> Romain
>>>>>
>>>>> Le 18 février 2010 10:18, Arnaud Héritier
>>>>> <[hidden email]> a écrit :
>>>>>>
>>>>>> Hi all,
>>>>>>   I wanted to discuss about a really annoying missing feature : The
>>>>>> bulk update of jobs.
>>>>>>   We have plugins to use templates when we create a new job, or to
>>>>>> update some fields like in slicing configuration.
>>>>>>   It is good but not enough.
>>>>>>   In theory, we don't have to do a bulk update really often but when
>>>>>> we have to do it, it is just a nightmare when you have several dozen of
>>>>>> jobs.
>>>>>>   Yesterday I installed the mail-ext plugin to customize emails sent
>>>>>> to my teams. The installation was easy, like always, but I add to update all
>>>>>> jobs to enable it eveywhere :-( (and I have to end this morning).
>>>>>>   Many tools like Jira, or Bamboo added a bulk update operation which
>>>>>> allow to override in a set of jobs a given number of parameters.
>>>>>>   Isn't it something we could imagine to add ?
>>>>>>   I could try to participate if need.
>>>>>>   Another solution instead having a bulk feature is to have an
>>>>>> inheritance mechanism with the ability to update one "abstract" parent and
>>>>>> to automatically update children.
>>>>>>   I never had a look at your code and your architecture thus it is
>>>>>> perhaps impossible or it too expensive to do ?
>>>>>>   I don't know but I'm interested to exchange about this.
>>>>>>   Cheers,
>>>>>> Arnaud Héritier
>>>>>> ---
>>>>>> Software Factory Manager
>>>>>> eXo platform - http://www.exoplatform.com
>>>>>> ---
>>>>>> Apache Maven PMC
>>>>>> http://maven.apache.org
>>>>>> ---
>>>>>> http://www.aheritier.net
>>>>>
>>>>
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Arnaud Héritier
Tell me where. If I have enough rights to push it, I'll do.


Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net


On Fri, Feb 19, 2010 at 3:54 PM, Ken Liu <[hidden email]> wrote:
It would be good to put this in the wiki.

2010/2/18 Arnaud Héritier <[hidden email]>:
> Here is the script I wrote to replace standard notifications in Freestyle
> and Maven projects by the Mail Ext Publisher. This script also activate the
> Jira plugin to update issues.
> Perhaps it could help someone else in the future
> I think I'm not using all the power of Groovy to have a more readable code
> and I'm not sure I'm using Hudson APIs like I should (It is the first time
> I'm using it)
> import hudson.plugins.emailext.* import
> hudson.plugins.emailext.plugins.trigger.* import hudson.plugins.jira.*
> import hudson.model.* import hudson.maven.* import hudson.maven.reporters.*
> import hudson.tasks.* // For each project for(item in Hudson.instance.items)
> { def recipients println("JOB : "+item.name); // Find current recipients
> defined in project if(item instanceof MavenModuleSet) { println(">MAVEN
> MODULE SET"); // Search for Maven Mailer Reporter println(">>Reporters");
> for(reporter in item.reporters) { println(">>> "+reporter); if(reporter
> instanceof MavenMailer) { recipients = reporter.recipients // remove it
> item.reporters.remove(reporter) } } } else if(item instanceof
> FreeStyleProject) { println(">FREESTYLE PROJECT"); }
> println(">>Publishers"); for(publisher in item.publishersList) {
> println(">>> "+publisher); // Search for default Mailer Publisher
> if(publisher instanceof Mailer) { recipients = publisher.recipients //
> remove it item.publishersList.remove(publisher) } else // Or for Extended
> Email Publisher if(publisher instanceof ExtendedEmailPublisher) { recipients
> = publisher.recipientList item.publishers.remove(publisher) // remove it
> item.publishersList.remove(publisher) } } // If we found recipients list to
> send mail if(recipients!=null){ println (">CURRENT RECIPIENT : "+recipients)
> // We create a new Extended Email Publisher def eep = new
> ExtendedEmailPublisher(); eep.recipientList = recipients eep.defaultSubject
> = "\$DEFAULT_SUBJECT" eep.defaultContent = "\$DEFAULT_CONTENT" // With some
> triggers eep.configuredTriggers.add(new FailureTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
> eep.configuredTriggers.add(new FixedTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
> eep.configuredTriggers.add(new StillFailingTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
> eep.configuredTriggers.add(new StillUnstableTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
> eep.configuredTriggers.add(new UnstableTrigger(email : new
> EmailType(sendToRecipientList : true, body :
> ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
> ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) // And we
> add/replace it in the project item.publishersList.replace(eep); }else{
> println (">NO RECIPIENT") } // We add Jira Publisher
> item.publishersList.replace(new JiraIssueUpdater()) println("\n=======\n");
> }
>
>
> Cheers,
> Arnaud
> 2010/2/18 Arnaud Héritier <[hidden email]>
>>
>> On Thu, Feb 18, 2010 at 3:00 PM, Romain Seguy <[hidden email]>
>> wrote:
>>>
>>> Re,
>>>
>>> I'm not a Groovy expert, but a little script like this can be useful to
>>> remove some publishers on a freestyle project:
>>>
>>> for(item in hudson.model.Hudson.instance.items) {
>>>   for(publisher in item.publishersList) {
>>>     for(describable in publisher) {
>>>       if(describable.descriptor.displayName == "Continuous Integration
>>> game") {
>>>         println("Removing publisher " +
>>> describable.descriptor.displayName  + " from " + item.name)
>>>         item.publishersList.remove(describable.descriptor)
>>>       }
>>>     }
>>>   }
>>> }
>>>
>>> This one is dirty (and it removes the Continuous Integration Game
>>> publisher) since it removed publishers based on their display name, there
>>> are also surely some faster paths to access the publishers, but it works
>>> fine.
>>>
>> Cool, I will try to adapt it to my own need. I'll publish it.
>>
>>>
>>> I'm sorry to not help on Maven jobs (knowing that you obviously love it
>>> ;-)) but I don't use it.
>>
>> Current issues are not easy to find and fix.
>> I'll try to have a look at them.
>> I would like to be able to use only them
>>
>>>
>>> HTH,
>>> Romain
>>>
>>> Le 18 février 2010 11:11, Arnaud Héritier <[hidden email]> a écrit :
>>>>
>>>> Yes it is also possible.
>>>> I already did it but in bash/grep/sed/...
>>>> In that case it isn't easy but I think it is possible to do with groovy.
>>>> I have to remove this sort of block
>>>>   <reporters>
>>>>     <hudson.maven.reporters.MavenMailer>
>>>>       <recipients>XXXXXXX</recipients>
>>>>       <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
>>>>       <sendToIndividuals>false</sendToIndividuals>
>>>>     </hudson.maven.reporters.MavenMailer>
>>>>   </reporters>
>>>> And add this one
>>>>   <publishers>
>>>>     <hudson.plugins.jira.JiraIssueUpdater/>
>>>>     <hudson.plugins.emailext.ExtendedEmailPublisher>
>>>>       <recipientList></recipientList>
>>>>       <configuredTriggers>
>>>>         <hudson.plugins.emailext.plugins.trigger.FailureTrigger>
>>>>           <email>
>>>>             <recipientList></recipientList>
>>>>             <subject>$PROJECT_DEFAULT_SUBJECT</subject>
>>>>             <body>$PROJECT_DEFAULT_CONTENT</body>
>>>>             <sendToDevelopers>true</sendToDevelopers>
>>>>             <includeCulprits>false</includeCulprits>
>>>>             <sendToRecipientList>true</sendToRecipientList>
>>>>           </email>
>>>>         </hudson.plugins.emailext.plugins.trigger.FailureTrigger>
>>>>       </configuredTriggers>
>>>>       <contentType>default</contentType>
>>>>       <defaultSubject>$DEFAULT_SUBJECT</defaultSubject>
>>>>       <defaultContent>$DEFAULT_CONTENT</defaultContent>
>>>>     </hudson.plugins.emailext.ExtendedEmailPublisher>
>>>>   </publishers>
>>>> After copying the recipient list from the old to the new one
>>>> And it must be a little bit different for freestyle jobs (I have few of
>>>> them because of issues on the maven 2 integration)
>>>>
>>>>
>>>> On Thu, Feb 18, 2010 at 10:47 AM, Romain Seguy <[hidden email]>
>>>> wrote:
>>>>>
>>>>> Hi Arnaud,
>>>>>
>>>>> To update your jobs, what about using the Groovy script console to run
>>>>> an arbitrary script? ==> https://.../hudson/script
>>>>>
>>>>> Regards,
>>>>> Romain
>>>>>
>>>>> Le 18 février 2010 10:18, Arnaud Héritier
>>>>> <[hidden email]> a écrit :
>>>>>>
>>>>>> Hi all,
>>>>>>   I wanted to discuss about a really annoying missing feature : The
>>>>>> bulk update of jobs.
>>>>>>   We have plugins to use templates when we create a new job, or to
>>>>>> update some fields like in slicing configuration.
>>>>>>   It is good but not enough.
>>>>>>   In theory, we don't have to do a bulk update really often but when
>>>>>> we have to do it, it is just a nightmare when you have several dozen of
>>>>>> jobs.
>>>>>>   Yesterday I installed the mail-ext plugin to customize emails sent
>>>>>> to my teams. The installation was easy, like always, but I add to update all
>>>>>> jobs to enable it eveywhere :-( (and I have to end this morning).
>>>>>>   Many tools like Jira, or Bamboo added a bulk update operation which
>>>>>> allow to override in a set of jobs a given number of parameters.
>>>>>>   Isn't it something we could imagine to add ?
>>>>>>   I could try to participate if need.
>>>>>>   Another solution instead having a bulk feature is to have an
>>>>>> inheritance mechanism with the ability to update one "abstract" parent and
>>>>>> to automatically update children.
>>>>>>   I never had a look at your code and your architecture thus it is
>>>>>> perhaps impossible or it too expensive to do ?
>>>>>>   I don't know but I'm interested to exchange about this.
>>>>>>   Cheers,
>>>>>> Arnaud Héritier
>>>>>> ---
>>>>>> Software Factory Manager
>>>>>> eXo platform - http://www.exoplatform.com
>>>>>> ---
>>>>>> Apache Maven PMC
>>>>>> http://maven.apache.org
>>>>>> ---
>>>>>> http://www.aheritier.net
>>>>>
>>>>
>>>
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Ken Liu
I couldn't find a place to put CLI samples, so I created a new page here:
http://wiki.hudson-ci.org/display/HUDSON/CLI+Samples

2010/2/19 Arnaud Héritier <[hidden email]>:

> Tell me where. If I have enough rights to push it, I'll do.
>
> Arnaud Héritier
> Software Factory Manager
> eXo platform - http://www.exoplatform.com
> ---
> http://www.aheritier.net
>
>
> On Fri, Feb 19, 2010 at 3:54 PM, Ken Liu <[hidden email]> wrote:
>>
>> It would be good to put this in the wiki.
>>
>> 2010/2/18 Arnaud Héritier <[hidden email]>:
>> > Here is the script I wrote to replace standard notifications in
>> > Freestyle
>> > and Maven projects by the Mail Ext Publisher. This script also activate
>> > the
>> > Jira plugin to update issues.
>> > Perhaps it could help someone else in the future
>> > I think I'm not using all the power of Groovy to have a more readable
>> > code
>> > and I'm not sure I'm using Hudson APIs like I should (It is the first
>> > time
>> > I'm using it)
>> > import hudson.plugins.emailext.* import
>> > hudson.plugins.emailext.plugins.trigger.* import hudson.plugins.jira.*
>> > import hudson.model.* import hudson.maven.* import
>> > hudson.maven.reporters.*
>> > import hudson.tasks.* // For each project for(item in
>> > Hudson.instance.items)
>> > { def recipients println("JOB : "+item.name); // Find current recipients
>> > defined in project if(item instanceof MavenModuleSet) { println(">MAVEN
>> > MODULE SET"); // Search for Maven Mailer Reporter
>> > println(">>Reporters");
>> > for(reporter in item.reporters) { println(">>> "+reporter); if(reporter
>> > instanceof MavenMailer) { recipients = reporter.recipients // remove it
>> > item.reporters.remove(reporter) } } } else if(item instanceof
>> > FreeStyleProject) { println(">FREESTYLE PROJECT"); }
>> > println(">>Publishers"); for(publisher in item.publishersList) {
>> > println(">>> "+publisher); // Search for default Mailer Publisher
>> > if(publisher instanceof Mailer) { recipients = publisher.recipients //
>> > remove it item.publishersList.remove(publisher) } else // Or for
>> > Extended
>> > Email Publisher if(publisher instanceof ExtendedEmailPublisher) {
>> > recipients
>> > = publisher.recipientList item.publishers.remove(publisher) // remove it
>> > item.publishersList.remove(publisher) } } // If we found recipients list
>> > to
>> > send mail if(recipients!=null){ println (">CURRENT RECIPIENT :
>> > "+recipients)
>> > // We create a new Extended Email Publisher def eep = new
>> > ExtendedEmailPublisher(); eep.recipientList = recipients
>> > eep.defaultSubject
>> > = "\$DEFAULT_SUBJECT" eep.defaultContent = "\$DEFAULT_CONTENT" // With
>> > some
>> > triggers eep.configuredTriggers.add(new FailureTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
>> > eep.configuredTriggers.add(new FixedTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
>> > eep.configuredTriggers.add(new StillFailingTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
>> > eep.configuredTriggers.add(new StillUnstableTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
>> > eep.configuredTriggers.add(new UnstableTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) // And we
>> > add/replace it in the project item.publishersList.replace(eep); }else{
>> > println (">NO RECIPIENT") } // We add Jira Publisher
>> > item.publishersList.replace(new JiraIssueUpdater())
>> > println("\n=======\n");
>> > }
>> >
>> >
>> > Cheers,
>> > Arnaud
>> > 2010/2/18 Arnaud Héritier <[hidden email]>
>> >>
>> >> On Thu, Feb 18, 2010 at 3:00 PM, Romain Seguy <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Re,
>> >>>
>> >>> I'm not a Groovy expert, but a little script like this can be useful
>> >>> to
>> >>> remove some publishers on a freestyle project:
>> >>>
>> >>> for(item in hudson.model.Hudson.instance.items) {
>> >>>   for(publisher in item.publishersList) {
>> >>>     for(describable in publisher) {
>> >>>       if(describable.descriptor.displayName == "Continuous Integration
>> >>> game") {
>> >>>         println("Removing publisher " +
>> >>> describable.descriptor.displayName  + " from " + item.name)
>> >>>         item.publishersList.remove(describable.descriptor)
>> >>>       }
>> >>>     }
>> >>>   }
>> >>> }
>> >>>
>> >>> This one is dirty (and it removes the Continuous Integration Game
>> >>> publisher) since it removed publishers based on their display name,
>> >>> there
>> >>> are also surely some faster paths to access the publishers, but it
>> >>> works
>> >>> fine.
>> >>>
>> >> Cool, I will try to adapt it to my own need. I'll publish it.
>> >>
>> >>>
>> >>> I'm sorry to not help on Maven jobs (knowing that you obviously love
>> >>> it
>> >>> ;-)) but I don't use it.
>> >>
>> >> Current issues are not easy to find and fix.
>> >> I'll try to have a look at them.
>> >> I would like to be able to use only them
>> >>
>> >>>
>> >>> HTH,
>> >>> Romain
>> >>>
>> >>> Le 18 février 2010 11:11, Arnaud Héritier <[hidden email]> a
>> >>> écrit :
>> >>>>
>> >>>> Yes it is also possible.
>> >>>> I already did it but in bash/grep/sed/...
>> >>>> In that case it isn't easy but I think it is possible to do with
>> >>>> groovy.
>> >>>> I have to remove this sort of block
>> >>>>   <reporters>
>> >>>>     <hudson.maven.reporters.MavenMailer>
>> >>>>       <recipients>XXXXXXX</recipients>
>> >>>>
>> >>>>  <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
>> >>>>       <sendToIndividuals>false</sendToIndividuals>
>> >>>>     </hudson.maven.reporters.MavenMailer>
>> >>>>   </reporters>
>> >>>> And add this one
>> >>>>   <publishers>
>> >>>>     <hudson.plugins.jira.JiraIssueUpdater/>
>> >>>>     <hudson.plugins.emailext.ExtendedEmailPublisher>
>> >>>>       <recipientList></recipientList>
>> >>>>       <configuredTriggers>
>> >>>>         <hudson.plugins.emailext.plugins.trigger.FailureTrigger>
>> >>>>           <email>
>> >>>>             <recipientList></recipientList>
>> >>>>             <subject>$PROJECT_DEFAULT_SUBJECT</subject>
>> >>>>             <body>$PROJECT_DEFAULT_CONTENT</body>
>> >>>>             <sendToDevelopers>true</sendToDevelopers>
>> >>>>             <includeCulprits>false</includeCulprits>
>> >>>>             <sendToRecipientList>true</sendToRecipientList>
>> >>>>           </email>
>> >>>>         </hudson.plugins.emailext.plugins.trigger.FailureTrigger>
>> >>>>       </configuredTriggers>
>> >>>>       <contentType>default</contentType>
>> >>>>       <defaultSubject>$DEFAULT_SUBJECT</defaultSubject>
>> >>>>       <defaultContent>$DEFAULT_CONTENT</defaultContent>
>> >>>>     </hudson.plugins.emailext.ExtendedEmailPublisher>
>> >>>>   </publishers>
>> >>>> After copying the recipient list from the old to the new one
>> >>>> And it must be a little bit different for freestyle jobs (I have few
>> >>>> of
>> >>>> them because of issues on the maven 2 integration)
>> >>>>
>> >>>>
>> >>>> On Thu, Feb 18, 2010 at 10:47 AM, Romain Seguy
>> >>>> <[hidden email]>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi Arnaud,
>> >>>>>
>> >>>>> To update your jobs, what about using the Groovy script console to
>> >>>>> run
>> >>>>> an arbitrary script? ==> https://.../hudson/script
>> >>>>>
>> >>>>> Regards,
>> >>>>> Romain
>> >>>>>
>> >>>>> Le 18 février 2010 10:18, Arnaud Héritier
>> >>>>> <[hidden email]> a écrit :
>> >>>>>>
>> >>>>>> Hi all,
>> >>>>>>   I wanted to discuss about a really annoying missing feature : The
>> >>>>>> bulk update of jobs.
>> >>>>>>   We have plugins to use templates when we create a new job, or to
>> >>>>>> update some fields like in slicing configuration.
>> >>>>>>   It is good but not enough.
>> >>>>>>   In theory, we don't have to do a bulk update really often but
>> >>>>>> when
>> >>>>>> we have to do it, it is just a nightmare when you have several
>> >>>>>> dozen of
>> >>>>>> jobs.
>> >>>>>>   Yesterday I installed the mail-ext plugin to customize emails
>> >>>>>> sent
>> >>>>>> to my teams. The installation was easy, like always, but I add to
>> >>>>>> update all
>> >>>>>> jobs to enable it eveywhere :-( (and I have to end this morning).
>> >>>>>>   Many tools like Jira, or Bamboo added a bulk update operation
>> >>>>>> which
>> >>>>>> allow to override in a set of jobs a given number of parameters.
>> >>>>>>   Isn't it something we could imagine to add ?
>> >>>>>>   I could try to participate if need.
>> >>>>>>   Another solution instead having a bulk feature is to have an
>> >>>>>> inheritance mechanism with the ability to update one "abstract"
>> >>>>>> parent and
>> >>>>>> to automatically update children.
>> >>>>>>   I never had a look at your code and your architecture thus it is
>> >>>>>> perhaps impossible or it too expensive to do ?
>> >>>>>>   I don't know but I'm interested to exchange about this.
>> >>>>>>   Cheers,
>> >>>>>> Arnaud Héritier
>> >>>>>> ---
>> >>>>>> Software Factory Manager
>> >>>>>> eXo platform - http://www.exoplatform.com
>> >>>>>> ---
>> >>>>>> Apache Maven PMC
>> >>>>>> http://maven.apache.org
>> >>>>>> ---
>> >>>>>> http://www.aheritier.net
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Bulk updates

Arnaud Héritier
I added my code.
If some hudson/groovy experts want to review/improve it, feel free to do it.

cheers,

Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net


On Fri, Feb 19, 2010 at 5:46 PM, Ken Liu <[hidden email]> wrote:
I couldn't find a place to put CLI samples, so I created a new page here:
http://wiki.hudson-ci.org/display/HUDSON/CLI+Samples

2010/2/19 Arnaud Héritier <[hidden email]>:
> Tell me where. If I have enough rights to push it, I'll do.
>
> Arnaud Héritier
> Software Factory Manager
> eXo platform - http://www.exoplatform.com
> ---
> http://www.aheritier.net
>
>
> On Fri, Feb 19, 2010 at 3:54 PM, Ken Liu <[hidden email]> wrote:
>>
>> It would be good to put this in the wiki.
>>
>> 2010/2/18 Arnaud Héritier <[hidden email]>:
>> > Here is the script I wrote to replace standard notifications in
>> > Freestyle
>> > and Maven projects by the Mail Ext Publisher. This script also activate
>> > the
>> > Jira plugin to update issues.
>> > Perhaps it could help someone else in the future
>> > I think I'm not using all the power of Groovy to have a more readable
>> > code
>> > and I'm not sure I'm using Hudson APIs like I should (It is the first
>> > time
>> > I'm using it)
>> > import hudson.plugins.emailext.* import
>> > hudson.plugins.emailext.plugins.trigger.* import hudson.plugins.jira.*
>> > import hudson.model.* import hudson.maven.* import
>> > hudson.maven.reporters.*
>> > import hudson.tasks.* // For each project for(item in
>> > Hudson.instance.items)
>> > { def recipients println("JOB : "+item.name); // Find current recipients
>> > defined in project if(item instanceof MavenModuleSet) { println(">MAVEN
>> > MODULE SET"); // Search for Maven Mailer Reporter
>> > println(">>Reporters");
>> > for(reporter in item.reporters) { println(">>> "+reporter); if(reporter
>> > instanceof MavenMailer) { recipients = reporter.recipients // remove it
>> > item.reporters.remove(reporter) } } } else if(item instanceof
>> > FreeStyleProject) { println(">FREESTYLE PROJECT"); }
>> > println(">>Publishers"); for(publisher in item.publishersList) {
>> > println(">>> "+publisher); // Search for default Mailer Publisher
>> > if(publisher instanceof Mailer) { recipients = publisher.recipients //
>> > remove it item.publishersList.remove(publisher) } else // Or for
>> > Extended
>> > Email Publisher if(publisher instanceof ExtendedEmailPublisher) {
>> > recipients
>> > = publisher.recipientList item.publishers.remove(publisher) // remove it
>> > item.publishersList.remove(publisher) } } // If we found recipients list
>> > to
>> > send mail if(recipients!=null){ println (">CURRENT RECIPIENT :
>> > "+recipients)
>> > // We create a new Extended Email Publisher def eep = new
>> > ExtendedEmailPublisher(); eep.recipientList = recipients
>> > eep.defaultSubject
>> > = "\$DEFAULT_SUBJECT" eep.defaultContent = "\$DEFAULT_CONTENT" // With
>> > some
>> > triggers eep.configuredTriggers.add(new FailureTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
>> > eep.configuredTriggers.add(new FixedTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
>> > eep.configuredTriggers.add(new StillFailingTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
>> > eep.configuredTriggers.add(new StillUnstableTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT )))
>> > eep.configuredTriggers.add(new UnstableTrigger(email : new
>> > EmailType(sendToRecipientList : true, body :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_BODY_TEXT, subject :
>> > ExtendedEmailPublisher.PROJECT_DEFAULT_SUBJECT_TEXT ))) // And we
>> > add/replace it in the project item.publishersList.replace(eep); }else{
>> > println (">NO RECIPIENT") } // We add Jira Publisher
>> > item.publishersList.replace(new JiraIssueUpdater())
>> > println("\n=======\n");
>> > }
>> >
>> >
>> > Cheers,
>> > Arnaud
>> > 2010/2/18 Arnaud Héritier <[hidden email]>
>> >>
>> >> On Thu, Feb 18, 2010 at 3:00 PM, Romain Seguy <[hidden email]>
>> >> wrote:
>> >>>
>> >>> Re,
>> >>>
>> >>> I'm not a Groovy expert, but a little script like this can be useful
>> >>> to
>> >>> remove some publishers on a freestyle project:
>> >>>
>> >>> for(item in hudson.model.Hudson.instance.items) {
>> >>>   for(publisher in item.publishersList) {
>> >>>     for(describable in publisher) {
>> >>>       if(describable.descriptor.displayName == "Continuous Integration
>> >>> game") {
>> >>>         println("Removing publisher " +
>> >>> describable.descriptor.displayName  + " from " + item.name)
>> >>>         item.publishersList.remove(describable.descriptor)
>> >>>       }
>> >>>     }
>> >>>   }
>> >>> }
>> >>>
>> >>> This one is dirty (and it removes the Continuous Integration Game
>> >>> publisher) since it removed publishers based on their display name,
>> >>> there
>> >>> are also surely some faster paths to access the publishers, but it
>> >>> works
>> >>> fine.
>> >>>
>> >> Cool, I will try to adapt it to my own need. I'll publish it.
>> >>
>> >>>
>> >>> I'm sorry to not help on Maven jobs (knowing that you obviously love
>> >>> it
>> >>> ;-)) but I don't use it.
>> >>
>> >> Current issues are not easy to find and fix.
>> >> I'll try to have a look at them.
>> >> I would like to be able to use only them
>> >>
>> >>>
>> >>> HTH,
>> >>> Romain
>> >>>
>> >>> Le 18 février 2010 11:11, Arnaud Héritier <[hidden email]> a
>> >>> écrit :
>> >>>>
>> >>>> Yes it is also possible.
>> >>>> I already did it but in bash/grep/sed/...
>> >>>> In that case it isn't easy but I think it is possible to do with
>> >>>> groovy.
>> >>>> I have to remove this sort of block
>> >>>>   <reporters>
>> >>>>     <hudson.maven.reporters.MavenMailer>
>> >>>>       <recipients>XXXXXXX</recipients>
>> >>>>
>> >>>>  <dontNotifyEveryUnstableBuild>false</dontNotifyEveryUnstableBuild>
>> >>>>       <sendToIndividuals>false</sendToIndividuals>
>> >>>>     </hudson.maven.reporters.MavenMailer>
>> >>>>   </reporters>
>> >>>> And add this one
>> >>>>   <publishers>
>> >>>>     <hudson.plugins.jira.JiraIssueUpdater/>
>> >>>>     <hudson.plugins.emailext.ExtendedEmailPublisher>
>> >>>>       <recipientList></recipientList>
>> >>>>       <configuredTriggers>
>> >>>>         <hudson.plugins.emailext.plugins.trigger.FailureTrigger>
>> >>>>           <email>
>> >>>>             <recipientList></recipientList>
>> >>>>             <subject>$PROJECT_DEFAULT_SUBJECT</subject>
>> >>>>             <body>$PROJECT_DEFAULT_CONTENT</body>
>> >>>>             <sendToDevelopers>true</sendToDevelopers>
>> >>>>             <includeCulprits>false</includeCulprits>
>> >>>>             <sendToRecipientList>true</sendToRecipientList>
>> >>>>           </email>
>> >>>>         </hudson.plugins.emailext.plugins.trigger.FailureTrigger>
>> >>>>       </configuredTriggers>
>> >>>>       <contentType>default</contentType>
>> >>>>       <defaultSubject>$DEFAULT_SUBJECT</defaultSubject>
>> >>>>       <defaultContent>$DEFAULT_CONTENT</defaultContent>
>> >>>>     </hudson.plugins.emailext.ExtendedEmailPublisher>
>> >>>>   </publishers>
>> >>>> After copying the recipient list from the old to the new one
>> >>>> And it must be a little bit different for freestyle jobs (I have few
>> >>>> of
>> >>>> them because of issues on the maven 2 integration)
>> >>>>
>> >>>>
>> >>>> On Thu, Feb 18, 2010 at 10:47 AM, Romain Seguy
>> >>>> <[hidden email]>
>> >>>> wrote:
>> >>>>>
>> >>>>> Hi Arnaud,
>> >>>>>
>> >>>>> To update your jobs, what about using the Groovy script console to
>> >>>>> run
>> >>>>> an arbitrary script? ==> https://.../hudson/script
>> >>>>>
>> >>>>> Regards,
>> >>>>> Romain
>> >>>>>
>> >>>>> Le 18 février 2010 10:18, Arnaud Héritier
>> >>>>> <[hidden email]> a écrit :
>> >>>>>>
>> >>>>>> Hi all,
>> >>>>>>   I wanted to discuss about a really annoying missing feature : The
>> >>>>>> bulk update of jobs.
>> >>>>>>   We have plugins to use templates when we create a new job, or to
>> >>>>>> update some fields like in slicing configuration.
>> >>>>>>   It is good but not enough.
>> >>>>>>   In theory, we don't have to do a bulk update really often but
>> >>>>>> when
>> >>>>>> we have to do it, it is just a nightmare when you have several
>> >>>>>> dozen of
>> >>>>>> jobs.
>> >>>>>>   Yesterday I installed the mail-ext plugin to customize emails
>> >>>>>> sent
>> >>>>>> to my teams. The installation was easy, like always, but I add to
>> >>>>>> update all
>> >>>>>> jobs to enable it eveywhere :-( (and I have to end this morning).
>> >>>>>>   Many tools like Jira, or Bamboo added a bulk update operation
>> >>>>>> which
>> >>>>>> allow to override in a set of jobs a given number of parameters.
>> >>>>>>   Isn't it something we could imagine to add ?
>> >>>>>>   I could try to participate if need.
>> >>>>>>   Another solution instead having a bulk feature is to have an
>> >>>>>> inheritance mechanism with the ability to update one "abstract"
>> >>>>>> parent and
>> >>>>>> to automatically update children.
>> >>>>>>   I never had a look at your code and your architecture thus it is
>> >>>>>> perhaps impossible or it too expensive to do ?
>> >>>>>>   I don't know but I'm interested to exchange about this.
>> >>>>>>   Cheers,
>> >>>>>> Arnaud Héritier
>> >>>>>> ---
>> >>>>>> Software Factory Manager
>> >>>>>> eXo platform - http://www.exoplatform.com
>> >>>>>> ---
>> >>>>>> Apache Maven PMC
>> >>>>>> http://maven.apache.org
>> >>>>>> ---
>> >>>>>> http://www.aheritier.net
>> >>>>>
>> >>>>
>> >>>
>> >>
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]