[Mesa-dev] CI job for Android builds
robherring2 at gmail.com
Tue May 17 22:29:41 UTC 2016
On Tue, May 17, 2016 at 5:21 PM, Rob Clark <robdclark at gmail.com> wrote:
> On Tue, May 17, 2016 at 6:14 PM, Jose Fonseca <jfonseca at vmware.com> wrote:
>> On 17/05/16 22:43, Rob Clark wrote:
>>> On Tue, May 17, 2016 at 5:13 PM, Rob Herring <robherring2 at gmail.com>
>>>> I'm in the process of setting up a CI job to track Android builds of
>>>> mesa master (ATM merging in a branch of commits needed to build which
>>>> are not yet upstream). It is mostly working now though I'm still
>>>> tweaking the setup a bit. It is built on AOSP master branch as well.
>>>> Build errors/warnings are published here:
>>>> I can add anyone who would like to get emails of errors.
>>> Great idea!
>>> I think appveyor (windows CI build) just spams all of mesa-dev for
>>> build breaks.. and I guess I don't see a reason not to do that for
>>> android CI builds as well.
>> What do you mean by "spams"? Do you mean to say the AppVeyor traffic is too
> only meant that it sends it to the whole list (and I'm not saying that
> is a bad thing).. don't read too much into my choice of words ;-)
>> FYI, the notification settings are set such that AppVeyor does _not_ email
>> for _every_ failure. It emails when the build goes from passing -> failed,
>> or failed -> passed.
>> So, if the Windows build breaks while all Windows maitainers are on
>> vacation, there should be no spam.
>> The only situation where there's spam is when there are intermetting build
>> failures. We've seen a few of those (due to infrastructure issues), but
>> thankfully not too often.
>> I recommend similar notification settings. Too many emails: everybody
>> ignores, or will setup rules to hide those emails. No emails: nobody
> yeah, that is a good point.. not too familiar w/ Jenkins but if it has
> similar settings, that sounds like a good idea..
It does. Right now I have it set to email on every build (3 times a
day), so I'm not quite ready to spam everyone. First, I'd like to get
to a passing state and give it some time to make sure it is stable
(i.e. little/no AOSP master related breakage).
More information about the mesa-dev