Skip to content

devnet-7: buildoor action-plan-rules canary on buildoor-lighthouse-geth-1 - #49

Merged
qu0b merged 1 commit into
masterfrom
qu0b/devnet-7-buildoor-action-plan-rules-canary
Jul 27, 2026
Merged

devnet-7: buildoor action-plan-rules canary on buildoor-lighthouse-geth-1#49
qu0b merged 1 commit into
masterfrom
qu0b/devnet-7-buildoor-action-plan-rules-canary

Conversation

@qu0b

@qu0b qu0b commented Jul 27, 2026

Copy link
Copy Markdown
Member

Runs the buildoor PR build with per-slot recurring action plan rules (ethpandaops/buildoor#147) on one builder only — buildoor-lighthouse-geth-1. The other three buildoors stay on default_tooling_images.buildoor (main-latest).

Why: a rule repeats a slot plan on the same slot index of every epoch, so "win slot 31 and withhold its payload" holds for a whole devnet run instead of a bounded slot list — the ePBS side of testing an epoch-boundary slot that produces no execution payload.

Behaviour on deploy: none. The rule set starts empty; the scenario is armed explicitly via the WebUI or POST /api/buildoor/action-plan/rules. Rules live in the state-db (/data/buildoor.sqlite), so they survive container recreates and watchtower updates.

Image ethpandaops/buildoor:qu0b-action-plan-recurring-rules-latest is a moving tag on purpose: this host is in the watchtower list, so further pushes to the PR branch roll out here automatically.

Revert: delete the file and re-run --tags buildoor --limit buildoor-lighthouse-geth-1.

@qu0b
qu0b merged commit 0844f81 into master Jul 27, 2026
@qu0b
qu0b deleted the qu0b/devnet-7-buildoor-action-plan-rules-canary branch July 27, 2026 12:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant