Re: [Buildroot] [PATCH 1/2] package/Makefile.in: set GIT_DIR=. in {HOST, TARGET}_MAKE_ENV

[Peter Korsgaard <peter@korsgaard.com>]

>>>>> "Jan" == Jan Kundrát via buildroot <buildroot@buildroot.org> writes:

 >> In the context of Buildroot the packages are never built in their own git
 >> checkout, so pass GIT_DIR=.  to ensure git doesn't walk back up the
 >> directory tree and finds the Buildroot git repo, which fixes the rauc (and
 >> similar) issues.

 > This has caused a regression for us.

Sorry to hear that.

 > We're using Zuul CI [1] which is set up so that any patch that's
 > uploaded for review in any of our internal projects also triggers a
 > test build through Buildroot. Some of these builds would use sequences
 > of yet-unmerged patches, so tracking version info of each component is
 > crucial, which is why we're puting all that into the target's
 > /etc/os-release, as well as relaying on the build system to call an
 > equivalent of a `git describe` for each of our projects.

 > For this feature, we're relying on a few hooks:

 > - Zuul itself produces the correct content as a git checkout in a
 >   scratch directory,

 > - Buildroot is configured via `local.mk` to use that checkout as a
 >   source [2]

 > - a custom hook sets up the redirection via the `gitdir` statement in
 >   the buidlroot's copy of the source directory [3], this redirection
 >   however  takes effect at runtime (see [4])

I don't understand why you do > \$(@D)/.git, I was would have
expected >> \$(@D)/.git/config but OK.


 > - the build script of each app then simply runs `git describe` with a
 >   few flags for output formatting; the apps currently do not have a
 >   way of accepting some externally provided version strings.

 > Some of our projects use git submodules, which means that manipulating
 > .gitdir has to be done carefuly. The TL;DR version is that this is a
 > bit more complex than just putting a version override into a file. In
 > short, there's already a git checkout that's been prepared with
 > accurate version info, and it makes sense to use that info as-is -- or
 > it has worked well for us in the past three years :), up until this
 > commit.

I guess those are local/custom packages that you have in your external
tree? Can you pass GIT_DIR=.git to them (or make them unset GIT_DIR) to
make them use your prepared .git directory?


 > How are you guys solving this problem in your CI systems?

This is not applicable to the CI done for Buildroot itself (where we
want to build the versions specified in the .mk files). For $WORK, I
have populated a file in a post-build script like your os-release file.


 > Is there a chance of undoing this global GIT_DIR which,
 > unfortunately, takes precedence over the projects' own .gitdir
 > mechanism?

The problem this change tried to fix is real, so the question is how we
can continue to fix this issue (without having to play whack-a-mole for
each package) which still supporting a use case like yours.

Thanks for the heads up!

-- 
Bye, Peter Korsgaard
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot