[ENG-2210][ENG-2200] synd-cli

[calebguy]

Ticket

• Related Linear Ticket: Ticket-Number

What does this PR do?

• Summary:
  • Moves create-chain to a CLI
  • Updates call to RollupCreator.createRollup() to only pass required fields for Syndicate Appchains (no validators, batch posters, batch post manager, or fee token pricer)
  • Uses non-forked versions of v3.1.1 nitro contracts
  • Pass options from a config file like --config path_to_options.json
  • Generate example option configs with bun synd-cli <cmmd> init (bun synd-cli appchain create foundation init will write an example config file to options/foundation.json)
  • Pre-commit hook for formatting

Breaking changes?

• Yes/No:
  • No

Anything interesting?

• We can add any additional helpers here for deploying & maintaining appchains

How can this PR be tested?

• bun synd-cli -h

[daniilrrr]

lgtm

dumb q but are there any low time commitment/ "low-hanging fruit" approaches we could take to validating that create-chain works in CI and that a new PR hasn't broken it? Would prefer to know proactively if create-chain works vs finding out in a a deployment or from a customer. It doesn't have to be super comprehensive but even checking if things like if new lib/tooling/contract versions have broken something would be helpful to reduce the feedback loop

separate question - is there a release artifact that gets produced for synd-cli "releases" like we produce Docker containers for the other services? Maybe something like a bun executable? If so, I think we should have a Github action for that to create it as part of the release flow

[daniilrrr]

any way we can assert or unit test this ?

[calebguy]

Will follow up with tests in an additional PR so this one does not get unwieldy, ty!

[calebguy]

lgtm

dumb q but are there any low time commitment/ "low-hanging fruit" approaches we could take to validating that create-chain works in CI and that a new PR hasn't broken it? Would prefer to know proactively if create-chain works vs finding out in a a deployment or from a customer. It doesn't have to be super comprehensive but even checking if things like if new lib/tooling/contract versions have broken something would be helpful to reduce the feedback loop

separate question - is there a release artifact that gets produced for synd-cli "releases" like we produce Docker containers for the other services? Maybe something like a bun executable? If so, I think we should have a Github action for that to create it as part of the release flow

Yup totally - We currently cover this with 2 GH actions. 1 to make sure the ABIs the CLI uses are up to date with the source code (similar to how we check the contract bindings for the portions of the stack where we utilize rust & go). & another that typechecks the CLI. If the ABIs are out of sync the first action fails. If the ABIs are in sync but the cli code hasn't been updated yet, the 2 action will fail. Added support for publishing builds in 4d600636!

[ericvelazquez]

🚢