Build Process and Github Actions

[CyrusVorwald]

This board is for the purposes of discussing issue #4 and #11.

[bbist]

The build, test and deployment process is fragmented across multiple integrations. There's a lot of redundant code and conflicting dependencies that have multiple sources. Therefore, I propose a repo restructuring scheme that includes:

1. Minimize effective code footprint by removing unused and conflicting dependencies. This minimizes the confusions and likelihood of introducing bugs.
2. Create a unified repo structure and abstraction that each integration can use to run consistent localnet, testnet, and mainnet deployments using github actions.
3. Create a set of github actions to build and deploy each integration's blockchain nodes, deploy and configure smart contracts, deploy iconbridge, and run the full set of unit, mock and e2e tests.

[bbist]

@MuhammedIrfan, @simsonraj, @dwdraju, @CyrusVorwald-ICON,

Please share your thoughts.

[bbist]

The organization of bmr go code and the contracts are pretty straightforward. The structure that's most important is the build/deploy automation that we all can share. It'd be even better if we can use the same flow that we use locally to be replicated in testnet/mainnet.

[CyrusVorwald]

Your suggestion to directory structure is largely in-line with what has been discussed so far. The key decision to make here is whether to go with a monorepo as you have written it, or a polyrepo. A polyrepo would be similar in structure, but broken up into 4 repos: relay, solidity-contracts, java-contracts, and rust-contracts. The folder provision you have would likely exist in each.

[bbist]

Yeah.
Should we move to polyrepo first, or should we start implementing the actions in this repo and later move to polyrepo?

What I'd recommend now, for the ease of implementing basic set github actions is that we start with restructuring current monorepo as mentioned above. We start with implementing e2etest github actions first, and gradually add unit, mock tests. The contracts will be separated and can be easily moved to polyrepo after this.

[CyrusVorwald]

I have no preference either way, so if you guys want to do a monorepo and keep similar structure to what is currently there then we can do that.

[CyrusVorwald]

Tagging @andrii-kl @mohamedelshami as well on this. Please state opinions and conduct discussions around this topic in this board instead of the weekly sync. Also, please summarize any follow up meetings on this specific topic here.

[mohamedelshami]

@CyrusVorwald-ICON @bbist this structure looks fine to me, and as mentioned it does align with what we already have.

Renaming cmd/btpsimple to cmd/bmr makes sense to me as it follows the same naming convention in the BTP spec. Is there a design motivation behind renaming the packages from what we have today?

I presume the chain-specific code will now move under `bmr/cmd/Ironbridge?

Similarly, I understand BTS is to differentiate the concrete service implementation the for BSH interface -- but deosn't BSH generally still have an abstract BSH implementation that is common for all concrete services?

With regard to the e2e Golang testing suite, happy to provide more detailed feedback on the relevant thread. But there are couple of points I have:

1. We can start to add basic github actions for build, test and release as per this issue here based on the make file.
2. Until the e2e Golang suite is mature enough, we can take advantage of the docker + scripts-based automation and integrate that in Github.

Generally speaking, the e2e integration testing can be an independent module on the top-level structure of the project and preferably triggered during pre-release action. It shouldn't take more than few mins to push and merge new code.

[CyrusVorwald]

What are the renamed packages?

[bbist]

The new structure would look something like this: https://github.com/icon-project/icon-bridge/tree/repo_mgmt_and_github_actions
Once we have basic github actions ready, we can make this the main branch and continue adding more actions. We'll slowly remove unnecessary packages, add new packages including hugobytes' rust contracts, and relay package.

In the meantime, we can keep working on bridge_hmny branch to fix the contracts and bsc relay issues, and get ready for beta launch.

[CyrusVorwald]

If the bridge_hmny branch is being used for beta launch, please move that to the main branch.

[bbist]

Okay. Will merge bridge_hmny to main, and start merging any new changes to main, while working on the github automations separately on repo_mgmt_and_github_actions.

[CyrusVorwald]

Sounds good.

To follow up on some of the discussion around having a staging environment, I do not believe that the complexity of the code base justifies a staging branch. There are a lot of tradeoffs to adding intermediary branches between dev and prod.

The goal is to minimize the amount of time to ship features to prod. This includes minimizing the amount of time branches are not merged into main.