uber / h3-go / 39463153816
100%
master: 100%

LAST BUILD BRANCH: polyfill/rename-aabb
DEFAULT BRANCH: master
Ran
Jobs 1
Files 20
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 100.0%. Remained the same
39463153816

Pull #173

github

justinhwang 
conformance: build the generator from an H3 submodule

The generator compiled against the h3_*.c copies at the repository root,
which exist for the cgo binding. The binding is about to go, so the
reference sources move to a git submodule, third_party/h3, pinned at the
v4.5.0 tag and never modified. build.sh copies its src/h3lib sources into
a scratch tree, renders h3api.h from the CMake template, applies the
patches in internal/gen/patches and compiles gen.c against the result;
generate.sh and digests.sh call it. The one patch carries the atan2
latitude change the root copy already had by hand, so the suite's 1e-12
degree tolerance still holds; build.sh fails on a patch that is already
applied, which is the signal to delete it after a release contains it.

Nothing that builds or tests the module needs the submodule. A new CI job
checks it out and asserts that H3_VERSION, the submodule's VERSION, the
manifest's h3Version and the upstream tag's commit agree, then compiles
gen.c with -Wall -Wextra -Wconversion -Wpedantic -Werror; the library
itself is compiled without those flags, since upstream is not clean under
them. Regenerating every file and the resolution 7 digests from the
submodule build reproduces testdata byte for byte.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Pull Request #173: conformance: build the generator from an H3 submodule

4569 of 4569 relevant lines covered (100.0%)

4150919.5 hits per line

Jobs
ID Job ID Ran Files Coverage
1 Go- - 39463153816.1 20
100.0
GitHub Action Run
Source Files on build 39463153816