build everything using dgr, rkt, and bash only

[mark-kubacki]

I am interested in this too, and the idea has been presented scattered throughout some issues and commit comments. I'd like to move this forward and collect concrete ideas and plans.

For example, this:

git clone --depth=1 https://…/dgr
cd dgr
dgr

Is what I'd expect to generate:

• all the required aci files (and optionally install them)
• a new dgr binary
• … in a directory, say dist/.

Obviously we will need a catalyst container (shared builder) which will come with Go.

I'd propose using Ubuntu in all these images and avoid any compiling if possible: For example, currently the aci-builder container is about 54 MiB – I can strip down Ubuntu for our purposes to less than that (see: rkt image fetch blitznote.com/ubuntu:16.04).

• The catalyst will then build on that and come with go, glide, and what's needed to build dgr.
• In addition to that the catalyst will come with multistrap to enable us to create customized images, such as the aci-builder.
• The aci-builder is then plain Ubuntu, but without its package manager, perl, and everything else not necessary to neither run dgr nor tar nor gpgv2. (At estimated ≤32 MiB.)

Or, are there any other preferences regarding what goes inside the aci-builder and aci-tester as distribution?

[n0rad]

That's what we are doing at blablacar, every project has an aci directory in it.

You can prepare your host as you want to work on the project, or just build the aci using the aci directory. There is an aci directory in dgr project, but it's not working yet.

To build dgr, the container will require at least go, git, upx and gcc to prepare the builder. any distro can do the job but we will require a repository to store those aci. I planned to use my aci repository at https://aci.awired.net/ that I'm already using for my own server. I was thinking about pushing them to github, but it will just kill the quota and is not really a good solution for that.

About the builder, we need to be strictly retro-compatible with what we have today since there is a lot of project that rely on this builder. I'm not for changing it by ubuntu as the default builder (it can still be overriden by any project), until we are 100% sure about retro-compatiblity.

There is also a trust problem around what is building dgr & what is inside dgr, using buildroot for the stage1 is ok, as soon as we can rebuild from scratch the builder (I'm working on it right now). The problem still exist for the distro that will build dgr, and the distro in the builder If we change, which needs concrete benefits and 100% compatibility first.

[mark-kubacki]

The builder currently relies on parts of its rootfs being moved to rootfs/dgr. You might find option builder.transform []string as introduced by this commit handy for that: https://github.com/blablacar/dgr/pull/225/commits/74be5580f2d6007cd4593e6007dddec62c893a06

I am currently toying with an aci-builder based on a fork of Ubuntu and it's working well. I could've gone with Gentoo, but I don't like the idea of compiling everything from scratch, because that's redundant, duplicate maintaining instead of using work already done, and it's slow. On the other hand, Debian/Ubuntu and friends are available even for different flavours of ARM and setting it up is just a matter of downloading about 25 MiB in packages.

Same goes for what I call catalyst, and what you are referring to in your third paragraph:
We can run /usr/lib/rkt/stage1-images/stage1-coreos.aci, as that is always shipped with rkt, and just extract Go/latest as well as upx to compile dgr. No gcc or any additional or special *.aci necessary.

0: in stage1-coreos.aci
  - curl golang | tar -x…
  - curl upx/latest
  - build templater
1: any
  - add templater
  - setup Debian or Ubuntu → aci-builder
2: any
  - curl bats → aci-tester
3: in stage1-coreos.aci or aci-builder
  - mount cache with aci-builder and aci-tester
  - curl golang | tar -x…
  - curl upx/latest
  - build dgr
…