Greptile Summary

This PR wires the Lean Hive simulator suites into GitHub Actions by adding a docker_build job that exports the ethlambda image as an artifact and a run-hive matrix job covering nine simulator categories. A results-checker script parses Hive JSON output and surfaces failures in the step summary.

• docker_build is never triggered: its if guard references needs.detect-changes.outputs.run_tests, but no detect-changes job exists in the workflow and needs: detect-changes is not declared — the condition is permanently false, skipping docker_build and every dependent run-hive job on every run.
• Failure artifact upload has a logic gap: the upload step only fires when the results-checker script fails, not when the Hive simulation step itself crashes; the verify-hive-results step is skipped on simulation failure, so its conclusion is never 'failure' and no artifacts are uploaded.
• Dead devnet3 config: clients.yaml registers both devnet3 and devnet4, but the workflow only uses ethlambda_devnet4.

Confidence Score: 3/5

Safe to merge from a runtime-behavior standpoint — no client code is changed — but the new CI jobs will never execute as written.

The docker_build job references a detect-changes job that does not exist anywhere in the workflow, making its if condition always false. All nine Hive matrix jobs depend on docker_build, so they are also permanently skipped. The PR's stated goal of running Lean Hive simulators in CI is entirely unmet until this is fixed. There is also a secondary gap where simulation-level crashes produce no uploaded artifacts.

ci.yml needs the if condition on docker_build either removed or replaced with a valid guard; the failure-artifact upload condition also needs revision.

Important Files Changed

Fix the following 3 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 3
.github/workflows/ci.yml:150-153
**`docker_build` always skipped — `detect-changes` job does not exist**

The `if` condition references `needs.detect-changes.outputs.run_tests`, but `docker_build` has no `needs: detect-changes` declaration and the workflow defines no `detect-changes` job at all. GitHub Actions evaluates `needs.detect-changes` as an empty context, so the expression `needs.detect-changes.outputs.run_tests == 'true'` is permanently `false`. Every run of this workflow will skip `docker_build`, and because `run-hive` declares `needs: docker_build`, every Hive matrix job is skipped as well — making the entire new CI path a no-op.

### Issue 2 of 3
.github/workflows/ci.yml:268-274
**Failure artifacts not uploaded when the Hive simulation itself crashes**

The upload condition `failure() && steps.verify-hive-results.conclusion == 'failure'` only fires when the explicit results-checker script exits non-zero. If the `Run Hive Simulation` step itself fails (e.g., Hive crashes, network timeout, bad Docker image), the `Check Hive Results For Failures` step is skipped (its guard is `if: success()`), leaving `steps.verify-hive-results.conclusion == 'skipped'`. The compound condition is never satisfied, so no artifacts are uploaded on simulation-level failures — exactly the case where diagnostic logs would be most useful.

### Issue 3 of 3
.github/workflows/ci.yml:252-260
**`client` field hard-codes `devnet4` and ignores the `devnet3` nametag**

`clients.yaml` registers both `ethlambda` with `devnet3` and `ethlambda` with `devnet4`, but `client: ethlambda_devnet4` is used unconditionally in the simulation step. The `devnet3` entry appears to be dead config — if it is truly needed for some simulators, it should be referenced in the matrix; if not, it should be removed from `clients.yaml` to avoid confusion.

Reviews (1): Last reviewed commit: "ci: add Hive config for both ethlambda d..." | Re-trigger Greptile

Reviewed this from a security angle since it touches CI and comes from outside the org. Overall it's in good shape — workflow correctly uses pull_request (not pull_request_target), no new secrets are introduced, push: false on the docker build, and check-hive-results.sh is properly quoted. Two hardening suggestions:

1. Add an explicit permissions: block.
The new jobs inherit the workflow defaults. For fork PRs the token is read-only anyway, but pinning permissions explicitly makes the intent obvious and protects against future workflow changes silently widening scope. Suggestion:

docker_build:
  permissions:
    contents: read
  ...
run-hive:
  permissions:
    contents: read
  ...

2. Pin ethpandaops/hive-github-action by commit SHA, not by tag.
Tag pins (@v0.5.0) can be moved if the upstream tag is force-pushed or compromised. Replacing with the commit SHA + a comment with the version is the standard hardening:

