-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
auto: Implementation and initial tests #1624
Conversation
This change adds `LocalWorkspace`, `WorkspaceStack`, and `LocalPulumiCommand`, and supporting types, which provides the bulk of the implementation. An initial set of tests is included, but more need to be added. Beyond adding more tests, there are a few known issues that are in-progress (I'm going to open issues for these): - Bug: `NoSummaryEventException` is thrown when running previews on local programs - Bug: `getProjectSettings`/`saveProjectSettings` for YAML only has a bare minimum implementation. It is currently broken for all but the most simple of projects. WIP. - Bug: `getStackSettings`/`saveStackSettings` (de)serialization needs to be fixed. - Bug: Graceful error handling/propagation for inline programs - Engineering: Flesh out the test suite to cover all operations There's also some follow-up fixes / enhancements that we want to consider: - More tests - Bug: Properly pass through `logger` for inline programs (right now, it's not hooked up) - Enhancement: Add support for downloading/installing the CLI via APIs on `LocalPulumiCommand` - Enhancement: Add support for `importResources` (API for `pulumi import`) - Enhancement: Add `RemoteWorkspace` support for running operations using deployments - Enhancement: Avoid serializing inline program invocations. It ended up being simple enough to introduce some locking around this for inline programs, which does allow multiple inline programs to work in the same process. It's just going to serialize them, which could impact folks doing things in parallel. When we have the real fix that avoids the global state, we can remove the lock. I'm sure there are some lingering issues still, so I'll continue to raise PRs with more tests and any bug fixes for issues I find.
/** | ||
* Base builder for all update options. | ||
*/ | ||
public static abstract class Builder<B extends Builder<B>> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We don't have to do this pre-go-live but I think we should discuss not doing this when this out the door. I don't think the amount of code saved by inheriting e.g. DestroyOptions
from UpdateOptions
and the clever Builder
inheritance tricks is super worth it. I appreciate that we already do this in e.g. ResourceOptions
, though it's a bit messy there and has made certain kinds of changes fiddly in the past.
This change adds
LocalWorkspace
,WorkspaceStack
, andLocalPulumiCommand
, and supporting types, which provides the bulk of the implementation. Apologies for the large PR. An initial set of tests is included, but more need to be added.Beyond adding more tests, there are some known issues that I'm currently working on to be done as separate PRs:
Bug:Fixed!NoSummaryEventException
is thrown when running previews on local programsgetProjectSettings
/saveProjectSettings
YAML (de)serialization #1628getStackSettings
/saveStackSettings
YAML (de)serialization #1630com.pulumi.experimental.automation
tocom.pulumi.automation
#1633There's also some follow-up fixes / enhancements that we want to consider, subsequently:
getProjectSettings
/saveProjectSettings
JSON (de)serialization #1629getStackSettings
/saveStackSettings
JSON (de)serialization #1631logger
for inline programs #1636EngineEvent
object model and callback design (visitor pattern?) #1635importResources
(API forpulumi import
) #1638RemoteWorkspace
support #1639Part of #1607