Standardized Development Environment

[faddat]

Description

Yesterday I made some changes to the standard dev env that we're using at Notional to make protobufs builds easier, and to my surprise, they "just worked". That includes adding docker to the image so that we could do protocol buffer builds. It also has all the protobuf tooling installed in the filesystem for those with container allergies.

image: ghcr.io/notional-labs/cosmos

That image is built here daily using cron via github actions and each build is observable.

https://github.com/notional-labs/containers/blob/master/cosmos/Dockerfile

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Code follows the module structure standards.
• Wrote unit and integration tests
• Updated relevant documentation (docs/) or specification (x/<module>/spec/)
• Added relevant godoc comments.
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[faddat]

@crodriguezvega hi!

Ok, so the reason to add a .gitpod.yml to ibc-go is that it can give us a fully-standardized dev env.

For example, many of us often struggle to build.proto files, and newbies sometimes struggle to set up Go.

With gitpod, we can ship a known-good dev env, and treat breakages in that as a bug.

Its only downside is what you just saw in #1734 -- the browsaer-based version of it adds the .gitpod.yml file to your repo each time.

That is why it keeps cropping up in my code, sorry about that.

I do think it's a really great velocity-booster, though.

For example, all of the best practices that the core ibc-go team follows when writing code for ibc-go, can be baked into a development container. That container can be launched remotely in-browser, or locally in goland via ssh, and then we're all working with the same set of tools.

[damiannolan]

Going to close this PR (spring cleaning). I think that any standardised development container for this repo should live and be documented within this repo if we were to add one.

Personally, I'm not familiar with gitpod and the impacts around it. If this is still relevant feel free to pick up the discussion in #2546.