https://pulumi.com logo
Join Slack
Powered by
This message was deleted.
# pulumi-deployments
s
This message was deleted.
l
Today we only support 
git
as a source mechanism. We'd like to support more and expect that in the fullness of time we will also support: • Specifying a YAML program directly in the inline payload • Specifying a pre-signed blob URL, for instance S3 • Maybe others we haven't thought of yet. We don't currently have any plans to try and support inline automation api programs via deployments (it isn't clear that this is possible). Do any of the options above seem interesting? If so would you mind opening an issue at github.com/pulumi/service-requests We're definitely interested in adding this capability if we have users who are ready to consume it! It is true that today we only support the
Another option, which is a bit clunky, is to clone effectively an empty repo and then use pre-run commands to 
cat
the program and the stack yaml into the directory. Here is an example of doing that with a yaml program: https://github.com/pulumi/deploy-demos/blob/main/deployment-drivers/nodejs/typescript-driver/index.ts#L140-L176
f
@lemon-agent-27707 thanks! I was thinking this would work like an “API” behind the scenes, and that we could send the parameters in a JSON object so pulumi could process it. Do you recommend a way to accomplish something similar with existing Pulumi’s features? We were also thinking about putting our pulumi auto api code in a lambda function so we can send that JSON to it and deploy our resources. (Do you see any potential issues with this approach?)
r
We were also thinking about putting our pulumi auto api code in a lambda function so we can send that JSON to it and deploy our resources. (Do you see any potential issues with this approach?)
The thing to keep in mind here is that the Pulumi CLI needs to be present for automation api, so you'll need to use a custom image as the base of your lambda. Otherwise I don't foresee any issues.
l
@fresh-minister-66960 You could use the deployments REST API directly. Here is an example of running a refresh in a lambda: https://github.com/pulumi/deploy-demos/blob/main/pulumi-programs/drift-detection/index.ts#L24-L75 Here's a simpler example that runs an update: https://github.com/pulumi/deploy-demos/blob/main/deployment-drivers/nodejs/typescript-driver/index.ts#L116-L135
Do you see any potential issues with this approach?
The primary issue with wrapping normal Automation API in a lambda vs using Pulumi Deployments (whether the REST API or Remote workspaces) is that many pulumi programs take multiple minutes to run. Longer than is reasonable for a synchronous HTTP request. That is part of the benefit of deployments. You could create a lambda that does the following: 1. Receives an HTTP request to deploy some resources 2. Translate that into a call to the Deployments API 3. The deployments API will immediately return a URL to track the deployment to completion (app.pulumi.com/{org}/{project}/{stack}/deployments/{deploymentNumber} 4. You can return that URL immediately to users to they can monitor progress of the deployment to completion.
25 Views
Open in Slack
PreviousNext
Powered by