develop CI watch: red or missing push runs

[umeradl]

This is a long-running thread for reporting problems with CI on develop. Keep it open indefinitely: each incident gets its own new comment thread here.

Maintainers on CI watch: @Santiagocetran and @robertocarlous

Why this exists

Most merges into develop are done locally and pushed directly, and until now CI never ran on those pushes. PR No. 168 adds a push trigger, so every commit pushed to develop now gets its own CI run (Solidity, Python, Docs, CI OK). That run doesn't block anything, because the commit has already landed. It only shows whether the landed code is healthy, so someone has to look at it.

How it works

Normally, I handle it. When I push to develop, I make sure the push's CI run passes, or I add a fix commit on top to make it pass.

When it becomes critical, you step in. If a red (failed) or missing (never started) run on develop has gone unaddressed for about 6 hours or more, and more commits have landed on top of it, then:

• the breakage is being built on, and
• every later commit inherits the failure, so it's harder to tell which change broke what.

At that point, please don't wait for me: open a thread here (format below).

How to check

# latest push runs on develop: event, status, commit
gh run list --branch develop --event push --limit 10

# the run for one exact commit
gh run list --commit <sha>

Or open the Actions tab (filter: branch develop, event push), or the commit on GitHub, where a ✓/✗ next to it links to the run.

To find the commit that introduced the failure, walk back through the list to the oldest red run after the last green one. That commit is usually the culprit, not the newest one.

Reporting an incident: open a new top-level comment here

One thread per incident. Please don't reply inside someone else's incident thread unless it's the same failure. Include:

• Commit: the full SHA of the first failing (or run-less) commit on develop, plus the latest develop SHA if more have landed since
• Run: URL of the failing run, or "no run appeared"
• Failing job / test: e.g. Python → tests/test_x.py::TestY::test_z, with the key error line
• What's actually wrong: your read of the cause, if you have one (e.g. "test depends on the local config file", "contract change broke the upgrade-validation test")
• Since when: how long it has been red, and how many commits landed on top
• Proposed fix: optional. If you open a fix PR, link it.

I'll reply in the thread. Once it's fixed, the thread gets a final comment with the fixing commit SHA and the green run URL, so this discussion doubles as the incident log.

Notes

• This starts once PR No. 168 is merged. Before that, develop pushes have no CI run at all.
• The ruff (advisory) and forge lint (advisory) steps can show ##[error] without failing the job. Only a red job or a red CI OK counts as an incident.
• Related: CI/CD proposal in discussion No. 74.

[umeradl]

Admin bypass: f5b2284 — docs-only update to Developer/GOOD_FIRST_ISSUES.md for the public contributor call (item 0 marked done via PR #89; added #245 setup checker and #276 example model). Local CI mirror green.

[umeradl]

Admin bypass: 6e73dca — PR No. 288 was already approved (robertocarlous, on fe0bfa1) but had a minor conflict in Developer/BACK_LOG.md, so to save time it has been merged via bypass (path B).

[umeradl]

Admin bypass: 1f1431c — docs-only ROADMAP/BACK_LOG status refresh (issue No. 285); local CI mirror green.

[umeradl]

Admin bypass: 3e738c4 — docs-only: develop README banner, closing-keyword rule and skills-first wording in MAINTAINING/CONTRIBUTING, before switching the default branch to develop (Abraham item 7).

[umeradl]

Admin bypass: e9424af — path B merge of PR No. 297: branch was BEHIND develop on docs-only drift and the fork CI run for the empty re-trigger head 9ccf090 was awaiting approval; tree identical to green-CI d1b6bdc. Local precheck OK.

[umeradl]

Non-blocking job red on develop: Integration (full GI), failing on every run since it was added.

• Failing runs on develop: 954fbf8 (the merge of PR No. 242 that added the job, 2026-10-27) and e9424af (PR No. 297, 2026-10-29). The job was path-skipped on the docs-only pushes in between. It also failed on all four of PR No. 242's own runs, so it has never passed.
• Failure: tests/dincli/test_01_platform.py::test_deploy_platform_via_script: missing proxyAdmin in foundry/deployments/localhost.json.
• Root cause: b49c843 (2026-07-22) made DeployPlatform.s.sol record one ProxyAdmin per proxy (proxyAdminToken, proxyAdminCoordinator, …; seven of them). The harness still reads a single deployments["proxyAdmin"] (test_01_platform.py:135/137/164). The job runs pytest -x, so later tests in the suite never ran; more stale-suite failures may follow once this one is fixed.
• Why it wasn't logged earlier: the job is continue-on-error and not part of CI OK, so the workflow run reports success and the din-push-develop watcher reported it as green. Not a red-develop incident under MAINTAINING No. 4.6, but it should have been raised.
• Fix: a PR from umermjd11 updating the harness to the per-proxy keys is coming; I'll link it here.

[umeradl]

Correction to the entry above: the failure was known and accepted, not missed. Issue No. 228 planned the job as non-blocking. The assignment comment (#228 (comment)) said to expect it to fail after test_01 until task_061026_21 Part D lands, and PR No. 242 was merged with that known proxyAdmin stop noted.

Decision (2026-10-29): a full GI is too heavy to run on every commit or push, so the job becomes a manual-only workflow (.github/workflows/full-gi.yml, workflow_dispatch) that is never a required check: PR No. 301. PR No. 300 is closed; its two harness fixes move into Part D.

[umeradl]

Fix PR for the full-GI missing proxyAdmin failure above: PR No. 300 (#300). Phase 1 passes locally in isolated mode (8/8); its CI run will be the first to show how far the suite gets past phase 1.