On Mon, Jun 4, 2012 at 11:48 AM, Bram de Jong
wrote:
>
> If you'd go back to my first email and substitute "repository" by
> "trunk" maybe my emails make more sense?
> Our apps don't need the full repositories, they just need the trunk/master.
> But still, the rest of my email(s) stay the same: we
On Mon, Jun 4, 2012 at 6:18 PM, Les Mikesell wrote:
>> I suppose the gist of my question is:
>> If I have 50 different applications that are all sitting in the same
>> repository, and I want each of these applications to build separately
>> as a job, do I really need to do 50 different checkouts o
On Mon, Jun 4, 2012 at 9:22 AM, Bram de Jong wrote:
> On Mon, Jun 4, 2012 at 6:16 PM, Slide wrote:
>> No, we have a similar situation. I have a job that does the checkout
>> and then set the workspace for each of the other jobs to the place
>> where the SCM job checked the code out to and do the
On Mon, Jun 4, 2012 at 11:13 AM, Bram de Jong
wrote:
> >
> I suppose the gist of my question is:
> If I have 50 different applications that are all sitting in the same
> repository, and I want each of these applications to build separately
> as a job, do I really need to do 50 different checkouts
On Mon, Jun 4, 2012 at 6:16 PM, Slide wrote:
> No, we have a similar situation. I have a job that does the checkout
> and then set the workspace for each of the other jobs to the place
> where the SCM job checked the code out to and do the actual builds.
Aha, and could you perhaps give me an idea
On Mon, Jun 4, 2012 at 10:27 AM, Bram de Jong
wrote:
>>
>> I'd think in terms of jobs that build components and applications, not
>> so much in relationships to repositories.
>
> The problem is that this would mean 100 different jobs that all do the
> same thing (i.e. update 5 repositories - one o
On Mon, Jun 4, 2012 at 9:13 AM, Bram de Jong wrote:
> On Mon, Jun 4, 2012 at 5:27 PM, Bram de Jong
> wrote:
My initial guess on how to solve this:
* put each of the repo's in a job that *only fetches* the repo into a
shared directory and doesn't do anything else.
>>>
>>> I'd think
On Mon, Jun 4, 2012 at 5:27 PM, Bram de Jong wrote:
>>> My initial guess on how to solve this:
>>> * put each of the repo's in a job that *only fetches* the repo into a
>>> shared directory and doesn't do anything else.
>>
>> I'd think in terms of jobs that build components and applications, not
>
>> My initial guess on how to solve this:
>> * put each of the repo's in a job that *only fetches* the repo into a
>> shared directory and doesn't do anything else.
>
> I'd think in terms of jobs that build components and applications, not
> so much in relationships to repositories.
The problem is
On Mon, Jun 4, 2012 at 6:23 AM, Bram de Jong wrote:
>>
> My initial guess on how to solve this:
> * put each of the repo's in a job that *only fetches* the repo into a
> shared directory and doesn't do anything else.
I'd think in terms of jobs that build components and applications, not
so much i
Hello all,
I've just read the "official" jenkins book which gave me some ideas,
but I wanted to flesh out my ideas before I start configuring.
We have a relatively complex system which looks like this:
// old code bases, actively used elsewhere, but not actively changed
A <- svn repo, updated i
11 matches
Mail list logo
