ci: run monorepo CI suite on op-geth PRs

[geoknee]

When making a change to op-geth, we should be in the practice of preparing a monorepo PR consuming those changes, so that the monorepo CI (which contains the majority of our end-to-end tests) can provide a harness and protect against changes which break the desired behaviour of the system as a whole.

We usually remember to do this for significant changes such as upstream merges, but have been guilty of neglecting to do so for smaller changes / refactors.

We should consider automating this task so that we do not need to rely on engineers remembering to do it.

Solution A

A naive solution would have a CI job which clones the latest monorepo commit, updates the go.mod to point at the code being submitted in the PR, and runs the rest of the monorepo suite as usual.

Problems which would arise in the naive version:

• the monorepo suite can change a lot including how it is triggered in CI; how do we "import" the CI configuration into the op-geth CI configuration so that we get all the latest monorepo tests running?
• upstream merges are often expected to break something in the monorepo; the usual flow for those PRs is to have a monorepo PR which references the new op-geth code plus any changes in the monorepo required to cope with the changes. Therefore we can expect upstream merges (and other PRs which intend to break something) to have this new CI check fail. That could be solved by having the check be lablled "for information only" (and therefore ignorable by such PRs, which can follow the usual pattern).

Option B

Another alternative would be have a lightweight CI check in op-geth which checks for the existence of an actual monorepo PR referencing the new code with passing tests. This check can be cheaply re-run by the PR author when they have that monorepo PR prepared. This meshes nicely with existing practices for significant PRs, but would require a little more manual work from PR authors which might be considered bothersome for small changes. IMO this is probably the right amount of friction to add here. Monorepo PRs could be automatically created by an op-workbench command, which would put the commit hash in the PR title to make it easy to find for the new CI job. Or, the new CI job accepts the monorepo PR number as an input parameter which the user supplies when it is launched.

[ajsutton]

Option C would be to have a periodic job in the monorepo that checks if it is using the latest op-geth commit from optimism branch. It would notify in slack if it fails. This doesn't prevent creating the problem but does alert us to it pretty quickly and we can fix it either by updating the monorepo if it's easy or reverting the op-geth commit if not. Downside is that you will get some false alarms if the job runs between the op-geth PR merging and the corresponding monorepo PR merging.

No strong opinion on the best option here but thought I'd throw this out there.