gno
gno copied to clipboard
gnolang
gitpod image
The development environment image now supports all of the databases that gno does.
We can also...
OK, so, it's still opaque, because in both cases, the original dockerfile, and the modified one seen here, we still have mystery meat:
In the first one the mystery meat is golang:1.18.1 & debian-slim -- we trust those
But if we add this:
https://github.com/gnolang/gno/pull/178
Then the entire docker image build chain becomes fully transparent except for the compilation of the OS (and I do think that we can solve that part too, later, over time)
If we merge #178 then, we get a mystery-meat-free clearly defined build and runtime environment that builds here and at that point, there's no remaining opacity other than the upstream build process for:
- linux kernel
- os packages
- golang
and all of that can in fact be compiled in github actions, too.
Finally, to break the github chains, a second implementation of the builder can be kept self-hosted, to ensure that github is also not a dependency
In the first one the mystery meat is golang:1.18.1 & debian-slim -- we trust those
Yes, we trust those, because they are standards used and reviewed by millions for more than 10 years.
They are known to be rigorous in terms of updates.
And the images are versioned.
Notional’s docker image is made by a bunch of people, no massive review, no versioning, no proof of release consistency, and the need to audit by ourselve what is changed.
I’ve open a PR here -> https://github.com/gnolang/gno/pull/212
In this PR, I add `gofumpt and go pls, which looks like to be the two additions from your PR (I didn’t added golangci-lint yet, because the repo is not configured to support it yet).
This implementation is simple, pure go, and a way more transparent:
- your solution -> docker is not versioned, and
go install …@latestis not versioned - this solution ->
go.modenforced versions of our dev deps, simple
@moul shall we move these thoughts to an issue and close this draft? Thanks!
