mirror of https://github.com/pulumi/pulumi.git
c7ed4024ff
An exploration into how we could support int64 as well as float64 as a first class type in Pulumi. There's some inherit trickiness with this because we use JSON in a few places, state files most obviously but `PropertyValue` on the wire is using the protobuf `Struct` and `Value` types which are just mappings to JSON as well. JSON doesn't have an int64 type, and while the Go JSON marshaller can read/write int64s it's not a great behaviour to rely on given mixed support for that across languages. Further the protobuf `Value` type only supports float64s. So we support integers similar to our other special types (like assets) and wrap them in an object with a special signature field. The value itself is either a number (if it can safely roundtrip to float64 and back again) or a string. Providers, SDKs and the engine communicate support for integers via `AcceptsIntegers` fields in their interfaces (or similar). When transmitting to a peer that doesn't support integers (e.g. an old SDK, or old provider) all integer values are mapped back to standard number values. As this changes the serialisation of property values in the state file it will trigger errors if old engines try to load a state file containing integers. |
||
|---|---|---|
| .. | ||
| providers | ||
| testdata | ||
| README.md | ||
| go.mod | ||
| go.sum | ||
| interface.go | ||
| interface_test.go | ||
| internal_test.go | ||
| l1empty_test.go | ||
| l1main_test.go | ||
| l2continue_on_error_test.go | ||
| l2destroy_test.go | ||
| l2large_test.go | ||
| l2long_test.go | ||
| l2resourceasset_test.go | ||
| l2resourcesimple_test.go | ||
| main.go | ||
| runtime_options_test.go | ||
| snapshot_test.go | ||
| snapshots.go | ||
| test_host.go | ||
| testing.go | ||
| tests.go | ||
README.md
pulumi-language-test runs a gRPC interface that language plugins can use to run a suite of standard tests.
Architecture
pulumi-language-test is used to run a standard suite of tests against any compliant language plugin.
The diagram below shows the main interactions and data flows for how this system works.
There are three main actors involved. Firstly test which is a test function coordinating the language plugin and pulumi-language-test. Secondly ptl which is the pulumi-language-test process. Finally uut which is the language plugin actually being tested. This will generally be a grpc server running in the same process as the test method.
sequenceDiagram
test->>ptl: Start ptl process
ptl-->>test: Read stdout for ptl address to connect to
Note right of test: All future calls to ptl are via grpc
test->>+ptl: GetLanguageTests()
ptl-->>-test: Returns list of test names
test->>+uut: Serve
uut-->>-test: Returns uut server address
test->>+ptl: PrepareLanguageTests(uut)
ptl->>+uut: Pack(core)
uut-->>-ptl: Returns name of core artifact
ptl-->>-test: Returns `token`
loop for each test
test->>+ptl: RunLanguageTest(token, test)
loop for each sdk used in test
ptl->>+uut: GeneratePackage(sdk)
uut-->>-ptl: Write package code to temporary directory
ptl->>ptl: Verify sdk snapshot
ptl->>+uut: Pack(sdk)
uut-->>-ptl: Returns name of sdk artifact
end
ptl->>+uut: GenerateProject(test)
uut-->>-ptl: Write project code to temporary directory
ptl->>ptl: Verify project snapshot
ptl->>+uut: InstallDependencies(project)
uut-->>-ptl:
note right of ptl: Execute test with engine
activate ptl
ptl->>+uut: Run(project)
uut-->>-ptl: Return run result
ptl->>ptl: Run test asserts against run result and snapshot
deactivate ptl
ptl-->>-test: Returns test result from asserts
end
test->>ptl: sigkill
Meta tests
This module contains a number of _test.go files. These are tests of the conformance test system itself. The actual conformance tests are all defined in tests.go.