, 2014 4:12:03 PM UTC+1, Sampath wrote:
>>
>> Hi,
>>
>> We are facing problems with template project
>> plugin<https://wiki.jenkins-ci.org/display/JENKINS/Template+Project+Plugin>.
>> "use all the publishers from this project" is not triggering a new bu
re facing problems with template project
> plugin<https://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 Temp
Hi,
We are facing problems with template project
plugin<https://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 Proje
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 ov
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
t
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 buil
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
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 wrote:
> In a similar situation I defined one job ("Configuration") that created a
> .properties file with the relevant options bas
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
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 def
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
l
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
12 matches
Mail list logo
