Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/JuliaRegistries/TagBot/issues/281 below:

Subdirectory support broken due to wrong tree hash verification · Issue #281 · JuliaRegistries/TagBot · GitHub

If I am not mistaken, the current implementation for supporting subdirectory tagging is broken due to an apple-with-oranges-style comparison of the commit tree hash and the package tree hash, which are not identical for subdirectory tags.

After #279 had been merged, we tried to use TagBot to tag a new release of LibTrixi.jl, which lives in the LibTrixi.jl subdirectory of https://github.com/trixi-framework/libtrixi. Correspondingly, we have configured TagBot with subdir: LibTrixi.jl.

However, during its run, TagBot quit early with the following messages:

Warning: Tree SHA of commit from registry PR does not match
Warning: No matching commit was found for version v0.1.2 (7911434c8b808550e3bd6c321dd50da91b128a9e)

(see this log message).

The "Tree SHA ... does not match" error comes from the following snippet:

where

holds the first 32 characters of the

hash that has been extracted from the PR body of the corresponding PR to

. In our case, it got the

hash

from

.

As an additional safety measure (or maybe it is required to catch ambiguities, but I cannot see where they might come from), in line 259 the tree hash of the registered commit (commit.commit.tree.sha) is compared against the tree hash stored in the Julia registry for the corresponding package version. In our case, the version is v0.1.2, and TagBot extracted the package tree hash 7911434c8b808550e3bd6c321dd50da91b128a9e from this file.

And this is where the problem is located: The package tree hash 7911... is obtained by computing the git tree hash of the package directory, which in our case is the subdirectory LibTrixi.jl. The commit tree hash, against it is compared here, however, is computed on the entire repository.

To quickly verify that they are different, you can check the different strings from the libtrixi repo:

git clone git@github.com:trixi-framework/libtrixi.git
cd libtrixi
git show --name-only 6e615c91364595e8ad1feca67ebfbb391c4ede00 --pretty=raw | grep ^tree | awk '{print "commit tree hash: ", $2}'
echo "package tree hash: $(git rev-parse HEAD:LibTrixi.jl)"

which will output something like

commit tree hash:  26cb3d6465884c915ee97f20e4d6c978338782f5
package tree hash: 7911434c8b808550e3bd6c321dd50da91b128a9e

Obviously, this comparison of the commit tree hash and the package tree hash is bound to fail whenever the package lives in a subdirectory of the repository.

Currently, I see no obvious way out of this: Relying on the tree hash to determine the appropriate commit hash works only if the tree hash was computed for the entire repository, as otherwise there is no unique tree hash -> commit hash relation anymore. Since we are not interested in the content here (in which case that would be fine) but in the unique commit, this mechanism does fundamentally not work for subdirectory tags.

The only viable option I see atm is to remove the fallback mechanism for the commit identification and solely rely on the registry PR information. If this is not an option, one could consider doing this only for subdirectory tags and to leave the existing machinery in place for full-repo tags. Removing the (currently usuable) subdirectory support is imho not an option.

What are your thoughts on this @christopher-dG @IanButterworth (and maybe @hannahilea)?

cc @bgeihe

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4