[Anthill-pro] Build Life Not needed
Ryan Smith
rws at urbancode.com
Tue May 1 17:09:37 CDT 2007
In this scenario, the build of B would continuously fail. If B failed
for some reason that might rectify itself (network or resource) then it
might succeed, but this is definitely the minority case. Unless B failed
for some reason I am not seeing, you wouldn't want to rebuild B until
someone looks at why B failed. When they discover the reason they could
just force a build of B manually if that is what is needed and then do a
manual build of A.
Ryan Smith
Jason Dillon wrote:
> The problem is indeed with dependencies of projects.
>
> If I have A which depends on B which depends on C. Asking AH to build
> A, will trigger builds of C and then B before A as I'd expect. Though
> I often run into problems where if B fails, then rebuilding A will end
> up selecting an older version of B instead of rebuilding B. The only
> work around I know of is to manually delete the failed buildlife of B
> and then request a build for A.
>
> I'd like to have the build of A when building dependencies to rebuild
> failed builds, and re-use builds which are successful and have no
> source modifications. Seems that this is what is missing.
>
> --jason
>
>
> On May 1, 2007, at 2:21 PM, Maciej Zawadzki wrote:
>
>> The choice of whether a scheduled trigger forces a new build or not is
>> configurable -- a scheduled trigger contains a check box deciding
>> whether the build will be forced. This allows you to configure a
>> scheduled trigger that will actually kick off a new build even if the
>> previous build failed.
>>
>> I think that you pointed out a slightly different scenario which is
>> about selecting which build of a dependency is used. And that is
>> completely configurable as well -- so if you want to use the latest
>> (whether it succeeds or fails) you can, and if you want to use the
>> latest successful (thus skipping the actual latest build that failed)
>> then you can do that too. But these are separate issues.
>>
>> Perhaps I'm misunderstanding your email below though.
>>
>> Regards,
>>
>> --Maciej
>>
>>
>>
>> Jason Dillon wrote:
>>> I agree, it would be nice if this was an option.
>>>
>>> While its nice that you folks put in this feature to reduce build
>>> numbers for folks using scheduled builds... because of this "feature" I
>>> can't really reliably use any schedule or triggered builds, as I
>>> have no
>>> way of knowing if the build will actually use the correct buildlife...
>>> as if a dependency failed, then a dependent would build next time with
>>> the previous successful build of its dependency... which is *WRONG* and
>>> will almost certainly result in the new build not building sucessfully,
>>> or if it does build it will be completely useless and thus will mess up
>>> and other builds which it is a dependency for.
>>>
>>> I would personally like to have the choice as to always rebuild failed,
>>> or to use the current... revert to last known good buildlife.
>>>
>>> Most of my builds are using Maven 2, and to make it reliable, I'd have
>>> to set the workflows to always rebuild failed as when problems happen
>>> they tend to be transient network related or due to invalid/buggy
>>> snapshots.
>>>
>>> Without the choice to always rebuild/last know good... scheduled builds
>>> are completely useless, as I can't trust that AH will do the right
>>> thing
>>> for my builds, I will always have to keep any eye on it and go in and
>>> manually fix things up when something does not build correctly.
>>> This is
>>> not acceptable, and so I can't use AH for automated builds like this at
>>> all, which is a shame.
>>>
>>> --jason
>>>
>>>
>>>
>>> On May 1, 2007, at 7:27 AM, Jeff Rodgers ((jerodger)) wrote:
>>>
>>>> It would be nice if this could be an option, maybe on a project or a
>>>> specific workflow. How else would you test a scheduled workflow? If
>>>> there is something in my environment that changes at 2:00 AM and kills
>>>> my build, I would want that build to try again the next day.
>>>>
>>>>
>>>> Jeff Rodgers
>>>> Cisco Remote Operations Services
>>>>
>>>> -----Original Message-----
>>>> From: anthill-pro-bounces at caladin.urbancode.com
>>>> [mailto:anthill-pro-bounces at caladin.urbancode.com] On Behalf Of Ryan
>>>> Smith
>>>> Sent: Tuesday, May 01, 2007 9:12 AM
>>>> To: anthill-pro at caladin.urbancode.com
>>>> Cc: anthill-pro at caladin.urbancode.com
>>>> Subject: Re: [Anthill-pro] Build Life Not needed
>>>>
>>>> Curtis,
>>>>
>>>> If the source or dependencies of the build have not changed since the
>>>> last build and the last build was a failure, we do not build it unless
>>>> it is forced. We do this to reduce the number of builds for people
>>>> using
>>>> scheduled builds. If the failure was due to a configuration issue or
>>>> network failure (or something) that is very difficult to detect and we
>>>> leave it up the the users to go in and force the build.
>>>>
>>>> Ryan Smith
>>>>
>>>> Curtis Yanko wrote:
>>>>>
>>>>> All,
>>>>>
>>>>> I'm sure I'm just missing something obvious but how come if I trigger
>>>>> a build, and there are no new changes in SVN but... the previous
>>>>> build
>>>>
>>>>> with the changes failed (not to build really but one of my other
>>>>> steps). Is there a way for AHP3 to know to force if the previous
>>>>> build
>>>>
>>>>> life failed?
>>>>>
>>>>> - Curtis Yanko
>>>>> United Health Technologies
>>>>> Mail Route: CT028-06SA
>>>>> Internet email: curt_yanko at uhc.com
>>>>> Office 860.702.9059
>>>>> Cell 860.729.8171
>>>>>
>>>>>
>>>>> This e-mail, including attachments, may include confidential and/or
>>>>> proprietary information, and may be used only by the person or entity
>>>>> to which it is addressed. If the reader of this e-mail is not the
>>>>> intended recipient or his or her authorized agent, the reader is
>>>>> hereby notified that any dissemination, distribution or copying of
>>>>> this e-mail is prohibited. If you have received this e-mail in error,
>>>>> please notify the sender by replying to this message and delete this
>>>> e-mail immediately.
>>>>> ----------------------------------------------------------------------
>>>>>
>>>>> --
>>>>> _______________________________________________
>>>>> Anthill-pro mailing list
>>>>> Anthill-pro at lists.urbancode.com
>>>>> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>>>>>
>>>>
>>>> --===========================================================
>>>> Ryan Smith. 2044 Euclid Ave., Suite 600
>>>> Lead Developer Cleveland, Ohio 44115
>>>> Urbancode, Inc.
>>>> email: rws at urbancode.com
>>>> web: www.urbancode.com phone: 216-858-9000
>>>> web: www.anthillpro.com fax: 216-858-9602
>>>> ===========================================================
>>>>
>>>> _______________________________________________
>>>> Anthill-pro mailing list
>>>> Anthill-pro at lists.urbancode.com
>>>> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>>>> _______________________________________________
>>>> Anthill-pro mailing list
>>>> Anthill-pro at lists.urbancode.com
>>>> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>>>
>>> _______________________________________________
>>> Anthill-pro mailing list
>>> Anthill-pro at lists.urbancode.com
>>> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>>>
>> _______________________________________________
>> Anthill-pro mailing list
>> Anthill-pro at lists.urbancode.com
>> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>
> _______________________________________________
> Anthill-pro mailing list
> Anthill-pro at lists.urbancode.com
> http://lists.urbancode.com/mailman/listinfo/anthill-pro
>
--
===========================================================
Ryan Smith. 2044 Euclid Ave., Suite 600
Lead Developer Cleveland, Ohio 44115
Urbancode, Inc.
email: rws at urbancode.com
web: www.urbancode.com phone: 216-858-9000
web: www.anthillpro.com fax: 216-858-9602
===========================================================
More information about the Anthill-pro
mailing list