On 09/05/18 15:46, Max Rees wrote:
I believe that as it stands right now (I cannot check it at the
moment), my
abuildd-enqueue implementation does not distinguish between new commits added
to an existing MR, a force push over an existing MR, or a completely new MR.
Thus all added/changed (NB: *not* deleted) packages for a MR would be rebuilt
on each change to the MR.
That is probably for the best, as a MR is going to be a single unit of
work. I can understand that if, say, XFCE or elementary was added as a
MR, there might be a lot of busywork if a single package is changed.
But there could be non-obvious (or subtly non-declared) dependencies
between them all, which is why I think a clean rebuild for every MR
event is not only acceptable, but desireable.
It is, after all, just "machine time" right?
If there are other questions or considerations you'd like to
make, please let
me know.
If a build server goes down for maintenance, is that architecture "lost"
- i.e. will it require manual intervention / building of what was pushed
while that server was down?
Another feature I thought of during the same period today is that it
should be possible to prioritize jobs based on type (push, MR) and branch, if
applicable. Things such as being able to skip a build that would be caused by a
particular commit (I have seen things like having "[ci-skip]" in the commit
title before) are more difficult in the present implementation, but I'm sure it
can be done at some point.
Definitely prioritise 1-STABLE, then current, then feature branches,
then MRs from contributors, then MRs from the general public. At least,
that's how I would put it in a hierarchy.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org