build everything using dgr, rkt, and bash only #217
Comments
|
That's what we are doing at blablacar, every project has an You can prepare your host as you want to work on the project, or just build the aci using the To build dgr, the container will require at least 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. |
|
The builder currently relies on parts of its 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: |
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.)
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.)
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.)
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.)
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.)
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.)
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.) Sorts the contents to have a reproducible order, but pulls the manifest file to the front for fast access. Sorted contents of ACIs allow for easier comparison, and usage of tools such as zsync, and deduplication on the server. The price, sorting by 'tar', is cheap. zap the "chdir-acrobatique", use `tar -C`: dgr changes paths and performs needless renames, which result in mayhem if the process quits prematurely or the timing were off. The solution is to use tar's `-C` param and transform the filenames. closes blablacar#210
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.) Sorts the contents to have a reproducible order, but pulls the manifest file to the front for fast access. Sorted contents of ACIs allow for easier comparison, and usage of tools such as zsync, and deduplication on the server. The price, sorting by 'tar', is cheap. zap the "chdir-acrobatique", use `tar -C`: dgr changes paths and performs needless renames, which result in mayhem if the process quits prematurely or the timing were off. The solution is to use tar's `-C` param and transform the filenames. closes blablacar#210
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.) Sorts the contents to have a reproducible order, but pulls the manifest file to the front for fast access. Sorted contents of ACIs allow for easier comparison, and usage of tools such as zsync, and deduplication on the server. The price, sorting by 'tar', is cheap. zap the "chdir-acrobatique", use `tar -C`: dgr changes paths and performs needless renames, which result in mayhem if the process quits prematurely or the timing were off. The solution is to use tar's `-C` param and transform the filenames. closes blablacar#210
Enables dgr to work on hosts that don't have any tar. (See also blablacar#217.) Sorts the contents to have a reproducible order, but pulls the manifest file to the front for fast access. Sorted contents of ACIs allow for easier comparison, and usage of tools such as zsync, and deduplication on the server. The price, sorting by 'tar', is cheap. zap the "chdir-acrobatique", use `tar -C`: dgr changes paths and performs needless renames, which result in mayhem if the process quits prematurely or the timing were off. The solution is to use tar's `-C` param and transform the filenames. closes blablacar#210
Enables dgr to work on hosts that don't have any tar. (See also #217.) Sorts the contents to have a reproducible order, but pulls the manifest file to the front for fast access. Sorted contents of ACIs allow for easier comparison, and usage of tools such as zsync, and deduplication on the server. The price, sorting by 'tar', is cheap. zap the "chdir-acrobatique", use `tar -C`: dgr changes paths and performs needless renames, which result in mayhem if the process quits prematurely or the timing were off. The solution is to use tar's `-C` param and transform the filenames. closes #210
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 dgrIs what I'd expect to generate:
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).Or, are there any other preferences regarding what goes inside the aci-builder and aci-tester as distribution?
The text was updated successfully, but these errors were encountered: