Re: Template Project Plugin : use all the publishers from this project is not triggering a new build.
I install Any Build Step plugin version 0.1, but problem persist. I have Jenkins 1.562 and my Maven job inherit 3 publisher from another job, a Jaccoco Coverage, Git Publish, and Sonar, but only execute Jaccoco. Someone have similar problem or solution?? El lunes, 14 de abril de 2014 07:52:48 UTC-4, Sampath escribió: This issue is fixed after enabling Any Build Step in the flexible publish plugin configuration under global jenkins config. For this Any Build step plugin has to be installed. On Wednesday, February 12, 2014 4:12:03 PM UTC+1, Sampath wrote: Hi, We are facing problems with template project pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin. use all the publishers from this project is not triggering a new build. Below are the steps to reproduce this issue. 1. Install Template Project Pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin(version: 1.4) on Jenkins(version: 1.550). 2. Create Job_A, Job_B and Job_C. 3. In Job_A configuration, Under Post build action - Add post-build action - Use publishers from another project, enter Job_B for Template Project. 4. In Job_B configuration, Under Post build action - Add post-build action - Build Other Projects -enter Job_C for Projects to Build. With this configuration, if I build Job_B, build for Job_C will be triggered. Using Template Project plugin, we have used Job_B as template for Job_A. If I trigger Job_A, it pulls the publisher configuration from Job_B and it is supposed to trigger Job_C. But if I build Job_A, Job_C is not at all triggered. But other post build actions like email, Java doc is working fine. Seems the problem is only in building other projects. Is there already a fix for this problem? Could you please help us to fix this? Thanks, Sampath. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Template Project Plugin : use all the publishers from this project is not triggering a new build.
This issue is fixed after enabling Any Build Step in the flexible publish plugin configuration under global jenkins config. For this Any Build step plugin has to be installed. On Wednesday, February 12, 2014 4:12:03 PM UTC+1, Sampath wrote: Hi, We are facing problems with template project pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin. use all the publishers from this project is not triggering a new build. Below are the steps to reproduce this issue. 1. Install Template Project Pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin(version: 1.4) on Jenkins(version: 1.550). 2. Create Job_A, Job_B and Job_C. 3. In Job_A configuration, Under Post build action - Add post-build action - Use publishers from another project, enter Job_B for Template Project. 4. In Job_B configuration, Under Post build action - Add post-build action - Build Other Projects -enter Job_C for Projects to Build. With this configuration, if I build Job_B, build for Job_C will be triggered. Using Template Project plugin, we have used Job_B as template for Job_A. If I trigger Job_A, it pulls the publisher configuration from Job_B and it is supposed to trigger Job_C. But if I build Job_A, Job_C is not at all triggered. But other post build actions like email, Java doc is working fine. Seems the problem is only in building other projects. Is there already a fix for this problem? Could you please help us to fix this? Thanks, Sampath. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Template Project Plugin : use all the publishers from this project is not triggering a new build.
Hi, We are facing problems with template project pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin. use all the publishers from this project is not triggering a new build. Below are the steps to reproduce this issue. 1. Install Template Project Pluginhttps://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin(version: 1.4) on Jenkins(version: 1.550). 2. Create Job_A, Job_B and Job_C. 3. In Job_A configuration, Under Post build action - Add post-build action - Use publishers from another project, enter Job_B for Template Project. 4. In Job_B configuration, Under Post build action - Add post-build action - Build Other Projects -enter Job_C for Projects to Build. With this configuration, if I build Job_B, build for Job_C will be triggered. Using Template Project plugin, we have used Job_B as template for Job_A. If I trigger Job_A, it pulls the publisher configuration from Job_B and it is supposed to trigger Job_C. But if I build Job_A, Job_C is not at all triggered. But other post build actions like email, Java doc is working fine. Seems the problem is only in building other projects. Is there already a fix for this problem? Could you please help us to fix this? Thanks, Sampath. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Template Project plugin
Hi - I just wanted to follow up that Daniel Beck's solution worked perfectly for me. Now the SCM team only has to define the release string in one location. Other parameters include some host names and other paths that were repeated in other jobs. I have one job that we run when a release rolls over and set these as a file in the file system (not as an artifact). Then the other jobs simply have an extra step Inject environment variables to the build process that point to the properties file on disk. Works great! Thank you! On Wed, Jul 10, 2013 at 2:08 PM, syl20bnr sylvain.ben...@gmail.com wrote: You can also use the build parameterized trigger plugin you already use to read from the property file using Parameters from properties file. The plus sides are that build parameters are recorded in build histories and the values will be set before that the SCM step occurs. Cheers, syl20bnr Le mercredi 10 juillet 2013 06:16:19 UTC-4, MoBarger a écrit : I like it! I was thinking about a properties file but never thought of creating it as an artifact! Thanks for the idea! On Wed, Jul 10, 2013 at 6:09 AM, Daniel Beck m...@beckweb.net wrote: In a similar situation I defined one job (Configuration) that created a .properties file with the relevant options based on job paraemters and archived it as artifact. The other jobs then used the Copy Artifact plugin to get the file (Copy from last successful build uses the current option set), and a build step defined in Env-Inject to inject those options into the environment for subsequent build steps. For more flexibility, use a build selector parameter, or specify a build number as string parameter and copy artifacts from a 'specific build'. On 10.07.2013, at 11:13, Maureen Barger moba...@gmail.com wrote: Right, thanks, we do use that and it works well. But this works best when one job triggers another. In my case the processes are fired off at different times. The same parameters have to be set on each top job which seems like too many moving parts to me. Ideally I could set up a job which only defines the release number and a couple other parameters that would be referenced by each kickoff of the process (ie build, deploy, test, package). On Tue, Jul 9, 2013 at 9:52 PM, syl20bnr sylvain...@gmail.com wrote: You should be able to do this with the Parameterized Build plugin (https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build). At work we use Perforce and we use this plugin to pass the variable P4_CHANGELIST to downstream job (with the perforce plugin configured with P4_CHANGELIST as a label). It works fine. Now you write that you have several build parameters. Depending on how you use them it may lead to mess your build history with the same job called with different parameters. You may want to look at Job Generation plugins like JobCopy Builder, Job DSL and Job Generator. I'm the author of the last one. :-) Cheers, syl20bnr -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@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 Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@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 Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@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 Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+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 Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Template Project plugin
It is but it depends on what the use case really is. By declaring build parameters on the jobs you can fire any job at any time with any value, those values can be fed by a property file if triggered by an upstream job. There are pros and cons to both approaches and the ideal solution would be to feed the build parameters with the default values of a property file. Anyway if there is a lot of parameters to feed this may be an indication that the pipeline is too abstract and generating specific jobs preconfigured with some of the parameters could be a better solution (especially to prevent spaghetti build history of jobs). Cheers, syl20bnr Le mercredi 10 juillet 2013 15:41:20 UTC-4, Daniel Beck a écrit : How would this solve the complexity problem of manually triggering downstream jobs? Quoting Maureen: In my case the processes are fired off at different times. The same parameters have to be set on each top job which seems like too many moving parts to me. --- Adding an Env-Inject build step (or build wrapper) also adds a page called 'Environment Variables' to each build listing all defined environment variables for that build. It includes the ones loaded from the properties file. Of course, they're among 50 or so others, but it's not like that information is just gone. The one advantage of actual build parameters is that they're set before SCM, so you can add some variables there. OTOH my approach allows triggers e.g. based on SCM changes without maintaining default job arguments for several different jobs. --- Another option would be to register with Cloudbees (it's free) and get the Folders Plugin. It allows defining environment variables that are made available for place holders in the configuration of child jobs. Example 1: In the folder, define 'RELEASE_NAME=foo'. In the job within the folder, specify the SCM URL ' https://server/svn/branches/$RELEASE_NAME/subproject' Example 2: In the folder, define 'RELEASE_NAME=foo'. In the job within the folder, specify the Env-Inject 'Inject environment variables to the build process' as 'RELEASE_NAME=$RELEASE_NAME' (yes, really). Then you can access the environment variable RELEASE_NAME from build steps. This works best for static configuration though, like folders specific to branches defining the branch name to be inserted in SCM configuration. Just wanted to mention that option, even though the copyartifact/env-inject combination actually seems more appropriate. On 10.07.2013, at 20:08, syl20bnr sylvain...@gmail.com javascript: wrote: You can also use the build parameterized trigger plugin you already use to read from the property file using Parameters from properties file. The plus sides are that build parameters are recorded in build histories and the values will be set before that the SCM step occurs. Cheers, syl20bnr Le mercredi 10 juillet 2013 06:16:19 UTC-4, MoBarger a écrit : I like it! I was thinking about a properties file but never thought of creating it as an artifact! Thanks for the idea! On Wed, Jul 10, 2013 at 6:09 AM, Daniel Beck m...@beckweb.net wrote: In a similar situation I defined one job (Configuration) that created a .properties file with the relevant options based on job paraemters and archived it as artifact. The other jobs then used the Copy Artifact plugin to get the file (Copy from last successful build uses the current option set), and a build step defined in Env-Inject to inject those options into the environment for subsequent build steps. For more flexibility, use a build selector parameter, or specify a build number as string parameter and copy artifacts from a 'specific build'. On 10.07.2013, at 11:13, Maureen Barger moba...@gmail.com wrote: Right, thanks, we do use that and it works well. But this works best when one job triggers another. In my case the processes are fired off at different times. The same parameters have to be set on each top job which seems like too many moving parts to me. Ideally I could set up a job which only defines the release number and a couple other parameters that would be referenced by each kickoff of the process (ie build, deploy, test, package). On Tue, Jul 9, 2013 at 9:52 PM, syl20bnr sylvain...@gmail.com wrote: You should be able to do this with the Parameterized Build plugin ( https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build). At work we use Perforce and we use this plugin to pass the variable P4_CHANGELIST to downstream job (with the perforce plugin configured with P4_CHANGELIST as a label). It works fine. Now you write that you have several build parameters. Depending on how you use them it may lead to mess your build history with the same job called with different parameters. You may want to look at Job Generation plugins like JobCopy Builder, Job
Re: Template Project plugin
Right, thanks, we do use that and it works well. But this works best when one job triggers another. In my case the processes are fired off at different times. The same parameters have to be set on each top job which seems like too many moving parts to me. Ideally I could set up a job which only defines the release number and a couple other parameters that would be referenced by each kickoff of the process (ie build, deploy, test, package). On Tue, Jul 9, 2013 at 9:52 PM, syl20bnr sylvain.ben...@gmail.com wrote: You should be able to do this with the Parameterized Build plugin (https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build). At work we use Perforce and we use this plugin to pass the variable P4_CHANGELIST to downstream job (with the perforce plugin configured with P4_CHANGELIST as a label). It works fine. Now you write that you have several build parameters. Depending on how you use them it may lead to mess your build history with the same job called with different parameters. You may want to look at Job Generation plugins like JobCopy Builder, Job DSL and Job Generator. I'm the author of the last one. :-) Cheers, syl20bnr -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+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 Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Template Project plugin
You can also use the build parameterized trigger plugin you already use to read from the property file using Parameters from properties file. The plus sides are that build parameters are recorded in build histories and the values will be set before that the SCM step occurs. Cheers, syl20bnr Le mercredi 10 juillet 2013 06:16:19 UTC-4, MoBarger a écrit : I like it! I was thinking about a properties file but never thought of creating it as an artifact! Thanks for the idea! On Wed, Jul 10, 2013 at 6:09 AM, Daniel Beck m...@beckweb.netjavascript: wrote: In a similar situation I defined one job (Configuration) that created a .properties file with the relevant options based on job paraemters and archived it as artifact. The other jobs then used the Copy Artifact plugin to get the file (Copy from last successful build uses the current option set), and a build step defined in Env-Inject to inject those options into the environment for subsequent build steps. For more flexibility, use a build selector parameter, or specify a build number as string parameter and copy artifacts from a 'specific build'. On 10.07.2013, at 11:13, Maureen Barger moba...@gmail.com javascript: wrote: Right, thanks, we do use that and it works well. But this works best when one job triggers another. In my case the processes are fired off at different times. The same parameters have to be set on each top job which seems like too many moving parts to me. Ideally I could set up a job which only defines the release number and a couple other parameters that would be referenced by each kickoff of the process (ie build, deploy, test, package). On Tue, Jul 9, 2013 at 9:52 PM, syl20bnr sylvain...@gmail.comjavascript: wrote: You should be able to do this with the Parameterized Build plugin ( https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build). At work we use Perforce and we use this plugin to pass the variable P4_CHANGELIST to downstream job (with the perforce plugin configured with P4_CHANGELIST as a label). It works fine. Now you write that you have several build parameters. Depending on how you use them it may lead to mess your build history with the same job called with different parameters. You may want to look at Job Generation plugins like JobCopy Builder, Job DSL and Job Generator. I'm the author of the last one. :-) Cheers, syl20bnr -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@googlegroups.com javascript:. For more options, visit https://groups.google.com/groups/opt_out. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: Template Project plugin
How would this solve the complexity problem of manually triggering downstream jobs? Quoting Maureen: In my case the processes are fired off at different times. The same parameters have to be set on each top job which seems like too many moving parts to me. --- Adding an Env-Inject build step (or build wrapper) also adds a page called 'Environment Variables' to each build listing all defined environment variables for that build. It includes the ones loaded from the properties file. Of course, they're among 50 or so others, but it's not like that information is just gone. The one advantage of actual build parameters is that they're set before SCM, so you can add some variables there. OTOH my approach allows triggers e.g. based on SCM changes without maintaining default job arguments for several different jobs. --- Another option would be to register with Cloudbees (it's free) and get the Folders Plugin. It allows defining environment variables that are made available for place holders in the configuration of child jobs. Example 1: In the folder, define 'RELEASE_NAME=foo'. In the job within the folder, specify the SCM URL 'https://server/svn/branches/$RELEASE_NAME/subproject' Example 2: In the folder, define 'RELEASE_NAME=foo'. In the job within the folder, specify the Env-Inject 'Inject environment variables to the build process' as 'RELEASE_NAME=$RELEASE_NAME' (yes, really). Then you can access the environment variable RELEASE_NAME from build steps. This works best for static configuration though, like folders specific to branches defining the branch name to be inserted in SCM configuration. Just wanted to mention that option, even though the copyartifact/env-inject combination actually seems more appropriate. On 10.07.2013, at 20:08, syl20bnr sylvain.ben...@gmail.com wrote: You can also use the build parameterized trigger plugin you already use to read from the property file using Parameters from properties file. The plus sides are that build parameters are recorded in build histories and the values will be set before that the SCM step occurs. Cheers, syl20bnr Le mercredi 10 juillet 2013 06:16:19 UTC-4, MoBarger a écrit : I like it! I was thinking about a properties file but never thought of creating it as an artifact! Thanks for the idea! On Wed, Jul 10, 2013 at 6:09 AM, Daniel Beck m...@beckweb.net wrote: In a similar situation I defined one job (Configuration) that created a .properties file with the relevant options based on job paraemters and archived it as artifact. The other jobs then used the Copy Artifact plugin to get the file (Copy from last successful build uses the current option set), and a build step defined in Env-Inject to inject those options into the environment for subsequent build steps. For more flexibility, use a build selector parameter, or specify a build number as string parameter and copy artifacts from a 'specific build'. On 10.07.2013, at 11:13, Maureen Barger moba...@gmail.com wrote: Right, thanks, we do use that and it works well. But this works best when one job triggers another. In my case the processes are fired off at different times. The same parameters have to be set on each top job which seems like too many moving parts to me. Ideally I could set up a job which only defines the release number and a couple other parameters that would be referenced by each kickoff of the process (ie build, deploy, test, package). On Tue, Jul 9, 2013 at 9:52 PM, syl20bnr sylvain...@gmail.com wrote: You should be able to do this with the Parameterized Build plugin (https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Build). At work we use Perforce and we use this plugin to pass the variable P4_CHANGELIST to downstream job (with the perforce plugin configured with P4_CHANGELIST as a label). It works fine. Now you write that you have several build parameters. Depending on how you use them it may lead to mess your build history with the same job called with different parameters. You may want to look at Job Generation plugins like JobCopy Builder, Job DSL and Job Generator. I'm the author of the last one. :-) Cheers, syl20bnr -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@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 Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-use...@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
Template Project plugin
Hi - we have broken our build/deploy process into distinct build, test, deploy and scheduled FTP processes. These jobs all share some common variables, release number being one of them. Currently release number is manually set each step of the way. It is my hope to create a job that defines all of these variables and then to have other jobs use scm from this project and inherit these parameters. However it is not working as I expected it to., the parameters don't seem to be passed down. Am I on the wrong track? Is there a way to do what I want to do? Thanks. -- You received this message because you are subscribed to the Google Groups Jenkins Users group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
