Commit Graph

130 Commits

Author SHA1 Message Date
Brandon Pollack 90c16ec186
plugin versions code reuse ()
Get latest version if one not specified in pulumi manifest
Refactor code from

https://github.com/pulumi/pulumi/pull/16981 to share code.

Related to https://github.com/pulumi/pulumi/issues/16920

Original version: 
2024-09-24 13:36:45 +00:00
Fraser Waters a6587ef98e
Fix gatherPluginsFromSnapshot incorrectly spec'ing parameterized providers ()
Also deleted `RunInstallPlugins` because nothing was using it.

Without this fix we would report a parameterized plugin in state back as
the parameterized package name, e.g. "random" instead of the base plugin
"terraform-provider".
2024-09-10 10:22:53 +00:00
Thomas Gummerer 531146678e
debugging: more consistency for naming ()
We're a bit inconsistent with naming for debugging, calling it enable
debugging in some places, attach debugger in others, and start debugger
yet in others.

Unify this, so we call everything that goes from the engine towards the
language host attach debugger, while the message we get back from the
language host is called start debugging since we're telling the engine
that we want to be starting the debugging session.

Thanks @julienp for the suggestion!
2024-09-04 10:36:45 +00:00
Will Jones 6ff74d2c6f
Use events to report downloads as system messages ()
When running a Pulumi operation such as a preview or an update, Pulumi
will detect if plugins (e.g. an AWS provider) are missing and download
and install them appropriately. Presently the user experience when this
happens isn't great (see e.g.
https://github.com/pulumi/pulumi/issues/14250), making it hard for the
user to see what is happening/what is taking so long when required
plugins are large.

This commit attempts to rectify this by continuing the work in
https://github.com/pulumi/pulumi/pull/16094 that tracks download
progress using engine events. In doing so, we are able to render
multiple downloads as part of the existing "system messages" panel in
the Pulumi output, and provide a clean view of what is going on when
downloads must occur before program execution. Moreover, we generalise
that PR to handle any engine process, enabling us to play a similar
trick with plugin installations (which can also take a while).

To preserve existing behaviour, we introduce a new class for these
events which we call "ephemeral", meaning that they are not persisted or
rendered in contexts such as diffs, for instance. Specifically,
ephemeral events are *not* sent to HTTP backends (i.e. the service), so
this commit should not require any changes to the service before merging
and releasing.

Fixes 
Closes 
Closes  



https://github.com/user-attachments/assets/f0fac5e9-b3c8-4ea7-9cb7-075fc4b625d9


https://github.com/user-attachments/assets/7a761aa9-10ad-4f66-afa3-e4550b4553a5
2024-09-03 12:12:04 +00:00
Thomas Gummerer d51c0bdd87
implement the engine bits for debugging support ()
We want to introduce dubugging support for Pulumi programs. This PR
implements the engine changes necessary for that. Namely, we pass the
information whether we expect a debugger to be started to the language
runtime, and introduce a way for the language runtime plugins to report
to the engine that we're waiting for a debugger to attach. The language
runtime is expected to include the information relevant for the user to
be able to attach to the debugger, as well as a shortened message.

The idea is that the configuration can be picked up by an IDE, and the
debugger can attach automatically. Meanwhile the short message should
contain enough information to be able to attach a debugger manually,
while being short enough to be displayed to the user in the CLI output.
(this will commonly be either the port of the debugger, or the PID of
the process being debugged).

The implementation of the CLI flags and each of the language runtimes
will follow in subsequent PRs.

