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