Add Image Support for Go

[tasiah]

Fixes #128.

A couple of things to note:

• The logging is super messy because Expose the engine's logging interface from the Go SDK. pulumi#3801 isn't completed yet. Once the fix for Expose the engine's logging interface from the Go SDK. pulumi#3801 is merged, we should subsequently change all the logging messages there to use that API.
• I did not test images with multiple stages because I'm not familiar with Docker and I couldn't find any existing examples with stages. If there are any simple ways to test this, please let me know!
• The working example is at Add example for Go with Docker examples#594.

[lukehoban]

Looks great! 🎉

[EvanBoyle]

Looks good to me. Most of the comments are more from the perspective of what we could do with the platform to improve the authorship/user experience for building something like this.

Seems like we're doing a lot of string building, manipulation, and some matching/parsing that would be easy to unit test. Not blocking, but something to consider.

[EvanBoyle]

Just a meta-comment on our current requirements for user-defined types: I think that the level of complexity is too high for most users to be successful here even with proper documentation. Is there something we can do here in terms of tooling to improve this authoring experience? Could we do something with templates pulumi new, or potentially provide code generation tools for some of this?

It seems like the user only really needs to synthesize T and TArgs structs, and everything else is boilerplate.

Thoughts @pgavlin ?

[pgavlin]

This does get more complicated with nested types. I'd love to avoid adding yet another code generator, but if we did, we'd probably do something like

//+pulumi
type Foo struct {
}

And then let a code generator chew on that. We might be able to do this by refactoring the schema generator a bit and adding a frontend that works off of parsed code.

At the moment, though, only the structs with input-typed fields should be necessary, and they shouldn't need to implement Input. The result will be a bit clumsy to work with--it will need type assertions--but it does avoid a fair bit of hand-written code.

[EvanBoyle]

Nit: Doc comments start with the name of the type/function/var in question.

Another thing I've noticed is that users sometimes get quite confused about which form of T TArgs TOutput TInput to use in various situations. This comment from Cameron in slack illustrates my point:

Given the type definition EventSelectors TrailEventSelectorArrayInput - how do I construct that? 

I wonder if we can come up with some sort of standard boilerplate comment for each type so that their intended usage is a little easier to understand.

For instance:

// T may be used to specify detailed instructions about how to build a container.
// T is the raw representation of the type.

// TArgs is the pulumified version of T where are members are outputs. Construct TArgs as an input to NewDockerBuild(...)

@lukehoban @pgavlin thoughts?

[EvanBoyle]

For some more detail on the above example:

https://github.com/pulumi/pulumi-aws/blob/c29dcf1b7f3209874af908b4fa94c81991b5adde/sdk/go/aws/cloudtrail/trail.go#L155

If you go searching for that type, it's a little daunting to try and figure out which one to pick if you aren't intimately familiar with our go type system:

https://github.com/pulumi/pulumi-aws/blob/c29dcf1b7f3209874af908b4fa94c81991b5adde/sdk/go/aws/cloudtrail/pulumiTypes.go

[tasiah]

Another thing I've noticed is that users sometimes get quite confused about which form of T TArgs TOutput TInput to use in various situations.

+1 Because I was/am one of those users.

[pgavlin]

Coming up with a standard comment here would be fantastic, yes.

[lukehoban]

🎉