cosmos-sdk
                                
                                
                                
                                    cosmos-sdk copied to clipboard
                            
                            
                            
                        feat: Build own docker image and use ghcr
Description
Closes: #11657 Closes: #11688
This PR changes the Dockerfile in the repository root to a rolling-release Docker image that is built here and keeps itself up to date.
Simapp and other docker images that come from the SDK could start with this.
In CI, we could set it up to build this, and push it only when it is on main. The main branch's docker image becomes canonical for current and past versions of the cosmos-sdk, and can be used in tm-db and iavl testing, too.
Merging this
This PR comes in two stages:
- is merged to main and then we wait 60ish minutes to make sure cron is working
 - when cron is verified working, we change all other images to consume ghcr.io/cosmos/cosmos-sdk, and this will make build times as least as fast as they were previously, but every image will be built and stored here, and updated every time that code is pushed to main.
 
Once this is merged we can immediately clear dependencies that aren't in this repository because we will get ghcr.io/cosmos/cosmos-sdk
images.
Matienance
These images do not have a tagged go version.  Like developer laptops, they will always use the latest go, the latest rocksdb, and the latest leveldb.  This way, our CI system will more closely reflect a developer laptop.
Author Checklist
All items are required. Please add a note to the item if the item is not applicable and please add links to any relevant follow up issues.
I have...
- [x] included the correct type prefix in the PR title
 - [ ] added 
!to the type prefix if API or client breaking change - [x] targeted the correct branch (see PR Targeting)
 - [x] provided a link to the relevant issue or specification
 - [x] followed the guidelines for building modules
 - [x] included the necessary unit and integration tests
 - [x] added a changelog entry to 
CHANGELOG.md - [ ] included comments for documenting Go code
 - [ ] updated the relevant documentation or specification
 - [x] reviewed "Files changed" and left comments if necessary
 - [x] confirmed all CI checks have passed
 
Reviewers Checklist
All items are required. Please add a note if the item is not applicable and please add your handle next to the items reviewed if you only reviewed selected items.
I have...
- [ ] confirmed the correct type prefix in the PR title
 - [ ] confirmed 
!in the type prefix if API or client breaking change - [ ] confirmed all author checklist items have been addressed
 - [ ] reviewed state machine logic
 - [ ] reviewed API design and naming
 - [ ] reviewed documentation is accurate
 - [ ] reviewed tests and test coverage
 - [ ] manually tested (if applicable)
 
Steps to putting this into action:
- Decide if pinning versions is a hard requirement
 - push this to ghcr.io/cosmos/cosmos-sdk when it hits master
 - base other images on this one, throughout cosmos
- simapp
 - simd
 - protobufs build image
 
 
Breaking is a feature, not a bug. When Go is out of date on my laptop, it yells at me, and I update it, and I imagine that is the same for >95% of developers using the cosmos-sdk
To enhance this property, we could use a cron job to build and push this image.
The possible downside to this is that we would need to keep our dependencies up to date.
to test this out:
docker pull faddat/archlinux
docker run faddat/archlinux /bin/bash
pacman -Syyu go rocksdb cleveldb git python base-devel
git clone https://github.com/cosmos/cosmos-sdk
build with rocksdb enabled, if you'd like to -- but use grocksdb branch
NB: in places where I'm using the "blank" image, we can change to the one in the repo root post merge
This was getting difficult to bootstrap, so here's the bootstrapper:
https://github.com/faddat/archlinux-docker/runs/6209164234?check_suite_focus=true
Down the line, I figure we can replace base-devel (a development oriented metapackage) with the individual components of it that we use.
https://github.com/faddat/archlinux-docker/pkgs/container/archlinux%2Fcosmos
@alexanderbez @marbar3778 Should I move the docker image build system here?
Result would be like:
https://github.com/faddat/archlinux-docker/actions
The difference between that, and the default image:
https://hub.docker.com/_/archlinux
is that faddat/archlinux (or cosmos/linux or what have you) is
- multiplatform (amd64/arm64 ignoring 32 bit because of the tendermint docs on 32 bit cpus)
 - glibc
 - always up to date (rocks, go, npm, python, leveldb)
 
Another pre-merge detail:
This is a two-stage PR, and this is stage 1.
The second stage:
- makes all docker images depend on one that is made here from scratch every hour (this can run independently of other jobs and will not add wait time)
 - adds documentation to the things surrounding docker & its use and why it is likely not a good idea at all to build anything for musl unless you happen to be running openwrt or another router distrubution
 - uses the docker image to provide a gitpod environment with every dependency (it would run the docker image)
 
please note that this approach:
- creates a single build env for the sdk, tendermint, and if you add rustup to the line 
pacman -Syyu --noconfirm ... rustup-- cw chains as well - is "rolling release": rocks, cleveldb, python, nvm, go and gcc would be updated to their latest upstream releases (per arch build system) once per hour when the container is built
 - is multi-arch: amd64 and arm64
 - runs on cloud, dekstop, and embedded equally well
 - would build the entire multiplatform container here, to be consumed downstream
 - should save a lot of time
 
But it is quite different from what we currently do so I just wanted to try and be clear about how it's different so as not to surprise anyone
This now feels ready to go.
it's missing tags still on the image, so I will have to work on this a little more tomorrow 💤
@marbar3778 please let me know if you'd like me to move the entire image build system here, maybe to a folder like
.dockerimage
so it is out of the way.
This PR eliminates the dependency on faddat/archlinux-docker
There's still too much cruft here. I will clean it up and then bring it out of draft.
@faddat did you have a chance to talk with rick? His idea of layers would make this pr able to be pushed across the finish line
@faddat any chance you want to complete this? otherwise lets close it
Yes, I do want to complete it.
This PR is kinda-sorta blocking #12842
Basically, this one will let us publish an up to date build environment from the main branch. In this case that'd be go 1.19, but I have seen others.
I am amenable to moving this to another repo, though I do basically maintain it at https://github.com/notional-labs/containers
Just want to again note that merging this means that we depend on an external repo-- but for about 1 hour. Once it is merged, we get our own images hosted on ghcr.
Those images stay up to date because we will be using a rolling-release linux, and they're made once an hour.
closing this for the time being. Doing a close pr round to clean up things