[Anthill-pro] Re: Circular dependencies and non-originatingworkflows

Steve Boone sbb at urbancode.com
Thu May 22 12:26:11 CDT 2008


Not really.

The other option would be to build them all in their own originitaing
workflows, and then have a "nightly build project"  that will have
dependencies on all of he projects and trigger them all nightly.

That way, you will get a build of everything you need, in one buildlife.

Does that approach make sense or sound like it would work?

On Thu, May 22, 2008 at 1:14 PM, Heather Wells <heather at semanticresearch.com>
wrote:

>
>>  If I understand your approach Steve, then each time a CI build kicked
> off, it would also run an installer build?  I'd prefer to only run the
> installer builds (which take much longer) nightly.  Unless there's a way for
> different build jobs in the same workflow to be triggered at different
> times?
>
> Heather
>
>
>> From: "Steve Boone" <sbb at urbancode.com>
>> Date: May 22, 2008 9:51:48 AM PDT
>> To: "AnthillPro user and support list." <anthill-pro at lists.urbancode.com>
>> Subject: Re: [Anthill-pro] Re: Circular dependencies and
>> non-originatingworkflows
>> Reply-To: "AnthillPro user and support list." <
>> anthill-pro at lists.urbancode.com>
>>
>>
>> Another approach could be to do both builds in the same Originating
>> workflow.
>>
>> So when the workflow started, it to the build, and publish those
>> artifacts, then the second job would build the installables, and then
>> publish them in a separate artifact set.
>>
>> If you keep them in separate originating workflows, then yes, they will
>> create a new build life, however you have have as many jobs (and those jobs
>> can all be build jobs) in the same workflow.
>>
>> You will still have the traceability of those jobs on the buildlife page.
>>
>> Cheers,
>> Steve
>>
>> On Thu, May 22, 2008 at 12:48 PM, Peter Steele <psteele at maxiscale.com>
>> wrote:
>> We take a different approach. The CI builds are mainly to provide early
>> feedback on build breaks. The CI builds create deployable artifacts
>> which users can install on systems, but for QA, we do a clean build from
>> scratch, and the artifacts produced by those builds are what we pass on
>> to QA. I've seen some weird problems with CI builds and I wouldn't trust
>> them to use as official builds...
>>
>>  _______________________________________________
> Anthill-pro mailing list
> Anthill-pro at lists.urbancode.com
> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-pro/attachments/20080522/56cf0f68/attachment.htm


More information about the Anthill-pro mailing list