uses: ethpandaops/hive-github-action@1aa8d73dad34de13afbb3113ab16c1a462d2fbc3  # v0.5.0

Optional: while you're there, v0.5.0 is a few releases behind latest (v0.6.3) — happy to keep v0.5.0 for parity with ethrex's workflow, or bump if you'd prefer to be on the current release.

Neither is blocking — the PR is safe to run as-is from a fork — but these would harden it. Functional/cosmetic feedback to follow in a separate comment.

Reviewed this from a security angle since it touches CI and comes from outside the org. Overall it's in good shape — workflow correctly uses pull_request (not pull_request_target), no new secrets are introduced, push: false on the docker build, and check-hive-results.sh is properly quoted. Two hardening suggestions:

1. Add an explicit permissions: block. The new jobs inherit the workflow defaults. For fork PRs the token is read-only anyway, but pinning permissions explicitly makes the intent obvious and protects against future workflow changes silently widening scope. Suggestion:

docker_build:
  permissions:
    contents: read
  ...
run-hive:
  permissions:
    contents: read
  ...

2. Pin ethpandaops/hive-github-action by commit SHA, not by tag. Tag pins (@v0.5.0) can be moved if the upstream tag is force-pushed or compromised. Replacing with the commit SHA + a comment with the version is the standard hardening:

uses: ethpandaops/hive-github-action@1aa8d73dad34de13afbb3113ab16c1a462d2fbc3  # v0.5.0

Optional: while you're there, v0.5.0 is a few releases behind latest (v0.6.3) — happy to keep v0.5.0 for parity with ethrex's workflow, or bump if you'd prefer to be on the current release.

Neither is blocking — the PR is safe to run as-is from a fork — but these would harden it. Functional/cosmetic feedback to follow in a separate comment.

I will work on the reviews. Thanks!

Neither is blocking — the PR is safe to run as-is from a fork — but these would harden it. Functional/cosmetic feedback to follow in a separate comment.

I will work on the reviews. Thanks!

@pablodeymo I implemented the suggested CI hardening updates:

• added explicit permissions blocks
• pinned ethpandaops/hive-github-action by commit SHA

Would appreciate another review when you have time. Thanks!

@dicethedev The new jobs are failing

The new jobs are failing

I will check it right way

The new jobs are failing

@MegaRedHand I’ve just updated my branch, but I’m not seeing any failed jobs or errors to address.

The new jobs are failing

@MegaRedHand I’ve just updated my branch, but I’m not seeing any failed jobs or errors to address.

still waiting @MegaRedHand

@dicethedev there: https://github.com/lambdaclass/ethlambda/actions/runs/26045835459/job/76766701172?pr=364

@dicethedev can you please solve the merge conflicts?

It's still failing 😞

It's still failing 😞

I will check why is still failing and I will also investigate other clients too.

It's still failing 😞

can we review this again? Add a fix to it. This fixes the Hive CI failure by moving to a Hive revision that includes the root Cargo.lock required by the lean simulator Dockerfile, tagging the local ethlambda image for both devnet4 and devnet5, and uploading Hive logs/results on any failure.

It's still failing 😞

can we review this again? Add a fix to it. This fixes the Hive CI failure by moving to a Hive revision that includes the root Cargo.lock required by the lean simulator Dockerfile, tagging the local ethlambda image for both devnet4 and devnet5, and uploading Hive logs/results on any failure.

@MegaRedHand

@dicethedev this hive job is failing due to an unauthenticated rate limit: https://github.com/lambdaclass/ethlambda/actions/runs/31505951897/job/93833968504?pr=364

Also, can you check why some tests are failing? This one for example: https://github.com/lambdaclass/ethlambda/actions/runs/31505951897/job/93833968743?pr=364

@dicethedev this hive job is failing due to an unauthenticated rate limit: https://github.com/lambdaclass/ethlambda/actions/runs/31505951897/job/93833968504?pr=364

Also, can you check why some tests are failing? This one for example: https://github.com/lambdaclass/ethlambda/actions/runs/31505951897/job/93833968743?pr=364

I will look into the issue and revert back Mega

I will look into the issue and revert back Mega

can you review again and let's see the report this time