[libvirt] [jenkins-ci PATCH v3 10/12] lcitool: Support building arbitrary branches

[Andrea Bolognani]

On Thu, 2018-08-23 at 14:36 +0200, Erik Skultety wrote:
> On Wed, Aug 22, 2018 at 11:44:25AM +0200, Andrea Bolognani wrote:
> > Building master is useful for CI purposes and to debug CI
> > failures locally, but when developing we want to be able
> > to build a personal branch to validate in-progress changes.
> > 
> > Signed-off-by: Andrea Bolognani <abologna at redhat.com>
> > ---
> >  guests/lcitool                           | 30 ++++++++++++++++--------
> >  guests/playbooks/build/jobs/defaults.yml |  1 -
> >  2 files changed, 20 insertions(+), 11 deletions(-)
> > 
> > diff --git a/guests/lcitool b/guests/lcitool
> > index 2901a92..ec81448 100755
> > --- a/guests/lcitool
> > +++ b/guests/lcitool
> > @@ -351,8 +351,13 @@ class Application:
> >              metavar="PROJECTS",
> >              help="list of projects to consider",
> >          )
> > +        self._parser.add_argument(
> > +            "-b",
> > +            metavar="BRANCH",
> > +            help="git branch to use when performing builds",
> > +        )
> 
> I agree with the idea, but the interface as proposed by the patch is not very
> convenient from user experience POV. The reason for that is having to specify a
> branch without a repo which IMHO feels incomplete, because if you actually need
> to use a custom branch, you most probably are testing a feature which means you
> want to work with your private copy of the upstream repo.
> You can modify the project's config, but that IMHO stops being convenient very
> soon as one day you want to test upstream CI failures locally and then test
> your feature the other, thus having to modify the git_url in the config each
> time. So, we need a quick cmdline override to make this a better interface.

Agreed, the current interface doesn't quite work.

> We
> also might want to have this working when building multiple projects, e.g. I'm
> working on a feature in libvirt and then propagate the necessary changes into
> virt-manager, so I want to build both projects using a custom repo and branch.
> 
> The other thing I quite don't don't agree with is having the cmdline parameter
> mandatory, as a user, I'd expect that if I don't specify the repo and branch,
> the default which we already ship would be used, so my preference would be to
> have it optional.

I'll have to think hard about this. All of the current arguments
are mandatory, so I would like to stick with that unless there's
a compelling reason not to; perhaps in this case it's okay to make
the arguments optional, but maybe all we need to do is provide a
convenient enough shorthand for "build the master branch of the
upstream repository" and the problem will basically disappear.

> Since we already had a private discussion about possible approaches, I'll leave
> summarizing that on the list to you. Nevertheless, the series doesn't really
> depend on this patch and we can already start profiting from what the other
> patches provide and work on top of that.

Yeah, let's drop this patch for now: being able to build upstream's
master branch conveniently is already a good feature to have, and
once we have that in adding more becomes feasible.

-- 
Andrea Bolognani / Red Hat / Virtualization