On Fri, Aug 10, 2018 at 06:44:50PM -0400, Jimmy Kaplowitz wrote:
> On Thu, Aug 09, 2018 at 04:11:19PM +0200, Bastian Blank wrote:
> > On casulana it only can run qemu directly. On GCE it would just start a
> > VM on the platform.
> I notice that a lot of your instructions refer to Docker, though. Are
> you talking about running Docker inside transient VMs or using it
> instead of transient VMs?
I would not say it uses transient VM if it weren't. So it runs Docker
as runtime environment within transient VM.
> My hope is that nobody would need to know or use GitLab (except that
> they would git clone our code from Salsa), nor have any write access to
> Debian infrastructure whatsoever, in order to reproduce our builds.
I don't know where this idea comes from. While this stack uses Gitlab
services and runs on salsa.d.o, you can always use the inner layers
> Independent verifiability is good, and requiring installation of gitlab
> or knowledge of gitlab-runner seems like unnecessary complexity.
> But any Debian user with a laptop and a way to run VMs should be able to
> reproduce our builds without installing GitLab or seeking an account
> from anyone.
> > - Use "make $job" to run it by hand from the working copy. We need to
> > rename stuff a bit for that.
Where does it say Gitlab in this? It is just "make".
The whole thing is setup in layers. You can remove several until you
are at the basic build stuff. You don't need to use all of them, it's
Right now this layers are:
- gitlab: repository store, job scheduler
- gitlab-runner: job executor
- docker-machine: VM handling with docker and directly supported by
- docker: runtime environment within transient VM
- gitlab ci script: just a script
- fai class wrapper
I hope that clears up some assumptions.
If some day we are defeated, well, war has its fortunes, good and bad.
-- Commander Kor, "Errand of Mercy", stardate 3201.7