4:46 p.m.
Hello all,
During some brief free time today I was thinking about how to go about
implementing some of the upcoming features that I plan to add to abuildd in
the next few weeks. Specifically, I am concerned about the handling of
dependencies.
My current proposal is that each new push to a branch ("push event") or update
to a merge request ("MR event") will create a new "job". The job can
be
composed of one or more "tasks" which would be building a package on a
specific architecture. As an example, if a push event is received that changed
two APKBUILDs, a job would be added that would include tasks to build those
two packages on all applicable architectures.
I do not expect there to be any problems with handling dependencies between
tasks in a single job (intra-job dependencies). However, dependencies between
multiple jobs (inter-job dependencies) is more complex, at least the way I see
it now.
For push events, it could be easy to handle inter-job dependencies as long as
the artifacts for each job are collected and kept for that branch. It is MR
events that I am more concerned about.
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.
I think it is possible to implement it such that we keep state for each MR and
thus only perform builds as necessary, but I'd like to hear all of your
thoughts on this.
If there are other questions or considerations you'd like to make, please let
me know. 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.
Max