5dd813ea47
When a resource depends on a local component resource, rather than setting the component resource itself as a dependency, each of the component's descendants is added as a dependency. This can lead to hangs when cycles are introduced.
For example, consider the following parent/child hierarchy, where `ComponentA` is the parent of `ComponentB` and `ComponentB` is the parent of `CustomC`:
ComponentA
|
ComponentB
|
CustomC
If `ComponentB` specifies it has a dependency on `ComponentA`, the following takes place as part determining the full set of transitive dependencies:
1. `ComponentA` is a component resource so it isn't added as a dependency, its children are.
2. `ComponentA` has one child: `ComponentB`
3. `ComponentB` is a component resource so it isn't added as a dependency, its children are.
4. `ComponentB` has one child: `CustomC`, a custom resource.
5. Since `CustomC` is a custom resource, it is added to the set of dependencies.
6. We try to await its URN, but we'll never get it because `RegisterResource` hasn't yet been called for it. And we hang waiting.
To address this, skip looking at a component's children if it is the component from which the dependency is being added.
In the example, with the fix, at step 3 the dependency expansion will stop: we won't look at `ComponentB`'s children because we're adding the dependency from `ComponentB`.
PR feedback
|
||
|---|---|---|
| .. | ||
| aliases | ||
| asset | ||
| chained_failure | ||
| component_dependencies | ||
| component_provider_resolution | ||
| component_resource_list_of_providers | ||
| component_resource_single_provider | ||
| config | ||
| delete_before_replace | ||
| empty | ||
| first_class_provider | ||
| first_class_provider_invoke | ||
| first_class_provider_unknown | ||
| future_failure | ||
| future_input | ||
| ignore_changes | ||
| inherit_defaults | ||
| inheritance_translation | ||
| inheritance_types | ||
| input_type_mismatch | ||
| input_values_for_outputs | ||
| invalid_property_dependency | ||
| invoke | ||
| invoke_future | ||
| invoke_types | ||
| large_resource | ||
| marshal_failure | ||
| one_complex_resource | ||
| one_resource | ||
| output_all | ||
| output_nested | ||
| output_property_dependencies | ||
| outputs_future | ||
| preview | ||
| property_dependencies | ||
| property_renaming | ||
| protect | ||
| read | ||
| remote_component_dependencies | ||
| replace_on_changes | ||
| resource_op_bad_inputs | ||
| resource_op_fail | ||
| resource_thens | ||
| runtime_settings | ||
| stack_output | ||
| ten_resources | ||
| types | ||
| versions | ||
| README.md | ||
| __init__.py | ||
| util.py | ||
README.md
Python Language Host Tests
The tests in this directory test the language host directly by posing as the engine and running programs in the same context that they would be run by the CLI. Programs run by these tests can create resources, read resource, invoke data sources, and generally do anything that a Pulumi program can do.
Language host tests provide a program to be run and an implementation
of the LanghostTest class, which provides implementations for the
four resource monitor endpoints that the language host speaks to:
invoke, for invoking data sources,read_resource, for reading existing resources,register_resource, for creating new resources,register_resource_outputs, for registering outputs on component resources
Classes deriving from LanghostTest can override any of these methods
to provide custom test functionality. This is commonly used to perform assertions
or place the language host in unexpected situations.
Adding a new test
To add a new language host test, you can:
- Create a new directory in this directory with the name of your test
- Place an
__init__.pyand__main__.pyin this directory.__init__.pyconvinces Python that this directory is a module, while__main__.pyindicates to Python that this module is runnable. - Write your Pulumi program in
__main__.py. If you want to do assertions, use theassertkeyword to do so. - Add a test file, which can have any name. In this test file you'll want to provide a
subclass of
LanghostTestthat drives your test. An example minimal test would be something like this:
from os import path
from ..util import LanghostTest
class EmptyTests(LanghostTest):
def test_empty(self):
self.run_test(
program=path.join(self.base_path(), "empty"), # If your test is in the empty/ subdirectory
expected_resource_count=0) # Assert there are 0 resource registrations
Your class can have any number of test_* methods in them. Language host tests are launched by
invoking the run_test method inherited from LanghostTest. run_test accepts the following
keyword arguments:
project- The name of the project that will be exposed to the running programstack- The name of the stack that will be exposed to the running programprogram- A path to the program to be run, relative to the working directory.pwd- The working directory to use.args- Command-line arguments to pass to the program.config- A dict of configuration keys and values to pass to the program.expected_resource_count- The number of resources this test is expected to register.expected_error- If non-None, the exact error text that is expected to be received.expected_stderr_contains- If non-None, asserts that the given substring exists in stderr
If expected_error is None, the expected error is asserted to be the empty string.
Note that your test method must begin with test_*, since this is how Python discovers what
tests to run.
One additional thing to note is that this test harness explicitly ignores the registration
of the top-level Stack resource, pulumi:pulumi:Stack, because it is annoying to write tests around.
All expected resource counts do not count this resource as a registration and overridden resource monitor
methods will never see a registration for pulumi:pulumi:Stack.