This removes the git hash from gitian-build zcash version strings when
built inside gitian (when the state of the working tree is clean and
corresponds to an annotated tag).
We partially revert 8dbd2edd98 by removing
all instances of setting `GIT_DIR` in the gitian descriptors. Currently,
gitian builds cause zcash to have version strings which look like
`Zcash Daemon version v5.3.0-35186b009-dirty`, which is inaccurate.
Setting `GIT_DIR` with a current working directory of
`/home/debian/build/zcash/distsrc-x86_64-linux-gnu` makes the git
invocations in `genbuild.sh` see that directory as the top of the
working tree, which causes git to believe that a bunch of tracked files
were deleted (namely, those not included by the `make dist` step).
This causes `genbuild.sh` to believe that it is working with a dirty
tree, and with the help of `src/clientversion.cpp`, zcash gets a version
string that includes a hash ending in `-dirty`.
The release commit was built with a `make-release.py` that was before the parallel-gitian commit, causing the parallel gitian descriptor to not be updated.
Have updatecheck look in $XDG_DATA_HOME/zcash/updatecheck/token for the GH
token. Having one in the repo will still take precedence (for pre-existing
users, as well as if you want to override the token used in a particular
case). The new location is standardized, exists at the user level (as the token
logically does), and means that you don't need to copy files around if you get a
new clone or worktree to do a release.
- make the token optional (just will hit a rate limit after a few runs of the
script)
- only load the token once, rather than once per request (this is necessary
after the above change, so you don't get the warning printed repeatedly)
- switch from BasicAuth to an Authorization header (this means we no longer need
the GitHub username, just the token)
- support a token file that doesn't contain a username (it will still parse old
versions of the file properly)
Previously make-release.py checked dependency updates before checking out the
commit to be released. This could be annoying if the release branch had
everything up-to-date, but you ran the script from a different branch. Worse,
you could accidentally update the dependencies on your original branch, and have
it pass the release process with outdated dependencies.
When I cleaned up the debug log reporting, I included the path to the debug log
in the help message, which unfortunately required the base params to be
loaded. They don’t get loaded before the help message (and they shouldn’t), so
this caused an assertion failure.
The fix is to use “debug log” in the help message, rather than the path to the
actual debug log. This is the right thing to do, because the help message
explains how to set the path to the debug log, so the literal path when run with
`--help` would possibly not be the correct one at runtime.
Fixes#6184.
Greg Pfeil
Kris Nuttycombe
str4d
Greg Pfeil
Daira Hopwood
sasha
sasha