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@xxxxxxxxxx> > > --- > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
