2018-06-29 21:08:58 +00:00
|
|
|
# Copyright 2016-2018, Pulumi Corporation.
|
|
|
|
#
|
|
|
|
# Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
# you may not use this file except in compliance with the License.
|
|
|
|
# You may obtain a copy of the License at
|
|
|
|
#
|
|
|
|
# http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
#
|
|
|
|
# Unless required by applicable law or agreed to in writing, software
|
|
|
|
# distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
# See the License for the specific language governing permissions and
|
|
|
|
# limitations under the License.
|
|
|
|
"""
|
|
|
|
Utility functions and classes for testing the Python language host.
|
|
|
|
"""
|
|
|
|
|
2018-10-31 20:35:31 +00:00
|
|
|
import asyncio
|
2023-07-17 12:18:54 +00:00
|
|
|
import logging
|
|
|
|
import subprocess
|
2018-06-29 21:08:58 +00:00
|
|
|
import unittest
|
|
|
|
from collections import namedtuple
|
|
|
|
from concurrent import futures
|
2019-01-31 22:27:53 +00:00
|
|
|
from inspect import signature
|
2018-06-29 21:08:58 +00:00
|
|
|
from os import path
|
2023-07-17 12:18:54 +00:00
|
|
|
|
2018-06-29 21:08:58 +00:00
|
|
|
import grpc
|
2018-11-09 22:27:10 +00:00
|
|
|
from google.protobuf import empty_pb2, struct_pb2
|
2023-07-17 12:18:54 +00:00
|
|
|
from pulumi.runtime import proto, rpc
|
|
|
|
from pulumi.runtime.proto import (engine_pb2, engine_pb2_grpc,
|
|
|
|
language_pb2_grpc, provider_pb2,
|
|
|
|
resource_pb2_grpc)
|
2018-06-29 21:08:58 +00:00
|
|
|
|
2018-06-29 23:10:01 +00:00
|
|
|
# gRPC by default logs exceptions to the root `logging` logger. We don't
|
|
|
|
# want this because it spews garbage to stderr and messes up our beautiful
|
2018-10-26 18:05:45 +00:00
|
|
|
# test output. Just turn it off.
|
|
|
|
logging.disable(level=logging.CRITICAL)
|
|
|
|
|
2020-04-21 18:08:22 +00:00
|
|
|
# _MAX_RPC_MESSAGE_SIZE raises the gRPC Max Message size from `4194304` (4mb) to `419430400` (400mb)
|
|
|
|
_MAX_RPC_MESSAGE_SIZE = 1024 * 1024 * 400
|
|
|
|
_GRPC_CHANNEL_OPTIONS = [('grpc.max_receive_message_length', _MAX_RPC_MESSAGE_SIZE)]
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
class LanghostMockResourceMonitor(proto.ResourceMonitorServicer):
|
|
|
|
"""
|
|
|
|
Implementation of proto.ResourceMonitorServicer for use in tests. Tests themselves
|
|
|
|
should not have to interact with this class.
|
|
|
|
|
|
|
|
This class encapsulates all gRPC details so that test authors only have to override
|
|
|
|
the `invoke`, `read_resource`, `register_resource`, and `register_resource_outputs`
|
|
|
|
functions on `LanghostTest` in order to get custom behavior.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def __init__(self, langhost_test, dryrun):
|
|
|
|
self.reg_count = 0
|
|
|
|
self.registrations = {}
|
|
|
|
self.dryrun = dryrun
|
|
|
|
self.langhost_test = langhost_test
|
|
|
|
|
|
|
|
def Invoke(self, request, context):
|
2018-10-31 20:35:31 +00:00
|
|
|
args = rpc.deserialize_properties(request.args)
|
2019-04-23 18:02:51 +00:00
|
|
|
failures, ret = self.langhost_test.invoke(context, request.tok, args, request.provider, request.version)
|
2018-11-09 22:27:10 +00:00
|
|
|
failures_rpc = list(map(
|
|
|
|
lambda fail: provider_pb2.CheckFailure(property=fail["property"], reason=fail["reason"]), failures))
|
|
|
|
|
|
|
|
loop = asyncio.new_event_loop()
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
ret_proto = loop.run_until_complete(rpc.serialize_properties(ret, {}))
|
2018-11-09 22:27:10 +00:00
|
|
|
loop.close()
|
|
|
|
fields = {"failures": failures_rpc, "return": ret_proto}
|
|
|
|
return proto.InvokeResponse(**fields)
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
def ReadResource(self, request, context):
|
|
|
|
type_ = request.type
|
|
|
|
name = request.name
|
|
|
|
id_ = request.id
|
|
|
|
parent = request.parent
|
2018-10-31 20:35:31 +00:00
|
|
|
state = rpc.deserialize_properties(request.properties)
|
2019-05-30 18:04:47 +00:00
|
|
|
dependencies = sorted(list(request.dependencies))
|
|
|
|
provider = request.provider
|
|
|
|
version = request.version
|
2018-06-29 21:08:58 +00:00
|
|
|
outs = self.langhost_test.read_resource(context, type_, name, id_,
|
2019-05-30 18:04:47 +00:00
|
|
|
parent, state, dependencies, provider, version)
|
2018-10-26 18:05:45 +00:00
|
|
|
if "properties" in outs:
|
2018-10-31 20:35:31 +00:00
|
|
|
loop = asyncio.new_event_loop()
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
props_proto = loop.run_until_complete(rpc.serialize_properties(outs["properties"], {}))
|
2018-10-31 20:35:31 +00:00
|
|
|
loop.close()
|
2018-06-29 21:08:58 +00:00
|
|
|
else:
|
|
|
|
props_proto = None
|
|
|
|
return proto.ReadResourceResponse(
|
|
|
|
urn=outs.get("urn"), properties=props_proto)
|
|
|
|
|
|
|
|
def RegisterResource(self, request, context):
|
|
|
|
type_ = request.type
|
|
|
|
name = request.name
|
2018-10-31 20:35:31 +00:00
|
|
|
props = rpc.deserialize_properties(request.object)
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
deps = sorted(list(request.dependencies))
|
Implement first-class providers for Python (#2335)
* Implement first-class providers for Python
First-class providers are an explicit projection of providers themselves
into Pulumi programs. For the most post, providers are just regular
resources, but the addition of providers to the fray (and the ability of
resources to be constructed by providers in the same program) requires
some changes to the Python resource model.
A summary of the changes:
1. Added ProviderResource, a custom resource that is the base class of
all providers.
2. ResourceOptions now has 'provider' and 'providers' fields.
'provider', when passed to a custom resource, allows users to override
the provider that is used to construct a resource to an instance of a
ProviderResource. 'providers', when passed to a component resource,
allows users to override providers used to construct children of the
component resource.
3. 'protect', 'providers', and 'provider' are all now inherited from
a resource's parent if they aren't specified in the child.
This commit adds the requisite code for the above changes and, in
addition, adds a number of new tests that exercise them and related code
paths.
* Rebase against master
2019-01-04 23:44:27 +00:00
|
|
|
parent = request.parent
|
|
|
|
custom = request.custom
|
|
|
|
protect = request.protect
|
|
|
|
provider = request.provider
|
2019-01-31 22:27:53 +00:00
|
|
|
delete_before_replace = request.deleteBeforeReplace
|
2019-04-22 20:54:48 +00:00
|
|
|
ignore_changes = sorted(list(request.ignoreChanges))
|
2019-04-23 18:02:51 +00:00
|
|
|
version = request.version
|
2019-07-12 18:12:01 +00:00
|
|
|
import_ = request.importId
|
2021-07-01 19:32:08 +00:00
|
|
|
replace_on_changes = sorted(list(request.replaceOnChanges))
|
2023-06-26 07:19:04 +00:00
|
|
|
providers = request.providers
|
2023-07-10 17:59:15 +00:00
|
|
|
source_position = request.sourcePosition
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
|
|
|
|
property_dependencies = {}
|
|
|
|
for key, value in request.propertyDependencies.items():
|
|
|
|
property_dependencies[key] = sorted(list(value.urns))
|
|
|
|
|
2018-06-29 21:08:58 +00:00
|
|
|
if type_ != "pulumi:pulumi:Stack":
|
2021-07-01 19:32:08 +00:00
|
|
|
outs = self.langhost_test.register_resource(
|
|
|
|
context, self.dryrun, type_, name, props, deps, parent, custom, protect, provider,
|
|
|
|
property_dependencies, delete_before_replace, ignore_changes, version, import_, replace_on_changes,
|
2023-07-10 17:59:15 +00:00
|
|
|
providers, source_position,
|
2021-07-01 19:32:08 +00:00
|
|
|
)
|
2018-06-29 21:08:58 +00:00
|
|
|
if outs.get("urn"):
|
|
|
|
urn = outs["urn"]
|
|
|
|
self.registrations[urn] = {
|
|
|
|
"type": type_,
|
|
|
|
"name": name,
|
|
|
|
"props": props
|
|
|
|
}
|
|
|
|
|
|
|
|
self.reg_count += 1
|
2018-11-12 17:26:31 +00:00
|
|
|
else:
|
|
|
|
# Record the Stack's registration so that it can be the target of register_resource_outputs
|
|
|
|
# later on.
|
|
|
|
urn = self.langhost_test.make_urn(type_, "teststack")
|
|
|
|
self.registrations[urn] = {
|
|
|
|
"type": type_,
|
|
|
|
"name": "somestack",
|
|
|
|
"props": {}
|
|
|
|
}
|
|
|
|
|
|
|
|
return proto.RegisterResourceResponse(urn=urn, id="teststack", object=None)
|
2018-10-26 18:05:45 +00:00
|
|
|
if "object" in outs:
|
2018-10-31 20:35:31 +00:00
|
|
|
loop = asyncio.new_event_loop()
|
Implement more precise delete-before-replace semantics. (#2369)
This implements the new algorithm for deciding which resources must be
deleted due to a delete-before-replace operation.
We need to compute the set of resources that may be replaced by a
change to the resource under consideration. We do this by taking the
complete set of transitive dependents on the resource under
consideration and removing any resources that would not be replaced by
changes to their dependencies. We determine whether or not a resource
may be replaced by substituting unknowns for input properties that may
change due to deletion of the resources their value depends on and
calling the resource provider's Diff method.
This is perhaps clearer when described by example. Consider the
following dependency graph:
A
__|__
B C
| _|_
D E F
In this graph, all of B, C, D, E, and F transitively depend on A. It may
be the case, however, that changes to the specific properties of any of
those resources R that would occur if a resource on the path to A were
deleted and recreated may not cause R to be replaced. For example, the
edge from B to A may be a simple dependsOn edge such that a change to
B does not actually influence any of B's input properties. In that case,
neither B nor D would need to be deleted before A could be deleted.
In order to make the above algorithm a reality, the resource monitor
interface has been updated to include a map that associates an input
property key with the list of resources that input property depends on.
Older clients of the resource monitor will leave this map empty, in
which case all input properties will be treated as depending on all
dependencies of the resource. This is probably overly conservative, but
it is less conservative than what we currently implement, and is
certainly correct.
2019-01-28 17:46:30 +00:00
|
|
|
obj_proto = loop.run_until_complete(rpc.serialize_properties(outs["object"], {}))
|
2018-10-31 20:35:31 +00:00
|
|
|
loop.close()
|
2018-06-29 21:08:58 +00:00
|
|
|
else:
|
|
|
|
obj_proto = None
|
2021-10-02 16:06:11 +00:00
|
|
|
|
|
|
|
output_property_dependencies = None
|
|
|
|
if "propertyDependencies" in outs:
|
|
|
|
output_property_dependencies = {}
|
|
|
|
for key, urns in outs["propertyDependencies"].items():
|
|
|
|
output_property_dependencies[key] = proto.RegisterResourceResponse.PropertyDependencies(urns=urns)
|
|
|
|
|
2018-06-29 21:08:58 +00:00
|
|
|
return proto.RegisterResourceResponse(
|
2021-10-02 16:06:11 +00:00
|
|
|
urn=outs.get("urn"), id=outs.get("id"), object=obj_proto, propertyDependencies=output_property_dependencies)
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
def RegisterResourceOutputs(self, request, context):
|
|
|
|
urn = request.urn
|
2018-10-31 20:35:31 +00:00
|
|
|
outs = rpc.deserialize_properties(request.outputs)
|
2018-06-29 21:08:58 +00:00
|
|
|
res = self.registrations.get(urn)
|
|
|
|
if res:
|
|
|
|
self.langhost_test.register_resource_outputs(
|
2018-11-12 17:26:31 +00:00
|
|
|
context, self.dryrun, urn, res["type"], res["name"], res["props"], outs)
|
2018-10-31 20:35:31 +00:00
|
|
|
return empty_pb2.Empty()
|
|
|
|
|
|
|
|
|
|
|
|
class MockEngine(proto.EngineServicer):
|
2023-07-17 12:18:54 +00:00
|
|
|
|
|
|
|
def __init__(self):
|
|
|
|
self.messages = []
|
|
|
|
|
2018-10-31 20:35:31 +00:00
|
|
|
"""
|
|
|
|
Implementation of the proto.EngineServicer protocol for use in tests. Like the
|
|
|
|
above class, we encapsulate all gRPC details here so that test writers only have
|
|
|
|
to override methods on LanghostTest.
|
|
|
|
"""
|
|
|
|
def Log(self, request, context):
|
2023-07-17 12:18:54 +00:00
|
|
|
self.messages.append(request.message)
|
2018-10-31 20:35:31 +00:00
|
|
|
if request.severity == engine_pb2.ERROR:
|
|
|
|
print(f"error: {request.message}")
|
|
|
|
return empty_pb2.Empty()
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
|
|
|
|
ResourceMonitorEndpoint = namedtuple('ResourceMonitorEndpoint',
|
2023-07-17 12:18:54 +00:00
|
|
|
['engine', 'monitor', 'server', 'port'])
|
2019-06-06 20:49:04 +00:00
|
|
|
LanguageHostEndpoint = namedtuple('LanguageHostEndpoint', ['process', 'port'])
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
|
|
|
|
class LanghostTest(unittest.TestCase):
|
|
|
|
"""
|
|
|
|
Base class of all end-to-end tests of the Python language host.
|
|
|
|
|
|
|
|
The `run_test` method on this class executes a test by mocking the
|
|
|
|
Pulumi Engine gRPC endpoint and running the language host exactly the same
|
|
|
|
way that the Pulumi CLI will. Once the program completes and the language host
|
|
|
|
exits, `run_test` will assert the expected errors and/or resource registration
|
|
|
|
counts specified by the individual test.
|
|
|
|
|
|
|
|
Check out README.md in this directory for more details.
|
|
|
|
"""
|
|
|
|
|
|
|
|
def run_test(self,
|
|
|
|
project=None,
|
|
|
|
stack=None,
|
|
|
|
program=None,
|
|
|
|
args=None,
|
|
|
|
config=None,
|
|
|
|
expected_resource_count=None,
|
2018-06-29 23:10:01 +00:00
|
|
|
expected_error=None,
|
2022-08-11 17:38:34 +00:00
|
|
|
expected_stderr_contains=None,
|
2022-08-31 09:33:29 +00:00
|
|
|
expected_bail=None,
|
2023-07-17 12:18:54 +00:00
|
|
|
expected_log_message=None,
|
2022-08-31 09:33:29 +00:00
|
|
|
organization=None):
|
2018-06-29 21:08:58 +00:00
|
|
|
"""
|
|
|
|
Runs a language host test. The basic flow of a language host test is that
|
|
|
|
a test is launched using the real language host while mocking out the resource
|
|
|
|
monitor RPC interface and, once the program completes, assertions are made about
|
|
|
|
the sorts of resource monitor calls that were made.
|
|
|
|
|
|
|
|
:param project: The name of the project in which the program will run.
|
|
|
|
:param stack: The name of the stack in which the program will run.
|
|
|
|
:param program: The path to the program the langhost should execute.
|
|
|
|
:param args: Arguments to the program.
|
|
|
|
:param config: Configuration keys for the program.
|
|
|
|
:param expected_resource_count: The number of resources this program is expected to create.
|
|
|
|
:param expected_error: If present, the expected error that should arise when running this program.
|
2018-06-29 23:10:01 +00:00
|
|
|
:param expected_stderr_contains: If present, the standard error of the process should contain this string
|
2018-06-29 21:08:58 +00:00
|
|
|
"""
|
|
|
|
# For each test case, we'll do a preview followed by an update.
|
|
|
|
for dryrun in [True, False]:
|
|
|
|
# For these tests, we are the resource monitor. The `invoke`, `read_resource`,
|
|
|
|
# `register_resource`, and `register_resource_outputs` methods on this class
|
|
|
|
# will be used to implement the resource monitor gRPC interface. The tests
|
|
|
|
# that we spawn will connect to us directly.
|
|
|
|
monitor = self._create_mock_resource_monitor(dryrun)
|
|
|
|
|
|
|
|
# Now we'll launch the language host, which will in turn launch code that drives
|
|
|
|
# the test.
|
2019-06-06 20:49:04 +00:00
|
|
|
langhost = self._create_language_host(monitor.port)
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
# Run the program with the langhost we just launched.
|
2020-04-21 18:08:22 +00:00
|
|
|
with grpc.insecure_channel("localhost:%d" % langhost.port, options=_GRPC_CHANNEL_OPTIONS) as channel:
|
2019-06-06 20:49:04 +00:00
|
|
|
grpc.channel_ready_future(channel).result()
|
2018-06-29 21:08:58 +00:00
|
|
|
stub = language_pb2_grpc.LanguageRuntimeStub(channel)
|
|
|
|
result = self._run_program(stub, monitor, project, stack,
|
Pass root and main info to language host methods (#14654)
<!---
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 is two changes rolled together in a way.
Firstly passing some of the data that we pass on language runtime
startup to also pass it to Run/GetRequiredPlugins/etc. This is needed
for matrix testing, as we only get to start the language runtime up once
for that but want to execute multiple programs with it.
I feel it's also a little more consistent as we use the language
runtimes in other contexts (codegen) where there isn't really a root
directory, and aren't any options (and if we did do options the options
for codegen are not going to be the same as for execution). It also
means we can reuse a language host for shimless and substack programs,
as before they heavily relied on their current working directory to
calculate paths, and obviosly could only take one set of options at
startup. Imagine a shimless python package + a python root program, that
would have needed two startups of the python language host to deal with,
this unblocks it so we can make the engine smarter and only use one.
Secondly renaming some of the fields we pass to
Run/GetRequiredPlugins/etc today. `Pwd` and `Program` were not very
descriptive and had pretty non-obvious documentation:
```
string pwd = 3; // the program's working directory.
string program = 4; // the path to the program to execute.
```
`pwd` will remain, although probably rename it to `working_directory` at
some point, because while today we always start programs up with the
working directory equal to the program directory that definitely is
going to change in the future (at least for MLCs and substack programs).
But the name `pwd` doesn't make it clear that this was intended to be
the working directory _and_ the directory which contains the program.
`program` was in fact nearly always ".", and if it wasn't that it was
just a filename. The engine never sent a path for `program` (although we
did have some unit tests to check how that worked for the nodejs and
python hosts).
These are now replaced by a new structure with (I think) more clearly
named and documented fields (see ProgramInfo in langauge.proto).
The engine still sends the old data for now, we need to update
dotnet/yaml/java before we break the old interface and give Virtus Labs
a chance to update [besom](https://github.com/VirtusLab/besom).
## 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. -->
2023-12-10 17:30:51 +00:00
|
|
|
program, args, config, dryrun, organization)
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
# Tear down the language host process we just spun up.
|
|
|
|
langhost.process.kill()
|
|
|
|
stdout, stderr = langhost.process.communicate()
|
2023-07-17 12:18:54 +00:00
|
|
|
monitor.server.stop(0)
|
2018-06-29 23:10:01 +00:00
|
|
|
if not expected_stderr_contains and (stdout or stderr):
|
2018-06-29 21:08:58 +00:00
|
|
|
print("PREVIEW:" if dryrun else "UPDATE:")
|
2023-07-17 12:18:54 +00:00
|
|
|
print("stdout:", stdout)
|
|
|
|
print("stderr:", stderr)
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
# If we expected an error, assert that we saw it. Otherwise assert
|
|
|
|
# that there wasn't an error.
|
|
|
|
expected = expected_error or ""
|
2022-08-11 17:38:34 +00:00
|
|
|
self.assertEqual(result.error, expected)
|
|
|
|
|
|
|
|
expected_bail = expected_bail or False
|
|
|
|
self.assertEqual(result.bail, expected_bail)
|
2018-06-29 21:08:58 +00:00
|
|
|
|
2023-07-17 12:18:54 +00:00
|
|
|
if expected_log_message:
|
|
|
|
for message in monitor.engine.messages:
|
|
|
|
if expected_log_message in message:
|
|
|
|
break
|
|
|
|
else:
|
|
|
|
print("log messages:", monitor.engine.messages)
|
|
|
|
self.fail("expected log message '" + expected_log_message + "'")
|
|
|
|
|
2018-06-29 23:10:01 +00:00
|
|
|
if expected_stderr_contains:
|
2018-10-26 18:05:45 +00:00
|
|
|
if expected_stderr_contains not in str(stderr):
|
|
|
|
print("stderr:", str(stderr))
|
2018-06-29 23:10:01 +00:00
|
|
|
self.fail("expected stderr to contain '" + expected_stderr_contains + "'")
|
|
|
|
|
2018-06-29 21:08:58 +00:00
|
|
|
if expected_resource_count is not None:
|
|
|
|
self.assertEqual(expected_resource_count,
|
|
|
|
monitor.monitor.reg_count)
|
|
|
|
|
2021-07-01 19:32:08 +00:00
|
|
|
def invoke(self, _ctx, token, args, provider, _version):
|
2018-06-29 21:08:58 +00:00
|
|
|
"""
|
|
|
|
Method corresponding to the `Invoke` resource monitor RPC call.
|
|
|
|
Override for custom behavior or assertions.
|
|
|
|
|
|
|
|
Returns a tuple of a list of errors that returned and the returned
|
|
|
|
object, if the call was successful.
|
|
|
|
"""
|
|
|
|
return ([], {})
|
|
|
|
|
2021-07-01 19:32:08 +00:00
|
|
|
def read_resource(self, ctx, ty, name, _id, parent, state, dependencies, provider, version):
|
2018-06-29 21:08:58 +00:00
|
|
|
"""
|
|
|
|
Method corresponding to the `ReadResource` resource monitor RPC call.
|
|
|
|
Override for custom behavior or assertions.
|
|
|
|
|
|
|
|
Returns a resource that was read from existing state.
|
|
|
|
"""
|
|
|
|
return {}
|
|
|
|
|
2021-07-01 19:32:08 +00:00
|
|
|
def register_resource(self, _ctx, _dry_run, ty, name, _resource, _dependencies, _parent, _custom, protect,
|
|
|
|
_provider, _property_deps, _delete_before_replace, _ignore_changes, _version, _import,
|
2023-07-10 17:59:15 +00:00
|
|
|
_replace_on_changes, _providers, source_position):
|
2018-06-29 21:08:58 +00:00
|
|
|
"""
|
|
|
|
Method corresponding to the `RegisterResource` resource monitor RPC call.
|
|
|
|
Override for custom behavior or assertions.
|
|
|
|
|
|
|
|
Returns a resource that was just created.
|
|
|
|
"""
|
|
|
|
return {}
|
|
|
|
|
|
|
|
def register_resource_outputs(self, _ctx, _dry_run, _urn, _type, _name,
|
|
|
|
_resource, _outputs):
|
|
|
|
"""
|
|
|
|
Method corresponding to the `RegisterResourceOutputs` resource monitor RPC call.
|
|
|
|
Override for custom behavior or assertirons.
|
|
|
|
|
|
|
|
Returns None.
|
|
|
|
"""
|
|
|
|
pass
|
|
|
|
|
|
|
|
def make_urn(self, type_, name):
|
|
|
|
"""
|
|
|
|
Makes an URN from a given resource type and name.
|
|
|
|
"""
|
|
|
|
return "%s::%s" % (type_, name)
|
|
|
|
|
|
|
|
def base_path(self):
|
|
|
|
"""
|
|
|
|
Returns the base path for language host tests.
|
|
|
|
"""
|
|
|
|
return path.dirname(__file__)
|
|
|
|
|
|
|
|
def _create_mock_resource_monitor(self, dryrun):
|
|
|
|
monitor = LanghostMockResourceMonitor(self, dryrun)
|
2018-10-31 20:35:31 +00:00
|
|
|
engine = MockEngine()
|
2020-04-21 18:08:22 +00:00
|
|
|
server = grpc.server(futures.ThreadPoolExecutor(max_workers=4), options=_GRPC_CHANNEL_OPTIONS)
|
2019-06-06 20:49:04 +00:00
|
|
|
|
|
|
|
resource_pb2_grpc.add_ResourceMonitorServicer_to_server(monitor, server)
|
2018-10-31 20:35:31 +00:00
|
|
|
engine_pb2_grpc.add_EngineServicer_to_server(engine, server)
|
2019-06-06 20:49:04 +00:00
|
|
|
|
2022-08-25 22:40:00 +00:00
|
|
|
port = server.add_insecure_port(address="127.0.0.1:0")
|
2018-06-29 21:08:58 +00:00
|
|
|
server.start()
|
2023-07-17 12:18:54 +00:00
|
|
|
return ResourceMonitorEndpoint(engine, monitor, server, port)
|
2018-06-29 21:08:58 +00:00
|
|
|
|
2019-06-06 20:49:04 +00:00
|
|
|
def _create_language_host(self, port):
|
2018-06-29 21:08:58 +00:00
|
|
|
exec_path = path.join(path.dirname(__file__), "..", "..", "..", "cmd", "pulumi-language-python-exec")
|
|
|
|
proc = subprocess.Popen(
|
2019-06-06 20:49:04 +00:00
|
|
|
["pulumi-language-python", "--use-executor", exec_path, "localhost:%d" % port],
|
2018-06-29 21:08:58 +00:00
|
|
|
stdout=subprocess.PIPE,
|
2023-07-17 12:18:54 +00:00
|
|
|
stderr=subprocess.PIPE,
|
|
|
|
text=True)
|
2018-06-29 21:08:58 +00:00
|
|
|
# The first line of output is the port that the language host gRPC server is listening on.
|
|
|
|
first_line = proc.stdout.readline()
|
|
|
|
try:
|
2019-06-06 20:49:04 +00:00
|
|
|
return LanguageHostEndpoint(proc, int(first_line))
|
2018-06-29 21:08:58 +00:00
|
|
|
except ValueError:
|
|
|
|
proc.kill()
|
|
|
|
stdout, stderr = proc.communicate()
|
|
|
|
print("language host did not respond with port")
|
|
|
|
print("stdout: ")
|
|
|
|
print(stdout)
|
|
|
|
print("stderr: ")
|
|
|
|
print(stderr)
|
|
|
|
raise
|
|
|
|
|
Pass root and main info to language host methods (#14654)
<!---
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 is two changes rolled together in a way.
Firstly passing some of the data that we pass on language runtime
startup to also pass it to Run/GetRequiredPlugins/etc. This is needed
for matrix testing, as we only get to start the language runtime up once
for that but want to execute multiple programs with it.
I feel it's also a little more consistent as we use the language
runtimes in other contexts (codegen) where there isn't really a root
directory, and aren't any options (and if we did do options the options
for codegen are not going to be the same as for execution). It also
means we can reuse a language host for shimless and substack programs,
as before they heavily relied on their current working directory to
calculate paths, and obviosly could only take one set of options at
startup. Imagine a shimless python package + a python root program, that
would have needed two startups of the python language host to deal with,
this unblocks it so we can make the engine smarter and only use one.
Secondly renaming some of the fields we pass to
Run/GetRequiredPlugins/etc today. `Pwd` and `Program` were not very
descriptive and had pretty non-obvious documentation:
```
string pwd = 3; // the program's working directory.
string program = 4; // the path to the program to execute.
```
`pwd` will remain, although probably rename it to `working_directory` at
some point, because while today we always start programs up with the
working directory equal to the program directory that definitely is
going to change in the future (at least for MLCs and substack programs).
But the name `pwd` doesn't make it clear that this was intended to be
the working directory _and_ the directory which contains the program.
`program` was in fact nearly always ".", and if it wasn't that it was
just a filename. The engine never sent a path for `program` (although we
did have some unit tests to check how that worked for the nodejs and
python hosts).
These are now replaced by a new structure with (I think) more clearly
named and documented fields (see ProgramInfo in langauge.proto).
The engine still sends the old data for now, we need to update
dotnet/yaml/java before we break the old interface and give Virtus Labs
a chance to update [besom](https://github.com/VirtusLab/besom).
## 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. -->
2023-12-10 17:30:51 +00:00
|
|
|
def _run_program(self, stub, monitor, project, stack, program, args,
|
2022-08-31 09:33:29 +00:00
|
|
|
config, dryrun, organization):
|
Pass root and main info to language host methods (#14654)
<!---
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 is two changes rolled together in a way.
Firstly passing some of the data that we pass on language runtime
startup to also pass it to Run/GetRequiredPlugins/etc. This is needed
for matrix testing, as we only get to start the language runtime up once
for that but want to execute multiple programs with it.
I feel it's also a little more consistent as we use the language
runtimes in other contexts (codegen) where there isn't really a root
directory, and aren't any options (and if we did do options the options
for codegen are not going to be the same as for execution). It also
means we can reuse a language host for shimless and substack programs,
as before they heavily relied on their current working directory to
calculate paths, and obviosly could only take one set of options at
startup. Imagine a shimless python package + a python root program, that
would have needed two startups of the python language host to deal with,
this unblocks it so we can make the engine smarter and only use one.
Secondly renaming some of the fields we pass to
Run/GetRequiredPlugins/etc today. `Pwd` and `Program` were not very
descriptive and had pretty non-obvious documentation:
```
string pwd = 3; // the program's working directory.
string program = 4; // the path to the program to execute.
```
`pwd` will remain, although probably rename it to `working_directory` at
some point, because while today we always start programs up with the
working directory equal to the program directory that definitely is
going to change in the future (at least for MLCs and substack programs).
But the name `pwd` doesn't make it clear that this was intended to be
the working directory _and_ the directory which contains the program.
`program` was in fact nearly always ".", and if it wasn't that it was
just a filename. The engine never sent a path for `program` (although we
did have some unit tests to check how that worked for the nodejs and
python hosts).
These are now replaced by a new structure with (I think) more clearly
named and documented fields (see ProgramInfo in langauge.proto).
The engine still sends the old data for now, we need to update
dotnet/yaml/java before we break the old interface and give Virtus Labs
a chance to update [besom](https://github.com/VirtusLab/besom).
## 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. -->
2023-12-10 17:30:51 +00:00
|
|
|
|
2018-06-29 21:08:58 +00:00
|
|
|
args = {}
|
Pass root and main info to language host methods (#14654)
<!---
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 is two changes rolled together in a way.
Firstly passing some of the data that we pass on language runtime
startup to also pass it to Run/GetRequiredPlugins/etc. This is needed
for matrix testing, as we only get to start the language runtime up once
for that but want to execute multiple programs with it.
I feel it's also a little more consistent as we use the language
runtimes in other contexts (codegen) where there isn't really a root
directory, and aren't any options (and if we did do options the options
for codegen are not going to be the same as for execution). It also
means we can reuse a language host for shimless and substack programs,
as before they heavily relied on their current working directory to
calculate paths, and obviosly could only take one set of options at
startup. Imagine a shimless python package + a python root program, that
would have needed two startups of the python language host to deal with,
this unblocks it so we can make the engine smarter and only use one.
Secondly renaming some of the fields we pass to
Run/GetRequiredPlugins/etc today. `Pwd` and `Program` were not very
descriptive and had pretty non-obvious documentation:
```
string pwd = 3; // the program's working directory.
string program = 4; // the path to the program to execute.
```
`pwd` will remain, although probably rename it to `working_directory` at
some point, because while today we always start programs up with the
working directory equal to the program directory that definitely is
going to change in the future (at least for MLCs and substack programs).
But the name `pwd` doesn't make it clear that this was intended to be
the working directory _and_ the directory which contains the program.
`program` was in fact nearly always ".", and if it wasn't that it was
just a filename. The engine never sent a path for `program` (although we
did have some unit tests to check how that worked for the nodejs and
python hosts).
These are now replaced by a new structure with (I think) more clearly
named and documented fields (see ProgramInfo in langauge.proto).
The engine still sends the old data for now, we need to update
dotnet/yaml/java before we break the old interface and give Virtus Labs
a chance to update [besom](https://github.com/VirtusLab/besom).
## 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. -->
2023-12-10 17:30:51 +00:00
|
|
|
|
|
|
|
# Assume program is the path to the project, i.e. root, program directory, and pwd.
|
|
|
|
args["info"] = proto.ProgramInfo(root_directory=program, program_directory=program, entry_point=".")
|
|
|
|
|
2019-06-06 20:49:04 +00:00
|
|
|
args["monitor_address"] = "localhost:%d" % monitor.port
|
2018-06-29 21:08:58 +00:00
|
|
|
args["project"] = project or "project"
|
|
|
|
args["stack"] = stack or "stack"
|
Pass root and main info to language host methods (#14654)
<!---
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 is two changes rolled together in a way.
Firstly passing some of the data that we pass on language runtime
startup to also pass it to Run/GetRequiredPlugins/etc. This is needed
for matrix testing, as we only get to start the language runtime up once
for that but want to execute multiple programs with it.
I feel it's also a little more consistent as we use the language
runtimes in other contexts (codegen) where there isn't really a root
directory, and aren't any options (and if we did do options the options
for codegen are not going to be the same as for execution). It also
means we can reuse a language host for shimless and substack programs,
as before they heavily relied on their current working directory to
calculate paths, and obviosly could only take one set of options at
startup. Imagine a shimless python package + a python root program, that
would have needed two startups of the python language host to deal with,
this unblocks it so we can make the engine smarter and only use one.
Secondly renaming some of the fields we pass to
Run/GetRequiredPlugins/etc today. `Pwd` and `Program` were not very
descriptive and had pretty non-obvious documentation:
```
string pwd = 3; // the program's working directory.
string program = 4; // the path to the program to execute.
```
`pwd` will remain, although probably rename it to `working_directory` at
some point, because while today we always start programs up with the
working directory equal to the program directory that definitely is
going to change in the future (at least for MLCs and substack programs).
But the name `pwd` doesn't make it clear that this was intended to be
the working directory _and_ the directory which contains the program.
`program` was in fact nearly always ".", and if it wasn't that it was
just a filename. The engine never sent a path for `program` (although we
did have some unit tests to check how that worked for the nodejs and
python hosts).
These are now replaced by a new structure with (I think) more clearly
named and documented fields (see ProgramInfo in langauge.proto).
The engine still sends the old data for now, we need to update
dotnet/yaml/java before we break the old interface and give Virtus Labs
a chance to update [besom](https://github.com/VirtusLab/besom).
## 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. -->
2023-12-10 17:30:51 +00:00
|
|
|
args["program"] = "."
|
2022-08-31 09:33:29 +00:00
|
|
|
args["organization"] = organization
|
Pass root and main info to language host methods (#14654)
<!---
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 is two changes rolled together in a way.
Firstly passing some of the data that we pass on language runtime
startup to also pass it to Run/GetRequiredPlugins/etc. This is needed
for matrix testing, as we only get to start the language runtime up once
for that but want to execute multiple programs with it.
I feel it's also a little more consistent as we use the language
runtimes in other contexts (codegen) where there isn't really a root
directory, and aren't any options (and if we did do options the options
for codegen are not going to be the same as for execution). It also
means we can reuse a language host for shimless and substack programs,
as before they heavily relied on their current working directory to
calculate paths, and obviosly could only take one set of options at
startup. Imagine a shimless python package + a python root program, that
would have needed two startups of the python language host to deal with,
this unblocks it so we can make the engine smarter and only use one.
Secondly renaming some of the fields we pass to
Run/GetRequiredPlugins/etc today. `Pwd` and `Program` were not very
descriptive and had pretty non-obvious documentation:
```
string pwd = 3; // the program's working directory.
string program = 4; // the path to the program to execute.
```
`pwd` will remain, although probably rename it to `working_directory` at
some point, because while today we always start programs up with the
working directory equal to the program directory that definitely is
going to change in the future (at least for MLCs and substack programs).
But the name `pwd` doesn't make it clear that this was intended to be
the working directory _and_ the directory which contains the program.
`program` was in fact nearly always ".", and if it wasn't that it was
just a filename. The engine never sent a path for `program` (although we
did have some unit tests to check how that worked for the nodejs and
python hosts).
These are now replaced by a new structure with (I think) more clearly
named and documented fields (see ProgramInfo in langauge.proto).
The engine still sends the old data for now, we need to update
dotnet/yaml/java before we break the old interface and give Virtus Labs
a chance to update [besom](https://github.com/VirtusLab/besom).
## 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. -->
2023-12-10 17:30:51 +00:00
|
|
|
args["pwd"] = program
|
2018-06-29 21:08:58 +00:00
|
|
|
|
|
|
|
if args:
|
|
|
|
args["args"] = args
|
|
|
|
|
|
|
|
if config:
|
|
|
|
args["config"] = config
|
|
|
|
|
Pass root and main info to language host methods (#14654)
<!---
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 is two changes rolled together in a way.
Firstly passing some of the data that we pass on language runtime
startup to also pass it to Run/GetRequiredPlugins/etc. This is needed
for matrix testing, as we only get to start the language runtime up once
for that but want to execute multiple programs with it.
I feel it's also a little more consistent as we use the language
runtimes in other contexts (codegen) where there isn't really a root
directory, and aren't any options (and if we did do options the options
for codegen are not going to be the same as for execution). It also
means we can reuse a language host for shimless and substack programs,
as before they heavily relied on their current working directory to
calculate paths, and obviosly could only take one set of options at
startup. Imagine a shimless python package + a python root program, that
would have needed two startups of the python language host to deal with,
this unblocks it so we can make the engine smarter and only use one.
Secondly renaming some of the fields we pass to
Run/GetRequiredPlugins/etc today. `Pwd` and `Program` were not very
descriptive and had pretty non-obvious documentation:
```
string pwd = 3; // the program's working directory.
string program = 4; // the path to the program to execute.
```
`pwd` will remain, although probably rename it to `working_directory` at
some point, because while today we always start programs up with the
working directory equal to the program directory that definitely is
going to change in the future (at least for MLCs and substack programs).
But the name `pwd` doesn't make it clear that this was intended to be
the working directory _and_ the directory which contains the program.
`program` was in fact nearly always ".", and if it wasn't that it was
just a filename. The engine never sent a path for `program` (although we
did have some unit tests to check how that worked for the nodejs and
python hosts).
These are now replaced by a new structure with (I think) more clearly
named and documented fields (see ProgramInfo in langauge.proto).
The engine still sends the old data for now, we need to update
dotnet/yaml/java before we break the old interface and give Virtus Labs
a chance to update [besom](https://github.com/VirtusLab/besom).
## 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. -->
2023-12-10 17:30:51 +00:00
|
|
|
|
2018-06-29 21:08:58 +00:00
|
|
|
args["dryRun"] = dryrun
|
|
|
|
request = proto.RunRequest(**args)
|
|
|
|
self.assertTrue(request.IsInitialized())
|
|
|
|
resp = stub.Run(request)
|
2022-08-11 17:38:34 +00:00
|
|
|
return resp
|