I tried adding a test to this, but I'm not sure it's possible with our
current testing infrastructure. To do this properly, we'd need to make a
RPC call to the engine, but we don't have that available in the
lifecycletests (? please let me know if I'm missing something). Once
more of the feature is implemented we might be able to implement an
integration test for it. (Not straightforward either, as we'll have to
tell the debugger to continue, but that should be more doable).

Another thing that's not clear to me is that @EronWright mentions this
could be used for MLC/provider debugging as well. However I'm not seeing
how that's going to work, as MLCs/providers are being run as a binary
plugin, which we don't compile from pulumi/pulumi, and thus wouldn't
necessarily even know which debugger to launch it under without a bunch
of additional configuration, that might be better in a shim around the
program (or just keeping the debugging the way we're currently doing,
launching the program and then letting the engine attach to it).

---------

Co-authored-by: Eron Wright <eron@pulumi.com>
Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
Julien eefd0ce92f
Use int32 in Go interfaces that map to protobufs using int32 ()
We use plain `int`, which can be 32 or 64 bit based on the system, in
some of the Go interfaces that map to protobuf using int32. Update the
Go interfaces to use int32 to prevent potential integer overflow.

These potential integer conversion overflows are flagged by the latest
golangci-lint. Once this PR is merged, we can upgrade our version of
golangci-lint, which will unblock us from using Go 1.23 in CI.

This will require some small updates in providers, mostly removing casts
`int32(...)`.
2024-08-28 13:45:17 +00:00
Luke Hoban f1e4b4ff94
Change `pulumi refresh` to report diff relative to desired state instead of relative to only output changes ()
Presently, the behaviour of diffing during refresh steps is incomplete,
returning only an "output diff" that presents the changes in outputs.
This commit changes refresh steps so that:

* they compute a diff similar to the one that would be computed if a
`preview` were run immediately after the refresh, which is more
typically what users expect and want; and
* `IgnoreChanges` resource options are respected when performing the new
desired-state diffs, so that property additions or changes reported by a
refresh can be ignored.

In particular, `IgnoreChanges` can now be used to acknowledge that part
or all of a resource may change in the provider, but the user is OK with
this and doesn't want to be notified about it during a refresh.
Importantly, this means that the diff won't be reported, but also that
the changes won't be applied to state.

The implementation covers the following:

* A diff is computed using the inputs from the program and then
inverting the result, since in the case of a refresh the diff is being
driven by the provider side and not the program. This doesn't change
what is stored back into the state, but it does produce a diff that is
more aligned with the "true changes to the desired state".
* `IgnoreChanges` resource options are now stored in state, so that this
information can be used in refresh operations that do not have access
to/run the program.
* In the context of a refresh operation, `IgnoreChanges` applies to
*both* input and output properties. This differs from the behaviour of a
normal update operation, where `IgnoreChanges` only considers input
properties.
* The special `"*"` value for `IgnoreChanges` can be used to ignore all
properties. It _also_ ignores the case where the resource cannot be
found in the provider, and instead keeps the resource intact in state
with its existing input and output properties.

Because the program is not run for refresh operations, `IgnoreChanges`
options must be applied separately before a refresh takes place. This
can be accomplished using e.g. a `pulumi up` that applies the options
prior to a refresh. We should investigate perhaps providing a `pulumi
state set ...`-like CLI to make these sorts of changes directly to a
state.

For use cases relying on the legacy refresh diff provider, the
`PULUMI_USE_LEGACY_REFRESH_DIFF` environment variable can be set, which
will disable desired-state diff computation. We only need to perform
checks in `RefreshStep.{ResultOp,Apply}`, since downstream code will
work correctly based on the presence or absence of a `DetailedDiff` in
the step.

### Notes

- https://github.com/pulumi/pulumi/issues/16144 affects some of these
cases - though its technically orthogonal
- https://github.com/pulumi/pulumi/issues/11279 is another technically
orthogonal issue that many providers (at least TFBridge ones) - do not
report back changes to input properties on Read when the input property
(or property path) was missing on the inputs. This is again technically
orthogonal - but leads to cases that appear "wrong" in terms of what is
stored back into the state still - though the same as before this
change.
- Azure Native doesn't seem to handle `ignoreChanges` passed to Diff, so
the ability to ignore changes on refresh doesn't currently work for
Azure Native.

### Fixes

* Fixes 
* Fixes 
* Fixes  
* Not quite , but likely replaces the need for that

Co-authored-by: Will Jones <will@sacharissa.co.uk>
2024-06-12 16:17:05 +00:00
Will Jones f71c764a4c
Clean up deployment options ()
# Description

There are a number of parts of the deployment process that require
context about and configuration for the operation being executed. For
instance:

* Source evaluation -- evaluating programs in order to emit resource
registrations
* Step generation -- processing resource registrations in order to
generate steps (create this, update that, delete the other, etc.)
* Step execution -- executing steps in order to action a deployment.

Presently, these pieces all take some form of `Options` struct or pass
explicit arguments. This is problematic for a couple of reasons:

* It could be possible for different parts of the codebase to end up
operating in different contexts/with different configurations, whether
due to different values being passed explicitly or due to missed
copying/instantiation.
* Some parts need less context/configuration than others, but still
accept full `Options`, making it hard to discern what information is
actually necessary in any given part of the process.

This commit attempts to clean things up by moving deployment options
directly into the `Deployment` itself. Since step generation and
execution already refer to a `Deployment`, they get a consistent view of
the options for free. For source evaluation, we introduce an
`EvalSourceOptions` struct for configuring just the options necessary
there. At the top level, the engine configures a single set of options
to flow through the deployment steps later on.

As part of this work, a few other things have been changed:

* Preview/dry-run parameters have been incorporated into options. This
lets up lop off another argument and mitigate a bit of "boolean
blindness". We don't appear to flip this flag within a deployment
process (indeed, all options seem to be immutable) and so having it as a
separate flag doesn't seem to buy us anything.
* Several methods representing parts of the deployment process have lost
arguments in favour of state that is already being carried on (or can be
carried on) their receiver. For instance, `deployment.run` no longer
takes actions or preview configuration. While doing so means that a
`deployment` could be run multiple times with different actions/preview
arguments, we don't currently exploit this fact anywhere, so moving this
state to the point of construction both simplifies things considerably
and reduces the possibility for error (e.g. passing different values of
`preview` when instantiating a `deployment` and subsequently calling
`run`).
* Event handlers have been split out of the options object and attached
to `Deployment` separately. This means we can talk about options at a
higher level without having to `nil` out/worry about this field and
mutate it correctly later on.
* Options are no longer mutated during deployment. Presently there
appears to be only one case of this -- when handling `ContinueOnError`
in the presence of `IgnoreChanges` (e.g. when performing a refresh).
This case has been refactored so that the mutation is no longer
necessary.

# Notes

* This change is in preparation for , where we'd like to add an
environment variable to control behaviour and having a single unified
`Options` struct would make it easier to pass this configuration down
with introducing (more) global state into deployments. Indeed, this
change should make it easier to factor global state into `Options` so
that it can be controlled and tested more easily/is less susceptible to
bugs, race conditions, etc.
* I've tweaked/extended some comments while I'm here and have learned
things the hard way (e.g. `Refresh` vs `isRefresh`). Feedback welcome on
this if we'd rather not conflate.
* This change does mean that if in future we wanted e.g. to be able to
run a `Deployment` in multiple different ways with multiple sets of
actions, we'd have to refactor. Pushing state to the point of object
construction reduces the flexibility of the code. However, since we are
not presently using that flexibility (nor is there an obvious [to my
mind] use case in the near future), this seems like a good trade-off to
guard against bugs/make it simpler to move that state around.
* I've left some other review comments in the code around
questions/changes that might be a bad idea; happy to receive feedback on
it all though!
2024-06-11 13:37:57 +00:00
Paul C. Roberts 95f06deccd
Revert "The `--expect-no-changes` flag checks for output diffs" ()
Reverts pulumi/pulumi#15903

This is implicated in Issue  so reverting to allow time to provide
a proper solution

Fixes 
2024-05-06 17:34:24 +00:00
Paul C. Roberts b72399bd28
The `--expect-no-changes` flag checks for output diffs ()
<!--- 
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->

# Description

<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
This adds a pseudo op `OpOutputChange` to the set of changes that are
recorded in `display.ResourceChanges` to count the number of output
changes, this is then included in the check used to evaluate the
`--expect-no-changes` flag

When resource outputs are registered, they are checked against their
previous value using existing functionality, the total count of changes
is then added

The internal capability is validated with an engine test, the cli is
validated using an integration test

This will break user workflows that depend on the previous behavior

Fixes 

## Checklist

- [X] I have run `make tidy` to update any new dependencies
- [X] I have run `make lint` to verify my code passes the lint check
  - [ ] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [X] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [X] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->

---------

Co-authored-by: Paul Roberts <proberts@pulumi.com>
2024-05-01 18:30:49 +00:00
Thomas Gummerer 8099d314a7
destroy: implement --continue-on-error ()
Implement a `--continue-on-error` flag for `pulumi destroy`. This makes
sure we continue processing destroys even if errors occur. We will only
continue for resources which do not depend on the failed resource, to
make sure we always have a valid snapshot available, and to not leave
any orphaned resources behind.

Resources that fail to destroy will still continue to be managed by
pulumi, and the process ends in an error to indicate to the user that
there were problems and the destroy didn't succeed cleanly.

The output will continue to be the same as for failed destroys, except
we now may succeed in destroying more resources than before.

/cc https://github.com/pulumi/pulumi/issues/3304
2024-03-22 09:22:40 +00:00
Zaid Ajaj bd4e50efdd
[conformance tests] Fix run root and use program info everywhere ()
# Description

This PR introduces `ProgramInfo` to replace the old `ProgInfo` and
consistently use it where we require plugin, install dependencies and
initialize language runtimes.

## Checklist

- [ ] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [ ] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-01-25 23:28:58 +00:00
Fraser Waters 941f3d0902
Clean up project usage ()
<!--- 
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->

# Description

<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->


The project field on `GetProgramDependenciesRequest` and
`GetRequiredPluginsRequest` was marked deprecated at the start of
December. None of the language runtimes are using this, so this cleans
up the engine side code so we don't need to thread a
`*workspace.Project` down to the plugin layer to fill in these fields
anymore.

I haven't fully removed them from the Protobuf structs yet, we probably
could but just to give a little more time for people to get a clear
usage error if still using it.

## Checklist

- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [x] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2024-01-16 17:06:14 +00:00
Fraser Waters 54c956af6d
Send all events to the engine event stream ()
<!--- 
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->

# Description

<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->

Currently the engine skips sending some resource events to the event
stream. Currently that's any "RemovePendingDelete" steps and anything to
do with default providers.

This was added so that we wouldn't display "internal implemntation
details" like default providers to the user in the tree or diff views.

However we wanted to use the engine event stream to support generating
an import file from preview deployments (make an import for every
resource that needs to be created). This mostly works except for the
imports we also need to know some of the provider details, and while the
event stream will tell us about explicit providers the skipping of
default providers means we can't get their information in the import
generater code.

So this moves this filtering out of the engine and to the display logic
instead. We still leave it up to the engine to mark what events it
considers "internal" but they're always sent to the event stream.

## Checklist

- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [ ] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works - This shouldn't change anything user visible so should be
covered by existing tests
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change - No user visible
change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-20 21:55:59 +00:00
Thomas Gummerer 13371f9865
Start policy packs in parallel ()
Currently we start up and thus compile policy packs one by one. When
multiple policy packs need to be loaded, this increases the start up
time substantially. In previous tests plugins took ~1-3s to start up, so
having multiple of these the time adds up quickly.

Loading them in parallel will help reduce the startup time here.

Fixes 

## Checklist

- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [x] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-20 14:08:32 +00:00
Fraser Waters 6f21cac6f3
Make `engine.NewEvent` type safe ()
<!--- 
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->

# Description

<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->
Small refactor I noticed while writing a test with engine events. We
always had to call `NewEvent` with the tag and payload value for an
event and these _had_ to match up else the engine panics. But we can
just pass the payload and type switch to work out the tag. Means one
less parameter to pass to `NewEvent` and pretty much no chance of it
going wrong. To ensure there's really no chance I've added a generic
union type so you can only pass payload types to this method now.

Cancel had to be handled separately because it doesn't have a payload
type, it's just nil.
2023-11-16 16:54:03 +00:00
Thomas Gummerer 529ea588ea
add output for running policy packs ()
# Description

🚧 

This is a work in progress attempting to add some output for when policy
packs are being loaded/compiled (which I realized was the actual reason
for the slowdown, not that they were being run already). There's still
some pretty obvious code quality issues as I've been throwing this
together, and the URN's are not constructed properly yet either, so some
of the output is less helpful than it could be. I'm mainly opening this
to get some early feedback on whether this is the appropriate place to
add the output, or if there are better alternatives.

Also including a gif here of what this looks like. In particular the
Name here needs to be improved, and the "Plan" might want to say
"loading/compiling" or something similar instead?


![policy-pack](https://github.com/pulumi/pulumi/assets/191004/85cca146-d740-4e4c-96dc-cc26dca6bb90)

Fixes 

## Checklist

- [ ] I have run `make tidy` to update any new dependencies
- [ ] I have run `make lint` to verify my code passes the lint check
  - [ ] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [ ] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [ ] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-11-15 11:19:31 +00:00
Fraser Waters 10c1e1baaa
Cleanup result.Result in pkg/engine ()
A big change for result.Result cleanup. This removes all references to
the Result type from pkg/engine. This was mostly just search replace.
Points to note, we still map to `result.Result` in pkg/backend (that
will be the next big result change to deal with), and a little bit of
fiddlyness with multiple error values in test_plan.go `runWithContext`.
2023-10-11 14:44:09 +00:00
Joe Duffy 96a9a77167
Policy remediations feature ()
This PR implements the new policy transforms feature, which allows
policy packs to not only issue warnings and errors in response to policy
violations, but actually fix them by rewriting resource property state.
This can be used, for instance, to auto-tag resources, remove Internet
access on the fly, or apply encryption to storage, among other use
cases.
2023-10-09 18:31:17 +00:00
Fraser Waters 79c008ffef
Cleanup result.Result in Deployment () 2023-10-09 14:48:10 +00:00
Eron Wright fb28ab7592
ctrl-c should cause Pulumi to call Cancel operation on providers ()
<!--- 
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->

# Description
Fixes 

This PR fixes a problem that the engine cannot forward a cancellation
signal to the provider, because the plugin context is already closed. An
[earlier
commit](a9ae602867)
made the plugin context be closed too eagerly, with the intent of
cancelling plugin installation. This PR attempts to decouple the
cancellation of plugin installation from the lifecycle of the plugin
context, so that plugin installation may be cancelled during the
cancelation phase as opposed to the termination phase. Then, it closes
the plugin context in termination phase.

There's an existing test case in the engine lifecycle tests called
`TestProviderCancellation`, but it didn't catch the problem because it
uses a fake plugin host that behaves differently after being closed. The
issue was fixed in https://github.com/pulumi/pulumi/pull/14063 and the
test was temporarily disabled. This PR re-enables the test case.

A new test case `TestSourceFuncCancellation` is added to test
cancellation of the source func (where plugin installation happens, see
[update.go](https://github.com/pulumi/pulumi/pull/14057/files#diff-7d2ca3e83a05073b332435271496050e28466b4f7af8c0c91bbc77947a75a3a2R378)),
as this was the original motivation of
a9ae602867.

## Checklist

- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [ ] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] ~Yes, there are changes in this PR that warrants bumping the
Pulumi Cloud API version~
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-09-29 22:12:35 +00:00
Kyle Dixler 98188c110c
[display] fix ComponentResource deletion not stopping time elapsed timer ()
<!--- 
Thanks so much for your contribution! If this is your first time
contributing, please ensure that you have read the
[CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md)
documentation.
-->

# Description

<!--- Please include a summary of the change and which issue is fixed.
Please also include relevant motivation and context. -->

Fixes 

ComponentResources now emit resourceOutputEvent on delete
steps. This fixes the time elapsed timer not stopping when the resource
is deleted.

## Checklist

- [x] I have run `make tidy` to update any new dependencies
- [x] I have run `make lint` to verify my code passes the lint check
  - [x] I have formatted my code using `gofumpt`

<!--- Please provide details if the checkbox below is to be left
unchecked. -->
- [x] I have added tests that prove my fix is effective or that my
feature works
<!--- 
User-facing changes require a CHANGELOG entry.
-->
- [x] I have run `make changelog` and committed the
`changelog/pending/<file>` documenting my change
<!--
If the change(s) in this PR is a modification of an existing call to the
Pulumi Cloud,
then the service should honor older versions of the CLI where this
change would not exist.
You must then bump the API version in
/pkg/backend/httpstate/client/api.go, as well as add
it to the service.
-->
- [ ] Yes, there are changes in this PR that warrants bumping the Pulumi
Cloud API version
<!-- @Pulumi employees: If yes, you must submit corresponding changes in
the service repo. -->
2023-09-29 19:48:33 +00:00
Fraser Waters 4ebf61f896
Move sdk/go/common/display to /pkg/display ()
Similar to how https://github.com/pulumi/pulumi/pull/13953 moves some
code from sdk/go/common to /pkg. This display code is only used in /pkg,
another simple reduction of what's in sdk/go/common.
2023-09-18 11:01:28 +00:00
Fraser Waters a691975202 Warn about ambient plugins loaded from $PATH
By default Pulumi will load ambient plugins from $PATH before looking in
the plugins directory or at bundled plugins.

While this is very useful for development it often causes confusion when
people have forgotten that they have plugins left on $PATH.

This makes the use of these $PATH plugins a diagnostic warning to try
and make that failure mode a little less silent.

Normal users shouldn't ever have plugins on $PATH and so won't see this
new warning.

Re-instates https://github.com/pulumi/pulumi/pull/13607 with a fix for
symlinks included.
2023-08-08 13:11:34 +01:00
Kyle Dixler 86ebe1bbd3 Revert "Warn about ambient plugins loaded from $PATH" 2023-08-04 16:54:16 -07:00
Fraser Waters a5b1590499 Warn about ambient plugins loaded from $PATH
By default Pulumi will load ambient plugins from $PATH before looking in
the plugins directory or at bundled plugins.

While this is very useful for development it often causes confusion when
people have forgotten that they have plugins left on $PATH.

This makes the use of these $PATH plugins a diagnostic warning to try
and make that failure mode a little less silent.

Normal users shouldn't ever have plugins on $PATH and so won't see this
new warning.
2023-07-27 17:59:44 +01:00
Pat Gavlin 948bb36e7e [engine] Add support for source positions
These changes add support for passing source position information in
gRPC metadata and recording the source position that corresponds to a
resource registration in the statefile.

Enabling source position information in the resource model can provide
substantial benefits, including but not limited to:

- Better errors from the Pulumi CLI
- Go-to-defintion for resources in state
- Editor integration for errors, etc. from `pulumi preview`

Source positions are (file, line) or (file, line, column) tuples
represented as URIs. The line and column are stored in the fragment
portion of the URI as "line(,column)?". The scheme of the URI and the
form of its path component depends on the context in which it is
generated or used:

- During an active update, the URI's scheme is `file` and paths are
  absolute filesystem paths. This allows consumers to easily access
  arbitrary files that are available on the host.
- In a statefile, the URI's scheme is `project` and paths are relative
  to the project root. This allows consumers to resolve source positions
  relative to the project file in different contexts irrespective of the
  location of the project itself (e.g. given a project-relative path and
  the URL of the project's root on GitHub, one can build a GitHub URL for
  the source position).

During an update, source position information may be attached to gRPC
calls as "source-position" metadata. This allows arbitrary calls to be
associated with source positions without changes to their protobuf
payloads. Modifying the protobuf payloads is also a viable approach, but
is somewhat more invasive than attaching metadata, and requires changes
to every call signature.

Source positions should reflect the position in user code that initiated
a resource model operation (e.g. the source position passed with
`RegisterResource` for `pet` in the example above should be the source
position in `index.ts`, _not_ the source position in the Pulumi SDK). In
general, the Pulumi SDK should be able to infer the source position of
the resource registration, as the relationship between a resource
registration and its corresponding user code should be static per SDK.

Source positions in state files will be stored as a new `registeredAt`
property on each resource. This property is optional.
2023-07-10 14:35:40 -07:00
Kyle Dixler 2b803b4ab8
Consolidated Target parameters
Consolidated `Target` parameters to a single variable. The deployment
executor is not well aware of the overall update that is going on and
runs individual resource operations. The consolidation minimizes
leakage.

Moved `--target` validation for `destroy` and `refresh` into `pkg/engine`.

Fixed  where `checkTargets()` would check the `prev` Snapshot for
resources after `rebuildBaseState()` was called. This would mutate prev
by removing resources from the snapshot. This caused deleted resources
on targeted updates not to be found and be reported as an error due to
having an unknown target.
2023-06-08 08:42:03 -07:00
Abhinav Gupta 7aa5b77a0c
all: Reformat with gofumpt
Per team discussion, switching to gofumpt.

[gofumpt][1] is an alternative, stricter alternative to gofmt.
It addresses other stylistic concerns that gofmt doesn't yet cover.

  [1]: https://github.com/mvdan/gofumpt

See the full list of [Added rules][2], but it includes:

- Dropping empty lines around function bodies
- Dropping unnecessary variable grouping when there's only one variable
- Ensuring an empty line between multi-line functions
- simplification (`-s` in gofmt) is always enabled
- Ensuring multi-line function signatures end with
  `) {` on a separate line.

  [2]: https://github.com/mvdan/gofumpt#Added-rules

gofumpt is stricter, but there's no lock-in.
All gofumpt output is valid gofmt output,
so if we decide we don't like it, it's easy to switch back
without any code changes.

gofumpt support is built into the tooling we use for development
so this won't change development workflows.

- golangci-lint includes a gofumpt check (enabled in this PR)
- gopls, the LSP for Go, includes a gofumpt option
  (see [installation instrutions][3])

  [3]: https://github.com/mvdan/gofumpt#installation

This change was generated by running:

```bash
gofumpt -w $(rg --files -g '*.go' | rg -v testdata | rg -v compilation_error)
```

The following files were manually tweaked afterwards:

- pkg/cmd/pulumi/stack_change_secrets_provider.go:
  one of the lines overflowed and had comments in an inconvenient place
- pkg/cmd/pulumi/destroy.go:
  `var x T = y` where `T` wasn't necessary
- pkg/cmd/pulumi/policy_new.go:
  long line because of error message
- pkg/backend/snapshot_test.go:
  long line trying to assign three variables in the same assignment

I have included mention of gofumpt in the CONTRIBUTING.md.
2023-03-03 09:00:24 -08:00
Abhinav Gupta 021a48e495
pkg/engine: Prefer contract.Assertf over Assert
Incremental step towards 

Migrates uses of contract.{Assert, AssertNoError, Require} in pkg/engine
to `*f` variants so that we're required to provide more error context.

Refs 
2023-02-15 10:23:38 -08:00
Abhinav Gupta 0bff0b8716 sdk/go: Remove 'nolint' directives from package docs
Go treats comments that match the following regex as directives.

    //[a-z0-9]+:[a-z0-9]

Comments that are directives don't show in an entity's documentation.
5a550b6951 (diff-f56160fd9fcea272966a8a1d692ad9f49206fdd8dbcbfe384865a98cd9bc2749R165)

Our code has `//nolint` directives that now show in the API Reference.
This is because these directives are in one of the following forms,
which don't get this special treatment.

    // nolint:foo
    //nolint: foo

This change fixes all such directives found by the regex:
`// nolint|//nolint: `.
See bottom of commit for command used for the fix.

Verification:
Here's the output of `go doc` on some entities
before and after this change.

Before
```
% go doc github.com/pulumi/pulumi/sdk/v3/go/pulumi | head -n8
package pulumi // import "github.com/pulumi/pulumi/sdk/v3/go/pulumi"

nolint: lll, interfacer

nolint: lll, interfacer

const EnvOrganization = "PULUMI_ORGANIZATION" ...
var ErrPlugins = errors.New("pulumi: plugins requested")
```

After
```
% go doc github.com/pulumi/pulumi/sdk/v3/go/pulumi | head -n8
package pulumi // import "github.com/pulumi/pulumi/sdk/v3/go/pulumi"

const EnvOrganization = "PULUMI_ORGANIZATION" ...
var ErrPlugins = errors.New("pulumi: plugins requested")
func BoolRef(v bool) *bool
func Float64Ref(v float64) *float64
func IntRef(v int) *int
func IsSecret(o Output) bool
```

Before
```
% go doc github.com/pulumi/pulumi/sdk/v3/go/pulumi URN_
package pulumi // import "github.com/pulumi/pulumi/sdk/v3/go/pulumi"

func URN_(o string) ResourceOption
    URN_ is an optional URN of a previously-registered resource of this type to
    read from the engine. nolint: revive
```

After:
```
% go doc github.com/pulumi/pulumi/sdk/v3/go/pulumi URN_
package pulumi // import "github.com/pulumi/pulumi/sdk/v3/go/pulumi"

func URN_(o string) ResourceOption
    URN_ is an optional URN of a previously-registered resource of this type to
    read from the engine.
```

Note that golangci-lint offers a 'nolintlint'  linter
that finds such miuses of nolint,
but it also finds other issues so I've deferred that to a follow up PR.

Resolves 

Related: https://github.com/golangci/golangci-lint/issues/892

[git-generate]
FILES=$(mktemp)
rg -l '// nolint|//nolint: ' |
  tee "$FILES" |
  xargs perl -p -i -e '
    s|// nolint|//nolint|g;
    s|//nolint: |//nolint:|g;
  '
rg '.go$' < "$FILES" | xargs gofmt -w -s
2023-01-06 09:06:47 -08:00
Fraser Waters 81b137b5f9 Decouple the generation of plans from the automatic use of plans
This threads a new option "Experimental" through to the engine which is
used to decided if plans should be used or not. This also generates
plans for any preview with --save-plan, but also now generates plans
during the preview phase of up.
2022-10-28 17:56:47 +01:00
Ian Wahbe 856bded330 test # This is a combination of 3 commits.
Support future glob patterns

Improve name for unspecified targets

Add a test in target_test
2022-10-25 16:54:58 -07:00
Fraser Waters 84e0fd6d3b Rename ExperimentalPlans to GeneratePlan
This option is just used to control if a plan is generated or not, we'll
continue to use it even after plans are no longer experimental. No need
to generate a plan if it's not being used at all (e.g. during `up`).
2022-10-10 09:19:32 +01:00
Fraser Waters 0ebe40a0c9
Fix getOrganization in policy ()
* Fix getOrganization in policy

* Add to CHANGELOG
2022-09-02 11:47:38 +02:00
Fraser Waters 6b496b0d18
Split PluginInfo in Info and Spec ()
Retry of https://github.com/pulumi/pulumi/pull/10492.

This time with a fixed and improved testDeletePlugin function.

This reverts commit 603d859126.
2022-08-26 15:51:14 +01:00
Anton Tayanovskyy 603d859126
Revert "Split PluginInfo in Info and Spec ()" ()
This reverts commit b81207f98c.
2022-08-25 14:56:23 -04:00
Fraser Waters b81207f98c
Split PluginInfo in Info and Spec ()
PluginSpec is used to specifiy a plugin, and is what is passed to things
like "Install". PluginInfo is used to refer to an installed plugin, and
so has extra data like file sizes, and time stamps, but does not include
things like plugin download url.
2022-08-25 12:27:28 +01:00
Harry bb84532fe6
Plugin Link ()
* demo

* modifications for serialization

* Provisionally changed plugins from map to array

* warnings for duplicate

* avoid breaking change

* avoid null pointer dereference

* added test

* Delete Pulumi.yaml

* ensurePluginsAreInstalled

* lint

* reworked NewContext and added kind

* auto-detect current project for YAML

* lint

* removed debug statement

* automatically modify local paths

* typo

* First return value of GetPluginPath was never used

* Always use the path returned from getPluginInfoAndPath in GetPluginPath

Also assert that Path is the correct directory for PluginInfo.

* address comments

* added language, analyzers

* path tweaks and cosmetic changes

* changelog + tweaks

* changed NewContextWithRoot to accept plugins instead of project

* Fix TestUnmarshalProjectWithProviderList

* Fix NewContext

* Fix comment

Co-authored-by: Fraser Waters <fraser@pulumi.com>
2022-07-22 14:17:43 +01:00
Richard Shade a5687d16a9
Moving previewDigest to sdk/go/common/display, and exporting it. ()
* Moving previewDigest and exporting it, closes 

* Moving previewDigest and exporting it, closes 

* Updating changelog-pending

* Go Mod Tidy

* replacing to local

* more go.mod changes

* reseting go mod

* full move

* Fixing golint

* No go.mod changes needed
2022-06-27 09:08:06 -05:00
Ian Wahbe d9ea78ff58
Set unspecified explicit provider version to default provider version ()
The Problem

Explicit providers that don't specify version/pluginDownloadURL are created using a potentially different plugin than the default provider.

We can have multiple versions of providers in the same go program at the same time. This means that we can also have multiple plugins loaded for providers with the same name. Due to limitations of Go, we are not able to determine which SDK version of a provider made an individual register resource request. Because requests don't specify versions, we get the above behavior trying to guess.

Pre-PR behavior

For (non-provider) resources without an explicit provider set, we use the default provider which takes its plugin from SDK provided by go.mod (or language equivalent). For explicit providers without version we take the locally installed plugin with the highest version.

Post-PR behavior

For (non-provider) resources without an explicit provider set, we use the default provider which takes its plugin from SDK provided by go.mod (or language equivalent). For explicit providers without version/pluginDownloadURL we check if there is a default provider for that package. If there is, we use that version/pluginDownloadURL. If no default exists, we still use the highest installed version.
2022-06-15 13:03:11 -07:00
Ian Wahbe f3e430a1da
Respond to SIGINT during plugin install ()
* Respond to SIGINT

With the current state of the PR, crash on SIGINT. This is progress.

* Don't crash responding to SIGINT

* Close on cancel instead of terminate

* CL

* Fix lint

* Add ctx for node

* Be consistent for test context
2022-06-09 14:57:56 -07:00
Fraser Waters 40eee5868e
Preview of update plans ()
* Implement resource plans in the engine

* Plumb plans through the CLI.

* Update wording

* plan renderer

* constraints

* Renames

* Update message

* fixes for rebase breaks and diffs

* WIP: outputs in plans

* fix diff

* fixup

* Liniting and test fixing

* Test and fix PropertyPath.String()

* Fix colors

* Fix cmdutil.PrintTable to handle non-simple strings

* More tests

* Readd test_plan.go

* lint

* Test expected deletes

* Test expected delete

* Test missing create

* Fix test for missing creates

* rm Paths()

* property set shrink test

* notes

* More tests

* Pop op before constraint check

* Delete plan cmd, rename arguments to preview and up

* Hide behind envvars

* typo

* Better constraint diffs

* Adds/Deletes/Updates

* Fix aliased

* Check more constraints

* fix test

* revert stack changes

* Resource sames test

* Fix same resource test

* Fix more tests

* linting

* Update pkg/cmd/pulumi/up.go

Co-authored-by: Alex Mullans <a.mullans@pulumi.com>

* Update pkg/cmd/pulumi/preview.go

Co-authored-by: Alex Mullans <a.mullans@pulumi.com>

* Auto refresh if using plans

* Fix TestGetRefreshOption

* Fix TestExplicitDeleteBeforeReplace

* lint

* More copying in tests because I do not trust myself to get mutation correct

* Small preview plan test

* Add TestPlannedUpdateChangedStack

* Revert auto-refresh changes

* Validate outputs don't change

* omitempty

* Add manifest to plan

* Add proper Plan type

* wip config work

* Config and manifest serder

* linting

* Asset NoError

* Actually check error

* Fix clone

* Test diag message

* Start on more tests

* Add String and GoString to Result

I got fed up assert errors in tests that looked like:
```
Expected nil, but got: &result.simpleResult{err:(*errors.fundamental)(0xc0002fa5d0)}
```

It was very hard to work out at a glance what had gone wrong and I kept
having to hook a debugger just to look at what the error was.

With GoString these now print something like:
```
Expected nil, but got: &simpleResult{err: Unexpected diag message: <{%reset%}>resource violates plan: properties changed: -zed, -baz, -foo<{%reset%}>
}
```

Which is much more ussful.

* Add test error text

* Fix reporting of unseen op errors

* Fix unneeded deletes

* Fix unexpected deletes

* Fix up tests

* Fix merge conflict

* lint

* Fix nil map error

* Fix serialisation typo

* Diff against old inputs

* Diff against checked goal

* Diff against empty for creates

* Fix test

* inputs not outputs

* Seperate PlanDiff type

* Add properties

* Fix input diffs

* Handle creates

* lint

* Add plan message

* Clone plan for update preview

* Save and serialise env vars in plans

* lint

* pretty print json

* input output difference test

* test alias

* fix typo in for loop

* Handle resource plans with nil goal

* go mod tidy

* typo

* Auto use plans from up previews in experimental mode

* Don't preview if we have plan

* Don't run previews with plans now

* fixing tests

* Handle diffs and goals

* Update copystructure

* tests/go.sum

* Revert mod changes

* Add copystructure to tests/go.sum

* includeUnknowns

* go mod tidy

* Make plans for imports

* Remove unused function

* Move code more locally

* Handle nil in serialize

* Handle empty output diffs

* Add test for dropping computed values

* Allow computed properties to become deletes

* if out the generation of plans unless experimental mode is opt'd into

* lint

* typo

* Revert back to plans not skipping previews, this is orthognal to --skip-preview

* Trying to work out non-determinism

* Remove notes.txt

* Hacking with check idea

* Pass checked inputs back to Check from plan file

* Include resource urn in constraint error

* Give much more informative errors when plans fail

* lint

* Update expected diag strings in tests

* Remove unused code

* Duplicate Diff and DeepEquals methods for plans

* Add comment about check ops with failures

* Fix CheckedInputs comment

* OutputDiff doesn't need to be a pointer

* Fix checks against computed

* diffStringSets

* lint

* lint pkg

* Use 4 space indent

* Don't wrap Buffer in Writer

* Mark flags hidden rather than disabled

* Remove envvars from plans

* Assert MarkHidden error

* Add to changelog

* Note plan/save-plan is experimental

Co-authored-by: Pat Gavlin <pat@pulumi.com>
Co-authored-by: Alex Mullans <a.mullans@pulumi.com>
2022-01-31 10:31:51 +00:00
Ian Wahbe 8e5e4caf6e
Pipe serverURL through register resource ()
* [engine] Pipe serverURL through register resource

* Fix lint

* Thread serverURL through default provider calls

* Change tag from "serverURL" to "pluginDownloadURL"

* Update CHANGELOG_PENDING.md

* Allow provider to be null

* Fix tests

* Include server url passthrough in test

* Fix parseProviderRequest

* Add test for url pass through

* Fix lint

* Correct small nits from @justinp

* Add test for default providers

* Move special helpers to providers

* Partial conversion serverURL -> pluginDownloadURL

* Remove serverURL

* Remove more serverURL instances

* const correctness

* Add url to ProviderRequest.Name()

I also canonicalize the url by removing any trailing '/'

* Fix typo + lint

* Add test for url canonicalization

* Fix ProviderRequest.Name for version=nil
2021-12-17 14:52:01 -08:00
Ian Wahbe 272c4643b2
Update error handling ()
This is the result of a change applied via `go-rewrap-errors`.
2021-11-12 18:37:17 -08:00
Justin Van Patten ed4b53d3ae
Add monitor feature for output values () 2021-09-15 14:16:00 -07:00
Evan Boyle f4efb7564b
Respect provider aliases () 2021-07-28 12:12:53 -07:00
pulumi-bot 73a66f48ea [breaking] Changing the version of go.mod in sdk / pkg to be v3 2021-04-14 19:32:18 +01:00
Pat Gavlin 9b6a7a4397
Improve resource ref unit tests. ()
- Add component ref coverage to the existing test
- Add coverage for a downlevel SDK communicating with an engine that
  supports resource refs
- Add coverage for a downlevel engine communicating with an SDK that
  supports resource refs

As part of improving coverage, these changes add a knob to explicitly
disable resource refs in the engine without the use of the environment
variable. The environment variable is now only read by the CLI, and has
been restored to its prior polarity (i.e. `PULUMI_ENABLE_RESOURCE_REFERENCES`).
2020-12-16 12:38:20 -08:00
Pat Gavlin f0951ce650
Rename engine.plan to engine.deployment. ()
This name better suits the semantics of the type, and aligns with the
rename of deploy.Plan to deploy.Deployment. These changes also refactor
the `update` method s.t. previews and updates are more consistent in
their behavior (e.g. duration and resource changes are now reported for
both, incl. on error paths).
2020-11-18 11:16:30 -08:00