Re: Build mailing list

From: Olav Vitters <olav vitters nl>

> | The topic matcher will scan this many lines of the message body looking
> | for topic keyword matches. Body scanning stops when either this many
> | lines have been looked at, or a non-header-like body line is
> | encountered. By setting this value to zero, no body lines will be
> | scanned (i.e. only the Keywords: and Subject: headers will be scanned).
> | By setting this value to a negative number, then all body lines will be
> | scanned until a non-header-like line is encountered. 
> The Subject is likely messy. As currently the regexp for commits-list
> has ^projectname$ (meaning: exact matches only). And body lines scanning
> I'd likely would disable if not needed (speeds things up).
> Anyway, you could put a keywords header in the 1st line of the body.
> Perhaps easier than a buildbot upgrade?

If it can be solved with just a 1st line of the body with the project
name, this should be really easy to solve. Anyway, I will try to check
if overriding the mail creation methods would easily add the Keyword

>> > So:
>> > ACTION: Provide a text/plain list of possible projectnames on
>> > so I can automatically update the Mailman (API)
>> >         configuration via Cron (like commits-list +
>> Well the projectnames came from jhbuild, so this should be just add a
>> way to get a file using "jhbuild list", ie in the current
>>, "gnome-apps-3.0" became a link to this list. Right?
> Yes. Just give the output of jhbuild list of the configuration for
> Suggest to update hourly or so. Then even when the
> mailing list only updates once a day, we'll be sure it receives the
> latest changes.

Ok, although I guess that it would be enough to update it each time
the master starts the builds. I will try to check if there is a way to
update this file every time the master is going to start the build.

>> And about configuration, as you can also configure if the build log is
>> included or not, should we include the log on the mail (so bigger
>> mails)?
> Think that would speed things up, so think it is good to include. Does
> it somehow limit it to like the last 1000 lines or so?
> Usually only the last 50 messages max would be useful, rest is just
> stuff to scroll through. So 1000 is a good safe margin :)

Ok, I will check if this is feasible.


API (apinheiro igalia com)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]