fix(build): Fix version detection in sparse git checkouts (#803) #818
Conversation
Previous fix got us into the case statement but didn't provide any useful information once we got there. This provides *something*, at least.
| @@ -152,7 +152,8 @@ then | |||
| # derive a version string. | |||
| elif test "`git log -1 --pretty=format:x . 2>/dev/null`" = x \ | |||
| && v=`git describe --tags --abbrev=7 --match="$prefix*" HEAD 2>/dev/null \ | |||
| || git describe --tags --abbrev=7 HEAD 2>/dev/null` \ | |||
| || git describe --tags --abbrev=7 HEAD 2>/dev/null \ | |||
| || git log -1 --pretty=format:'v0-HEAD-%h' 2>/dev/null` \ | |||
There was a problem hiding this comment.
This won't work on some kinds of checkouts. I'll think about this one a bit...
There was a problem hiding this comment.
git describe has an --always flag that returns a bare SHA if there is nothing else available. This might be useful:
$ git describe
fatal: No names found, cannot describe anything.
$ git describe --always
12d7610There was a problem hiding this comment.
Also you may be able do a git fetch --depth 100 or some number that is likely to be more than the time since the last release to try to get the tag.
There was a problem hiding this comment.
Doing a fetch in the build system is problematic because some environments don't have access to the credentials or network access for it. Also I'm not sure --always is what we want here because this is supposed to fail if we aren't sure what we are. I actually had to take it off of here to solve a different problem.
There was a problem hiding this comment.
Okay I've done a bit of poking and --always does break what this is supposed to do in some scenarios, and ding a git fetch from inside our build system is out of the question, but this change as presented doesn't do any harm. It's slightly more information about a broken build environment than we would have otherwise. I still think the real solution is to make sure git based builds are never shallow clones, but this is all we can do from inside the SILE source.
| @@ -152,7 +152,8 @@ then | |||
| # derive a version string. | |||
| elif test "`git log -1 --pretty=format:x . 2>/dev/null`" = x \ | |||
| && v=`git describe --tags --abbrev=7 --match="$prefix*" HEAD 2>/dev/null \ | |||
| || git describe --tags --abbrev=7 HEAD 2>/dev/null` \ | |||
| || git describe --tags --abbrev=7 HEAD 2>/dev/null \ | |||
| || git log -1 --pretty=format:'v0-HEAD-%h' 2>/dev/null` \ | |||
There was a problem hiding this comment.
Okay I've done a bit of poking and --always does break what this is supposed to do in some scenarios, and ding a git fetch from inside our build system is out of the question, but this change as presented doesn't do any harm. It's slightly more information about a broken build environment than we would have otherwise. I still think the real solution is to make sure git based builds are never shallow clones, but this is all we can do from inside the SILE source.
alerque
added
enhancement
It's a public project. No credentials are needed (as long as you have used the http url to clone it). Some CI environments don't have network access? That sounds very odd - how do they get the code in the first place? Also you could use a |
@rjmunro That's not the issue. Some build systems insist that builds work offline. The build bot downloads the sources, puts them inside a chroot or container, then executes the build scripts. More and more build systems are insisting that the process work offline as a way of ensuring isolation, than only the approved checksummed code is being used, etc. We currently fall short of this in another area: the test suite tries to download fonts that are not in the source tarball (see #772) but it is possible to build offline. Doing a |
Previous fix got us into the case statement but didn't provide any useful information once we got there. This provides something, at least.