[git-buildpackage] Tracking remote pristine-tar on salsa

[Guido Günther]

Hi,
On Wed, Aug 08, 2018 at 08:56:50AM +0200, Agustin Henze wrote:
> Hi Guido,
> 
> On 08/07/18 21:53, Guido Günther wrote:
> [...]
> >>  - gbp pull --ignore-branch
> >>  - gbp buildpackage --git-ignore-branch --git-export-dir=${WORKING_DIR} -us -uc
> >>
> >> All seems to work fine (actually it does work), but we found that gbp is not
> >> using the `pristine-tar` branch for building the orig tarball. Reading the doc,
> >> I can see the recommended way is using gbp clone but here we don't have any
> >> control over how Gitlab does the cloning. Is there a gbp friendly command to
> >> track the remote pristine-tar branch after the repo was cloned using just `git
> >> clone`?
> > 
> > In gitlab-ci this would be somthing like
> > 
> >    script:
> >       - git fetch origin pristine-tar
> >       - git branch pristine-tar FETCH_HEAD
> > 
> > or did I misunderstand your question?
> 
> Yeah, that could work. Oh, rereading my previous email I see that I didn't
> explain the whole scenario correctly, sorry. We are trying to write a pipeline
> that could be applied to any repository i.e. there are repositories with
> pristine-tar and there are other repositories without it. So as far I can see
> there isn't an automagically way for telling gbp track the origin pristine-tar
> if it's present. One of the goal if to KIS as possible and writing a
> detection

The good thing is that gbp buildpackage doesn't need to track
it. pristine-tar (as invoked by gbp buildpackage) just needs to be able
to find the commit.

> first if pristine-tar is enabled (maybe using gbp config) and then fetching the
> remote it doesn't sound very simple. If I write a patch with a new option like
> --git-force-track-remote-pristine-tar or something like that, are you willing
> to merge it?

I'm always happy to merge good patches but let's try to sort out what
needs to be done first?

"gbp buildpackage" does no remote fetching (and that's on purpose). So
either you already have the pristine-tar commits in your local repo (let's
ignore the branch name for the moment) when you start the build or you
haven't. In the later case s.th. else needs to fetch it.

That would be "gbp pull"'s job but gbp pull wasn't able to pick up
new branches from the remote side so I just did:

    https://git.sigxcpu.org/cgit/git-buildpackage/commit/?id=6dda2da54efbb81e4e1593d57eb5f30c4ef1e6d8

I'm not opposed to a "use-pristine-tar when available and fall back to
tarball creation" but I think that's already there in a hacky way with the
"--git-pristine-tar --git-pristine-tar-commit" options (use
pristine-tar, if not create tarball and commit it to the
pristine-tar branch). So what about:

    - gbp pull --debian-branch= --upstream-branch= --pristine-tar --track-missing
    - gbp buildpackage --git-pristine-tar --git-pristine-tar-commit

Now pristine-tar-commit wastes time so we can make this nicer by adding
a list of methods for tarball creation to gbp export-orig:

    - gbp export-orig --from="pristine-tar,upstream-ref"

"gbp buildpackage" and "gbp export orig" use the same logic internally
to build tarballs but export-orig should be simpler to deal with since
it carries less "don't break existing installation" code. So a patch to
make this possible would be great. In gitlab CI this would then become:

    - gbp pull --debian-branch= --upstream-branch= --pristine-tar --track-missing
    - gbp export-orig --from="pristine-tar,upstream-ref"
    - gbp buildpackage

Which is also splits the responsibilities nicely and makes it obvious
for someone looking at the output where the error happened. The above
list of tarball creation methods could later on be used to say:

    - gbp export-orig --from="pristine-tar,download,upstream-ref"

which is of lesser use to CI but for

     https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=902249

It would be great to make using gbp as simple possible in your
gitlab CI pipelines.
Cheers,
 -- Guido