Does anyone (I assume at Pulumi) have a nice build...
# contribute
s
Does anyone (I assume at Pulumi) have a nice build container image or similar? Keeping the versions in sync with y’all is hard (work is using $latest of everything)
So I keep getting spurious diffs from e.g. dep v0.5 vs 0.4.1
m
@creamy-potato-29402 I seem to remember that you were looking for something like this as well. Am I right? Did you ever get anywhere?
c
I have been slowly containerizing anything that causes me platform-dependent pain
but so far I have only containerized the protobuf stuff.
Other people have tried to write containers for pulumi/pulumi and pulumi/pulumi-kubernetes, but nothing has been checked in.
b
Didn't @bitter-oil-46081 do this as part of his CI container work? Ideally we would layer any CI-specific specializations on top of a base simple Pulumi CLI base image.
c
Uh, I’m not sure he did? Could be wrong.
ping @bitter-oil-46081
b
I think that @stocky-spoon-28903 is asking if we have a container definition for our build environment (e.g what we execute in on Travis). The answer for that is that we do not, since we do not use docker in Travis. We do have https://github.com/pulumi/scripts/blob/master/ci/install-common-toolchain.sh which is the shell script we run on Travis. You could probably use that as the seed for a developer environment, but we have not done that. The thing Joe is referring to, I think, was the example we did for CodeShip Pro where they force builds to happen in docker containers. All that work was was putting Pulumi in a container (see: https://github.com/pulumi/codeship-example/blob/master/Dockerfile). But this did not try to define an environment which could be used to build Pulumi itself.
s
👍 that is what I was asking
b
Ah I had assumed they would be the same thing: 1) a base container that builds Pulumi and 2) a derived container that uses the result of that built Pulumi. I can see why they could be different things. I will point out that they don't necessarily need to be, however, and that to simplify our lives it may be worth thinking of them as the same thing. The only overhead I can see is that the Go toolchain is needed in one but not the other.