Commit Graph

5 Commits

Author SHA1 Message Date
Fraser Waters 97d94658c1
Refactor transformation tests and add Go test ()
This removes the dynamic resources from the transformation tests and
just uses the testprovider instead. As such we can now also write the Go
transform test in pretty much exactly the same way in the same place.

I've removed the golang_sdk test from lifecycletest has it's now covered
by this integration test.
2023-12-16 14:06:27 +00:00
Robbie McKinstry c500b3b997
Revert package.json lookup fix. 2023-05-15 14:14:57 -04:00
Robbie McKinstry dad42a4954
Remove references to missing files.
It appears that a large number of tests were using references
to main fields which don't currently exist. The runtime didn't
produce an error because package.json was being ignored.
2023-05-10 18:04:59 -04:00
Luke Hoban 893e51d0ce
Add Python resource transformations support ()
Adds Python support for resource transformations aligned with the existing NodeJS support in .

This PR also moves processing of transformations to earlier in the resource construction process (for both NodeJS and Python) to ensure that invariants established in the constructor cannot be violated by transformations. This change can technically be a breaking change, but given that (a) the transformations features was just released in 1.3.0 and (b) the cases where this is a breaking change are uncommon and unlikely to have been reliable anyway - it feels like a change we should make now.

Fixes .
2019-10-14 19:35:00 -05:00
Luke Hoban 9374c374c3
Transformations ()
Adds the ability to provide `transformations` to modify the properties and resource options that will be used for any child resource of a component or stack.

This offers an "escape hatch" to modify the behaviour of a component by peeking behind it's abstraction.  For example, it can be used to add a resource option (`additionalSecretOutputs`, `aliases`, `protect`, etc.) to a specific known child of a component, or to modify some input property to a child resource if the component does not (yet) expose the ability to control that input directly.  It could also be used for more interesting scenarios - such as:
1. Automatically applying tags to all resources that support them in a stack (or component)
2. Injecting real dependencies between stringly-referenced  resources in a Helm Chart 
3. Injecting explicit names using a preferred naming convention across all resources in a stack
4. Injecting `import` onto all resources by doing a lookup into a name=>id mapping

Because this feature makes it possible to peek behind a component abstraction, it must be used with care in cases where the component is versioned independently of the use of transformations.  Also, this can result in "spooky action at a distance", so should be used judiciously.  That said - this can be used as an escape hatch to unblock a wide variety of common use cases without waiting on changes to be made in a component implementation.  

Each transformation is passed the `resource`, `name`, `type`, `props` and `opts` that are passed into the `Resource` constructor for any resource descended from the resource that has the transformation applied.  The transformation callback can optionally return alternate versions of the `props` and `opts` to be used in place of the original values provided to the resource constructor.

Fixes .
2019-09-29 11:27:37 -07:00