Skip to content
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

Merged
merged 6 commits into from
Feb 6, 2025
Merged

auto: Implementation and initial tests #1624

merged 6 commits into from
Feb 6, 2025

Conversation

justinvp
Copy link
Member

@justinvp justinvp commented Feb 6, 2025

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.
@justinvp justinvp requested a review from a team as a code owner February 6, 2025 08:28
@justinvp justinvp added the impact/no-changelog-required This issue doesn't require a CHANGELOG update label Feb 6, 2025
/**
* Base builder for all update options.
*/
public static abstract class Builder<B extends Builder<B>> {
Copy link
Contributor

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.

@justinvp justinvp merged commit 7e0fac7 into main Feb 6, 2025
23 checks passed
@justinvp justinvp deleted the justin/auto branch February 6, 2025 20:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
impact/no-changelog-required This issue doesn't require a CHANGELOG update
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants