Thanks! Looks like a good tool, surprised I haven't heard of it before.
For gitlab CI specifically it's very useful that you distribute a
docker container.
However it doesn't seem to be an open source tool:
github.com/GoogleCloudPlatform/compute-image-tools/cli_tools/daisy
Is a private repository, so building from source doesn't seem to be an
option. Could you please inquire about open sourcing this project?
Maybe it can even be included in the next version of debian!
On Mon, May 14, 2018 at 12:55 PM, Zach Marano <zmarano@google.com> wrote:
>
> I can speak from the GCE perspective more than the Debian perspective here. I would recommend you look at our open source workflow tool called Daisy instead of trying to use gcloud as a CLI for any kind of automation. Daisy is meant for automation and works well within a CI/CD system. You can compile from source, use the release binaries we maintain, or the release container we maintain. There are examples and docs at the links below. But let me know if you have specific questions.
>
> https://googlecloudplatform.github.io/compute-image-tools/daisy.html
> https://github.com/GoogleCloudPlatform/compute-image-tools/tree/master/daisy
>
> -----
> Zach Marano
> zmarano@google.com
>
>
> On Mon, May 14, 2018 at 10:49 AM Paul Dejean <paulcdejean@gmail.com> wrote:
>>
>> So it seems vagrant boxes build just fine on GCE instances that have nested virtualization enabled, via a gitlab shell runner.
>>
>> Proof: https://salsa.debian.org/paulcdejean-guest/vagrant-boxes/-/jobs/16762
>>
>> This means it's possible for us to fully automate the build and deployment process for vagrant boxes. Here's a rough plan:
>>
>> https://docs.google.com/drawings/d/1xDzxKr_AjnjqIBXXqH3b7ecW6EIBTo8TTJ49dxAd67M/edit
>>
>> The stages for building and provisioning the nested virt shell runners could conceivably be run on a shared runner.
>>
>> I do have some questions though. Is it fine to build/provision these GCE runners using the gcloud cli tool? Or does the cloud team have some infrastructure as code tool that they prefer to use instead in order to avoid vendor lockin?