Wire up hive tests on CI

[SamAg19]

fixes #117

Checklist

Self-check your solution before submitting:

• Verify make test-hive works, on a clean repo checkout, without additional setup (apart from system installation, like go toolchain);
• Verify that running make test-hive second time doesn't rebuild hive itself;
• Verify that running make test-hive HIVE_VERSION=<some_other_commit_hash> rebuilds hive properly and re-runs tests;
• Verify that modifying code in grandine (you can just insert some print in ./lean_client/src/main.rs`) rebuilds docker image and re-runs hive tests;
• Verify that your script runs all hive tests, available for grandine lean client;
• Verify your CI works (not necessarily passes, just runs tests) on your own fork;
• Verify that make clean cleans up hive directory;
• Don't forget to update README.md - include section what needs to be installed (probably only go toolchain) for running hive tests, and how to run them.

Additions beyond the checklist:

• Per-suite summary - each suite's pass/total count + names of failed test cases, printed to the job logs and rendered as a GitHub Step Summary panel.
• Infra-vs-test failure semantics - a completed run with failing tests is reported but does not fail the job; only a genuine build/run failure (no results produced) fails it. A red check means the pipeline broke, not that a spec test failed.
• Label-gated CI — runs only on PRs with the run-hive label (plus manual workflow_dispatch), not on every push, since the full suite is slow.

Example run (summary panel on the Summary page): https://github.com/SamAg19/lean/actions/runs/30262177584?pr=1; the committed workflow runs the full suite. Example PR where i tested out everything: SamAg19#1

[SamAg19]

@ArtiomTr @bomanaps The PR is ready for review

[ArtiomTr]

Very good, although small fixes still needed

[ArtiomTr]

probably fine to run this on every PR, because if it isn't running automatically, then probably no one will run these

[ArtiomTr]

Claude said:

One thing worth knowing: -not -path filters results but doesn't prune traversal, so find still walks all of ./target/, which can be slow on a large build dir. -path './target/*' -prune -o ... -print avoids that.

Don't know if that's true, but probably still worth looking - target directory can indeed be large and slow down source file discovery.

[ArtiomTr]

Probably would be better to put variables on top of the file, next to all other variables - this way it becomes a bit more obvious how we can parametrize our make runs.

[ArtiomTr]

also, probably no need to have 2 variables here - both HIVE_VERSION and HIVE_REF? If you want to set default version, then you can just do:

HIVE_VERSION ?= master

?= already means "assign if unset".

[ArtiomTr]

Not exactly sure, but I think we should be able to parametrize the devnet5 part