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

[Erik Skultety]

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. 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