<!---
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 reverts commit 75340dd942.
Fixes https://github.com/pulumi/pulumi/issues/16018.
This re-enables the locking and race detection. The locking is more
finely scoped to not be held over provider methods like Read/Update.
## 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
<!---
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. -->
Similar to destroy --continue-on-error, this flag allows `pulumi up`
to continue if any errors are encountered.
Currently when we encounter an error while creating/updating a
resource, we cancel the context of the deployment executor, and thus
the deployment stops once the resources that are being processed in
parallel with the failed one finish being updated.
For --continue-on-error, we ignore these errors, and let the
deployment executor continue. In order for the deployment executor to
exit eventually we also have to mark these steps as done, as the
deployment executor will otherwise just hang, and callers with open
channels waiting for it to finish/report back will hang indefinitely.
The errors in the step will still be reported back to the user by the
OnResourceStepPost callback.
Fixes https://github.com/pulumi/pulumi/issues/14515
---------
Co-authored-by: Fraser Waters <fraser@pulumi.com>
<!---
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 reverts the sdk and pkg changes from commit
655b76d030.
It also disables race detection from all builds and tests.
Fixes https://github.com/pulumi/pulumi/issues/15991.
## 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
<!---
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. -->
<!---
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 tests the production snapshot manager against the journalling
snapshot system in engine tests. This should ensure that both systems
produce similar (we ignore exact resource ordering, as long as both are
valid) results.
## 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.
-->
- [ ] 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. -->
<!---
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. -->
Combining #15120 and #15124 and including fixes to allow tests to pass.
Enable race detection in the binary we're using for integration tests.
This will allow us to catch more data races before they get into any
release. This does mean the binary we're using for integration tests is
slightly different from the binary we're releasing, however that's
already the case as we're running a binary with coverage enabled for
them. Later we rebuild the binary we're actually releasing.
This requires us to fix the race between snapshot code, display code,
and the step executor. I've done that by adding a lock to the State
struct. This does not feel great, but it's a quick way to fix this and
get race detection running (and unblocks #15871 which was also hitting
the race detector because it started pulling snapshot code into unit
tests as well). There's probably a more principled overhaul that doesn't
require locking at this level.
## 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. -->
If an update fails, update any stack outputs that were updated, but
otherwise leave existing stack outputs as-is. In other words, don't
delete stack outputs if the stack didn't successfully run to completion.
Implementation note: when we receive a RegisterResourceOutputsEvent for
the stack resource, we defer processing it until the end of the
deployment, to know whether the deployment ran to completion without
errors.
Fixes#14621
---------
Co-authored-by: Thomas Gummerer <t.gummerer@gmail.com>
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
<!---
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 fixes a data race between the snapshot system and the step executor
for create before delete replacements.
When doing a create-before-delete replacement the step generator would
issue two steps to the step executor. The first step being Create which
would create the new resource instance and add that state to the
snapshot system to be saved. The second being a replace step, which
didn't interact with the snapshot system but is a step that executes.
There's a bit of code in the executor that ran for every step to mutate
the outputs to ensure secrets propagated correctly. This could run in
parallel with the snapshot system trying to iterator over the outputs to
serialise them out and causes a "concurrent map iteration and map write"
error.
It is obviously very hard to write a test to show this but, work being
done in https://github.com/pulumi/pulumi/pull/14079 should improve the
likelihood of us detecting issues like this in pu/pu tests.
## 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
<!---
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. -->
Combination of a few cleanups.
1. Don't call .Error() on errors that are being passed to "%s" format
functions. Format will call `Error()` itself.
2. Don't call assert.Error then assert.Equal/Contains, just use
assert.ErrorEqual/ErrorContains instead.
3. Use "%w" if appropriate, instead of "%v"/"%s".
<!---
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 https://github.com/pulumi/pulumi/issues/14611.
`atomic.Value` panics if a second value is written to it which isn't
_exactly_ the same type. We were using this to atomically record any
errors that happened, although where only interested in saving the first
error.
This was fine if no or one error happened, or if multiple errors
happened that all were the same error type. But if two errors if
different error types happened `sync.Value` would panic.
Switched to use a promise completion source instead. If any error
happens we use it to reject the completion source, we also log if this
isn't the first error we've seen (a capabilitiy that `sync.Value` didn't
give us). At the end of the step executor being used when `Errored()` is
called we try to get the result of the completion source.
## 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 - Added tests for the new promise function `TryResult`,
not sure it's that needed to try and write a test for the error case we
hit in #14611 now that it's type safe.
<!---
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. -->
This was getting annoying when debugging tests because a step would fail
it wouldn't propagate up in the wrapped error and we don't show the
diagnostic logs in tests.
<!---
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 results in much nicer errors being bubbled up to tests. User UX is
not changed by this because these errors are always wrapped into Bails
and so not shown to users.
We should make a similar change for step generator errors.
<!---
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 https://github.com/pulumi/pulumi/issues/14036.
Not sure this is perfect (it's pretty hard to reason about mutation of
the whole system given what Go gives us to work with), but it seems
better.
We copy event payloads on construction, which should be synchronous with
step execution, rather than on access which could be in parallel with
the step executor or deployment executor mutating resource state.
Just copying on construction flagged up that the deployment executor and
step executor both race to modify resource state when the deployment
executor starts scheduling deletes. We add a synchronisation point
between the two parts in this change so that the deployment executor
waits for the step executor to go quite, and keeps it quite while it
computes the deletes, once it starts scheduling them the step executor
can run again.
## 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
<!---
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. -->
<!---
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#2394
Fixes https://github.com/pulumi/pulumi-dotnet/issues/39
## 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. -->
<!---
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. -->
Part of the yak shave to get rid of the `Result` type. We need to do
these changes from the bottom up because we allow converting from
`error` to `Result` (we simply discard data), but not the other way
(because we'd have to make up an error and `from Result conversion`
isn't very informative).
This replaces the `Result` return value in
`ExecuteRegisterResourceOutputs` to `error`. This means we now get
errcheck lints which warned that we were discarding the result from this
call in the import code.
This makes the engine mark outputs as secret if there is an input of the
same name that is marked secret.
It is an undesirable experience for a user to have an input secret
leaked by an output of the same name by a misbehaving provider.
Fixes#4957
Resources marked --target-replace are now correctly targeted. The Pulumi
root stack resource is now also marked targeted similarly to default
providers.
Users were running into an error `error: this should already have a plan
from when we called register resources when previewing update` due to a
bug where `--target` being left empty would assume it was an
unconstrained update targeting everything despite `--target-replace`
being set.
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.
Remove staticcheck from the list of disabled linters.
It's enabled by default in golangci-lint.
This also fixes minor remaining staticcheck issues
that don't merit their own pull requests,
or opts out of those that cannot be fixed yet.
Notably, we're opting out of:
- Resource.Name is deprecated (#9469)
- github.com/golang/protobuf is deprecated (#11869)
- strings.Title has been deprecated (#11870)
Besides that, other issues addressed in this change are:
```
// all issues are in pkg
codegen/schema/docs_parser.go:103:4: SA4006: this value of `text` is never used (staticcheck)
codegen/schema/loader.go:253:3: SA9003: empty branch (staticcheck)
resource/deploy/step_executor.go:328:12: SA9003: empty branch (staticcheck)
resource/deploy/step_generator.go:141:10: SA9003: empty branch (staticcheck)
codegen/pcl/invoke.go:97:10: SA9003: empty branch (staticcheck)
codegen/hcl2/model/type_const.go:57:2: SA9003: empty branch (staticcheck)
codegen/hcl2/model/type_enum.go:99:9: SA4001: &*x will be simplified to x. It will not copy x. (staticcheck)
codegen/go/gen_test.go:399:19: SA4017: HasPrefix is a pure function but its return value is ignored (staticcheck)
```
Depends on #11857, #11858, #11859, #11860, #11862, #11865, #11866, #11867, #11868Resolves#11808
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`).
* 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>
State tracking for goals was implemented using a raw map,
but this was not safe for concurrent read/write access from
multiple goroutines. Switched to using a sync.Map, which
is threadsafe.
The step generator was incorrectly tracking goal states for
old resources, which could lead to a panic if the resource
was removed in the update. This fix only generates goal
states for resources that exist in the updated program.
Record new resources after their operations have been run rather than
before in order to ensure that all state is available and appropriately
marked as secret.
Fixes#5803.
Rename deploy.Plan to deploy.Deployment.
There are two benefits to this change:
1. The name "Deployment" more accurately reflects the behavior of the
type, which is responsible for previewing or executing a deployment.
2. Renaming this type frees up the name "Plan" for use when addressing
#2318.
- Remove `Info` from `Source`. This method was not used.
- Remove `Stack` from `EvalSource`. This method was not used.
- Remove `Type` and `URN` from `Step`. These values are available via
`Res().URN.Type()` and `Res().URN`, respectively. This removes the
possibility of inconsistencies between the type, URN, and state of the
resource associated with a `Step`.
- Remove URN from StepEventMetadata.
* Make `async:true` the default for `invoke` calls (#3750)
* Switch away from native grpc impl. (#3728)
* Remove usage of the 'deasync' library from @pulumi/pulumi. (#3752)
* Only retry as long as we get unavailable back. Anything else continues. (#3769)
* Handle all errors for now. (#3781)
* Do not assume --yes was present when using pulumi in non-interactive mode (#3793)
* Upgrade all paths for sdk and pkg to v2
* Backport C# invoke classes and other recent gen changes (#4288)
Adjust C# generation
* Replace IDeployment with a sealed class (#4318)
Replace IDeployment with a sealed class
* .NET: default to args subtype rather than Args.Empty (#4320)
* Adding system namespace for Dotnet code gen
This is required for using Obsolute attributes for deprecations
```
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'ObsoleteAttribute' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'Obsolete' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
```
* Fix the nullability of config type properties in C# codegen (#4379)
- If an untargeted create would not affect the inputs of any targeted
resources, do not fail the update. Untargeted creates that are
directly dependend on by targeted resources will still cause failures
that inform the user to add the untargeted resources to the --target
list.
- Users may now pass the `--target-dependents` flag to allow targeted
destroys to automatically target dependents that must be destroyed in
order to destroy an explicitly targeted resource.
Some providers (namely Kubernetes) require unbounded parallelism in
order to function correctly. This commit enables the engine to operate
in a mode with unbounded parallelism and switches to that mode by
default.
* Process deletions conservatively in parallel
This commit allows the engine to conservatively delete resources in
parallel when it is sure that it is legal to do so. In the absence of a
true data-flow oriented step scheduler, this approach provides a
significant improvement over the existing serial deletion mechanism.
Instead of processing deletes serially, this commit will partition the
set of condemned resources into sets of resources that are known to be
legally deletable in parallel. The step executor will then execute those
independent lists of steps one-by-one until all steps are complete.
* CR: Make ResourceSet a normal map
* Only use the dependency graph if we can trust it
* Reverse polarity of pendingDeletesAreReplaces
* CR: un-export a few types
* CR: simplify control flow in step generator when scheduling
* CR: parents are dependencies, fix loop index
* CR: Remove ParentOf, add new test for parent dependencies
* Serialize SourceEvents coming from the refresh source
The engine requires that a source event coming from a source be "ready
to execute" at the moment that it is sent to the engine. Since the
refresh source sent all goal states eagerly through its source iterator,
the engine assumed that it was legal to execute them all in parallel and
did so. This is a problem for the snapshot, since the snapshot expects
to be in an order that is a legal topological ordering of the dependency
DAG.
This PR fixes the issue by sending refresh source events one-at-a-time
through the refresh source iterator, only unblocking to send the next
step as soon as the previous step completes.
* Fix deadlock in refresh test
* Fix an issue where the engine "completed" steps too early
By signalling that a step is done before committing the step's results
to the snapshot, the engine was left with a race where dependent
resources could find themselves completely executed and committed before
a resource that they depend on has been committed.
Fixespulumi/pulumi#1726
* Fix an issue with Replace steps at the end of a plan
If the last step that was executed successfully was a Replace, we could
end up in a situation where we unintentionally left the snapshot
invalid.
* Add a test
* CR: pass context.Context as first parameter to Iterate
* CR: null->nil
* Execute chains of steps in parallel
Fixespulumi/pulumi#1624. Since register resource steps are known to be
ready to execute the moment the engine sees them, we can effectively
parallelize all incoming step chains. This commit adds the machinery
necessary to do so - namely a step executor and a plan executor.
* Remove dead code
* CR: use atomic.Value to be explicit about what values are atomically loaded and stored
* CR: Initialize atomics to 'false'
* Add locks around data structures in event callbacks
* CR: Add DegreeOfParallelism method on Options and add comment on select in Execute
* CR: Use context.Context for cancellation instead of cancel.Source
* CR: improve cancellation
* Rebase against master: execute read steps in parallel
* Please gometalinter
* CR: Inline a few methods in stepExecutor
* CR: Feedback and bug fixes
1. Simplify step_executor.go by 'bubbling' up errors as far as possible
and reporting diagnostics and cancellation in one place
2. Fix a bug where the CLI claimed that a plan was cancelled even if it
wasn't (it just has an error)
* Comments
* CR: Add comment around problematic select, move workers.Add outside of goroutine, return instead of break