This message was deleted.

It is not, and pretty deeply tied to our Pulumi Service. But I’m happy to share the details with you, but until we offer general webhook support I don’t think you’d be able to create something similar. (As you wouldn’t get the notification when the stack was updated and/or its update results.)

Right, my backup plan was to write a thing that accepts the GitHub webhooks, runs Pulumi in codebuild and then parses the logs of that to post back, effectively giving the Terraform Enterprise workflow for Pulumi.

Re: Supporting CodeBuild in addition to Travis, there is no roadmap item. But depending on what you mean by that, it would be ~5m if work.

Basically I want the entire workflow of the GitHub app exactly as it is, but for the compute that uses Travis to use CodeBuild (or even a Fargate job) instead

The GitHub app associates preview and updates with GitHub IFF the job was ran as part of CI. (That’s how we don’t post previews ran on a dev box to PRs and things by mistake.) The way we support Travis is really just a matter of checking if some env vars are present, and then adding some additional metadata to the update. So we can tag Pulumi updates that are ran on CodeBuild in the same way. I’ll set a reminder to do that today, once my two little boys are in bed.

Ahhhhh I see. That would be great. If there are just a bunch of envvars to set I guess it wouldn’t be too hard to just replicate them in CodeBuild?

It’s more the other way around. Checking for the CodeBuild env vars, and then sending the data to Pulumi. I’m on mobile and cant find the code, but look in the Pulumi:Pulumi repo for the string ‘“TRAVIS”’. That should be the place where we read that env var and set some data in the update metadata.

Thanks

No problem, thanks for mentioning it!

@square-apartment-28429 This part? https://github.com/pulumi/pulumi/blob/master/cmd/util.go#L437

Yes, exactly. If we just add a similar set of checks to populate those metadata properties for CodeBuild-based builds, everything should “just work”(TM).

Heh of course they can’t make it easy by mirroring the Travis options…

That bit is actually really important, at least on Travis. As the GitHub PR is at commit X in branch Y. But the CI build runs on some merge commit that GitHub doesn’t provide IIRC. I don’t know if CodeBuild does that (build on a merge commit), but if so I’d be surprised they didn’t make the source commit of the PR easy to obtain. :(

Right - it’s a problem. I’ll figure out what others are doing I guess.

We do link in a Go library that allows us to read the current .git folder, etc. so we might be able to just use the Git APIs available to get that data. (We use that library elsewhere in that same source file until.go IIRC.)

It looks like it’s possible to get everything needed looking at my test project. I’ll write up what I’ve found as part of the pull request to make it easier to review