pulumi/sdk/nodejs/proto/language_grpc_pb.js

441 lines
18 KiB
JavaScript
Raw Permalink Normal View History

Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
// GENERATED CODE -- DO NOT EDIT!
// Original file comments:
// Copyright 2016-2023, 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.
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
//
'use strict';
var grpc = require('@grpc/grpc-js');
var pulumi_language_pb = require('./language_pb.js');
var pulumi_codegen_hcl_pb = require('./codegen/hcl_pb.js');
var pulumi_plugin_pb = require('./plugin_pb.js');
var google_protobuf_empty_pb = require('google-protobuf/google/protobuf/empty_pb.js');
pass through property values to RunRequest (#14273) # Description This is an alternative to https://github.com/pulumi/pulumi/pull/14244. Instead of adding type information to the run request, pass the config through as property values. Property values are properly encoded on the wire, and can be unmarshalled on the other end including type information, so this should be a more future proof way to go forward. Eventually we'll want to parse the config directly into property values, but that can be left for the future, as it's a bigger change. ## 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. --> - [ ] 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. -->
2023-10-20 10:44:16 +00:00
var google_protobuf_struct_pb = require('google-protobuf/google/protobuf/struct_pb.js');
function serialize_google_protobuf_Empty(arg) {
if (!(arg instanceof google_protobuf_empty_pb.Empty)) {
throw new Error('Expected argument of type google.protobuf.Empty');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_google_protobuf_Empty(buffer_arg) {
return google_protobuf_empty_pb.Empty.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_AboutRequest(arg) {
if (!(arg instanceof pulumi_language_pb.AboutRequest)) {
throw new Error('Expected argument of type pulumirpc.AboutRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_AboutRequest(buffer_arg) {
return pulumi_language_pb.AboutRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_AboutResponse(arg) {
if (!(arg instanceof pulumi_language_pb.AboutResponse)) {
throw new Error('Expected argument of type pulumirpc.AboutResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_AboutResponse(buffer_arg) {
return pulumi_language_pb.AboutResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GeneratePackageRequest(arg) {
if (!(arg instanceof pulumi_language_pb.GeneratePackageRequest)) {
throw new Error('Expected argument of type pulumirpc.GeneratePackageRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GeneratePackageRequest(buffer_arg) {
return pulumi_language_pb.GeneratePackageRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GeneratePackageResponse(arg) {
if (!(arg instanceof pulumi_language_pb.GeneratePackageResponse)) {
throw new Error('Expected argument of type pulumirpc.GeneratePackageResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GeneratePackageResponse(buffer_arg) {
return pulumi_language_pb.GeneratePackageResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GenerateProgramRequest(arg) {
if (!(arg instanceof pulumi_language_pb.GenerateProgramRequest)) {
throw new Error('Expected argument of type pulumirpc.GenerateProgramRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GenerateProgramRequest(buffer_arg) {
return pulumi_language_pb.GenerateProgramRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GenerateProgramResponse(arg) {
if (!(arg instanceof pulumi_language_pb.GenerateProgramResponse)) {
throw new Error('Expected argument of type pulumirpc.GenerateProgramResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GenerateProgramResponse(buffer_arg) {
return pulumi_language_pb.GenerateProgramResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GenerateProjectRequest(arg) {
if (!(arg instanceof pulumi_language_pb.GenerateProjectRequest)) {
throw new Error('Expected argument of type pulumirpc.GenerateProjectRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GenerateProjectRequest(buffer_arg) {
return pulumi_language_pb.GenerateProjectRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GenerateProjectResponse(arg) {
if (!(arg instanceof pulumi_language_pb.GenerateProjectResponse)) {
throw new Error('Expected argument of type pulumirpc.GenerateProjectResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GenerateProjectResponse(buffer_arg) {
return pulumi_language_pb.GenerateProjectResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GetProgramDependenciesRequest(arg) {
if (!(arg instanceof pulumi_language_pb.GetProgramDependenciesRequest)) {
throw new Error('Expected argument of type pulumirpc.GetProgramDependenciesRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GetProgramDependenciesRequest(buffer_arg) {
return pulumi_language_pb.GetProgramDependenciesRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GetProgramDependenciesResponse(arg) {
if (!(arg instanceof pulumi_language_pb.GetProgramDependenciesResponse)) {
throw new Error('Expected argument of type pulumirpc.GetProgramDependenciesResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GetProgramDependenciesResponse(buffer_arg) {
return pulumi_language_pb.GetProgramDependenciesResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GetRequiredPluginsRequest(arg) {
if (!(arg instanceof pulumi_language_pb.GetRequiredPluginsRequest)) {
throw new Error('Expected argument of type pulumirpc.GetRequiredPluginsRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GetRequiredPluginsRequest(buffer_arg) {
return pulumi_language_pb.GetRequiredPluginsRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_GetRequiredPluginsResponse(arg) {
if (!(arg instanceof pulumi_language_pb.GetRequiredPluginsResponse)) {
throw new Error('Expected argument of type pulumirpc.GetRequiredPluginsResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_GetRequiredPluginsResponse(buffer_arg) {
return pulumi_language_pb.GetRequiredPluginsResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
Move InstallDependencies to the language plugin (#9294) * Move InstallDependencies to the language plugin This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself. This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this. We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli. An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well. The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC. The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given? * Just warn if pty fails to open * Add tests and return real tty files * Add to CHANGELOG * lint * format * Test strings * Log pty opening for trace debugging * s/Hack/Workaround * Use termios * Tweak terminal test * lint * Fix windows build
2022-04-03 14:54:59 +00:00
function serialize_pulumirpc_InstallDependenciesRequest(arg) {
if (!(arg instanceof pulumi_language_pb.InstallDependenciesRequest)) {
Move InstallDependencies to the language plugin (#9294) * Move InstallDependencies to the language plugin This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself. This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this. We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli. An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well. The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC. The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given? * Just warn if pty fails to open * Add tests and return real tty files * Add to CHANGELOG * lint * format * Test strings * Log pty opening for trace debugging * s/Hack/Workaround * Use termios * Tweak terminal test * lint * Fix windows build
2022-04-03 14:54:59 +00:00
throw new Error('Expected argument of type pulumirpc.InstallDependenciesRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_InstallDependenciesRequest(buffer_arg) {
return pulumi_language_pb.InstallDependenciesRequest.deserializeBinary(new Uint8Array(buffer_arg));
Move InstallDependencies to the language plugin (#9294) * Move InstallDependencies to the language plugin This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself. This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this. We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli. An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well. The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC. The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given? * Just warn if pty fails to open * Add tests and return real tty files * Add to CHANGELOG * lint * format * Test strings * Log pty opening for trace debugging * s/Hack/Workaround * Use termios * Tweak terminal test * lint * Fix windows build
2022-04-03 14:54:59 +00:00
}
function serialize_pulumirpc_InstallDependenciesResponse(arg) {
if (!(arg instanceof pulumi_language_pb.InstallDependenciesResponse)) {
Move InstallDependencies to the language plugin (#9294) * Move InstallDependencies to the language plugin This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself. This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this. We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli. An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well. The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC. The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given? * Just warn if pty fails to open * Add tests and return real tty files * Add to CHANGELOG * lint * format * Test strings * Log pty opening for trace debugging * s/Hack/Workaround * Use termios * Tweak terminal test * lint * Fix windows build
2022-04-03 14:54:59 +00:00
throw new Error('Expected argument of type pulumirpc.InstallDependenciesResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_InstallDependenciesResponse(buffer_arg) {
return pulumi_language_pb.InstallDependenciesResponse.deserializeBinary(new Uint8Array(buffer_arg));
Move InstallDependencies to the language plugin (#9294) * Move InstallDependencies to the language plugin This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself. This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this. We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli. An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well. The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC. The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given? * Just warn if pty fails to open * Add tests and return real tty files * Add to CHANGELOG * lint * format * Test strings * Log pty opening for trace debugging * s/Hack/Workaround * Use termios * Tweak terminal test * lint * Fix windows build
2022-04-03 14:54:59 +00:00
}
function serialize_pulumirpc_PackRequest(arg) {
if (!(arg instanceof pulumi_language_pb.PackRequest)) {
throw new Error('Expected argument of type pulumirpc.PackRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_PackRequest(buffer_arg) {
return pulumi_language_pb.PackRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_PackResponse(arg) {
if (!(arg instanceof pulumi_language_pb.PackResponse)) {
throw new Error('Expected argument of type pulumirpc.PackResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_PackResponse(buffer_arg) {
return pulumi_language_pb.PackResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_PluginInfo(arg) {
if (!(arg instanceof pulumi_plugin_pb.PluginInfo)) {
throw new Error('Expected argument of type pulumirpc.PluginInfo');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_PluginInfo(buffer_arg) {
return pulumi_plugin_pb.PluginInfo.deserializeBinary(new Uint8Array(buffer_arg));
}
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
function serialize_pulumirpc_RunPluginRequest(arg) {
if (!(arg instanceof pulumi_language_pb.RunPluginRequest)) {
throw new Error('Expected argument of type pulumirpc.RunPluginRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_RunPluginRequest(buffer_arg) {
return pulumi_language_pb.RunPluginRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_RunPluginResponse(arg) {
if (!(arg instanceof pulumi_language_pb.RunPluginResponse)) {
throw new Error('Expected argument of type pulumirpc.RunPluginResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_RunPluginResponse(buffer_arg) {
return pulumi_language_pb.RunPluginResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
function serialize_pulumirpc_RunRequest(arg) {
if (!(arg instanceof pulumi_language_pb.RunRequest)) {
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
throw new Error('Expected argument of type pulumirpc.RunRequest');
}
return Buffer.from(arg.serializeBinary());
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
function deserialize_pulumirpc_RunRequest(buffer_arg) {
return pulumi_language_pb.RunRequest.deserializeBinary(new Uint8Array(buffer_arg));
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
function serialize_pulumirpc_RunResponse(arg) {
if (!(arg instanceof pulumi_language_pb.RunResponse)) {
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
throw new Error('Expected argument of type pulumirpc.RunResponse');
}
return Buffer.from(arg.serializeBinary());
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
function deserialize_pulumirpc_RunResponse(buffer_arg) {
return pulumi_language_pb.RunResponse.deserializeBinary(new Uint8Array(buffer_arg));
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
}
function serialize_pulumirpc_RuntimeOptionsRequest(arg) {
if (!(arg instanceof pulumi_language_pb.RuntimeOptionsRequest)) {
throw new Error('Expected argument of type pulumirpc.RuntimeOptionsRequest');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_RuntimeOptionsRequest(buffer_arg) {
return pulumi_language_pb.RuntimeOptionsRequest.deserializeBinary(new Uint8Array(buffer_arg));
}
function serialize_pulumirpc_RuntimeOptionsResponse(arg) {
if (!(arg instanceof pulumi_language_pb.RuntimeOptionsResponse)) {
throw new Error('Expected argument of type pulumirpc.RuntimeOptionsResponse');
}
return Buffer.from(arg.serializeBinary());
}
function deserialize_pulumirpc_RuntimeOptionsResponse(buffer_arg) {
return pulumi_language_pb.RuntimeOptionsResponse.deserializeBinary(new Uint8Array(buffer_arg));
}
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
// LanguageRuntime is the interface that the planning monitor uses to drive execution of an interpreter responsible
// for confguring and creating resource objects.
var LanguageRuntimeService = exports.LanguageRuntimeService = {
// GetRequiredPlugins computes the complete set of anticipated plugins required by a program.
2020-02-28 11:53:47 +00:00
getRequiredPlugins: {
path: '/pulumirpc.LanguageRuntime/GetRequiredPlugins',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.GetRequiredPluginsRequest,
responseType: pulumi_language_pb.GetRequiredPluginsResponse,
requestSerialize: serialize_pulumirpc_GetRequiredPluginsRequest,
requestDeserialize: deserialize_pulumirpc_GetRequiredPluginsRequest,
responseSerialize: serialize_pulumirpc_GetRequiredPluginsResponse,
responseDeserialize: deserialize_pulumirpc_GetRequiredPluginsResponse,
},
// Run executes a program and returns its result.
2020-02-28 11:53:47 +00:00
run: {
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
path: '/pulumirpc.LanguageRuntime/Run',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.RunRequest,
responseType: pulumi_language_pb.RunResponse,
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
requestSerialize: serialize_pulumirpc_RunRequest,
requestDeserialize: deserialize_pulumirpc_RunRequest,
responseSerialize: serialize_pulumirpc_RunResponse,
responseDeserialize: deserialize_pulumirpc_RunResponse,
},
// GetPluginInfo returns generic information about this plugin, like its version.
2020-02-28 11:53:47 +00:00
getPluginInfo: {
path: '/pulumirpc.LanguageRuntime/GetPluginInfo',
requestStream: false,
responseStream: false,
requestType: google_protobuf_empty_pb.Empty,
responseType: pulumi_plugin_pb.PluginInfo,
requestSerialize: serialize_google_protobuf_Empty,
requestDeserialize: deserialize_google_protobuf_Empty,
responseSerialize: serialize_pulumirpc_PluginInfo,
responseDeserialize: deserialize_pulumirpc_PluginInfo,
},
Move InstallDependencies to the language plugin (#9294) * Move InstallDependencies to the language plugin This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself. This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this. We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli. An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well. The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC. The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given? * Just warn if pty fails to open * Add tests and return real tty files * Add to CHANGELOG * lint * format * Test strings * Log pty opening for trace debugging * s/Hack/Workaround * Use termios * Tweak terminal test * lint * Fix windows build
2022-04-03 14:54:59 +00:00
// InstallDependencies will install dependencies for the project, e.g. by running `npm install` for nodejs projects.
installDependencies: {
path: '/pulumirpc.LanguageRuntime/InstallDependencies',
requestStream: false,
responseStream: true,
requestType: pulumi_language_pb.InstallDependenciesRequest,
responseType: pulumi_language_pb.InstallDependenciesResponse,
Move InstallDependencies to the language plugin (#9294) * Move InstallDependencies to the language plugin This changes `pulumi new` and `pulumi up <template>` to invoke the language plugin to install dependencies, rather than having the code to install dependencies hardcoded into the cli itself. This does not change the way policypacks or plugin dependencies are installed. In theory we can make pretty much the same change to just invoke the language plugin, but baby steps we don't need to make that change at the same time as this. We used to feed the result of these install commands (dotnet build, npm install, etc) directly through to the CLI stdout/stderr. To mostly maintain that behaviour the InstallDependencies gRCP method streams back bytes to be written to stdout/stderr, those bytes are either read from pipes or a pty that we run the install commands with. The use of a pty is controlled by the global colorisation option in the cli. An alternative designs was to use the Engine interface to Log the results of install commands. This renders very differently to just writing directly to the standard outputs and I don't think would support control codes so well. The design as is means that `npm install` for example is still able to display a progress bar and colors even though we're running it in a separate process and streaming its output back via gRPC. The only "oddity" I feel that's fallen out of this work is that InstallDependencies for python used to overwrite the virtualenv runtime option. It looks like this was because our templates don't bother setting that. Because InstallDependencies doesn't have the project file, and at any rate will be used for policy pack projects in the future, I've moved that logic into `pulumi new` when it mutates the other project file settings. I think we should at some point cleanup so the templates correctly indicate to use a venv, or maybe change python to assume a virtual env of "venv" if none is given? * Just warn if pty fails to open * Add tests and return real tty files * Add to CHANGELOG * lint * format * Test strings * Log pty opening for trace debugging * s/Hack/Workaround * Use termios * Tweak terminal test * lint * Fix windows build
2022-04-03 14:54:59 +00:00
requestSerialize: serialize_pulumirpc_InstallDependenciesRequest,
requestDeserialize: deserialize_pulumirpc_InstallDependenciesRequest,
responseSerialize: serialize_pulumirpc_InstallDependenciesResponse,
responseDeserialize: deserialize_pulumirpc_InstallDependenciesResponse,
},
// RuntimeOptionsPrompts returns a list of additional prompts to ask during `pulumi new`.
runtimeOptionsPrompts: {
path: '/pulumirpc.LanguageRuntime/RuntimeOptionsPrompts',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.RuntimeOptionsRequest,
responseType: pulumi_language_pb.RuntimeOptionsResponse,
requestSerialize: serialize_pulumirpc_RuntimeOptionsRequest,
requestDeserialize: deserialize_pulumirpc_RuntimeOptionsRequest,
responseSerialize: serialize_pulumirpc_RuntimeOptionsResponse,
responseDeserialize: deserialize_pulumirpc_RuntimeOptionsResponse,
},
// About returns information about the runtime for this language.
about: {
path: '/pulumirpc.LanguageRuntime/About',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.AboutRequest,
responseType: pulumi_language_pb.AboutResponse,
requestSerialize: serialize_pulumirpc_AboutRequest,
requestDeserialize: deserialize_pulumirpc_AboutRequest,
responseSerialize: serialize_pulumirpc_AboutResponse,
responseDeserialize: deserialize_pulumirpc_AboutResponse,
},
// GetProgramDependencies returns the set of dependencies required by the program.
getProgramDependencies: {
path: '/pulumirpc.LanguageRuntime/GetProgramDependencies',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.GetProgramDependenciesRequest,
responseType: pulumi_language_pb.GetProgramDependenciesResponse,
requestSerialize: serialize_pulumirpc_GetProgramDependenciesRequest,
requestDeserialize: deserialize_pulumirpc_GetProgramDependenciesRequest,
responseSerialize: serialize_pulumirpc_GetProgramDependenciesResponse,
responseDeserialize: deserialize_pulumirpc_GetProgramDependenciesResponse,
},
// RunPlugin executes a plugin program and returns its result asynchronously.
runPlugin: {
path: '/pulumirpc.LanguageRuntime/RunPlugin',
requestStream: false,
responseStream: true,
requestType: pulumi_language_pb.RunPluginRequest,
responseType: pulumi_language_pb.RunPluginResponse,
requestSerialize: serialize_pulumirpc_RunPluginRequest,
requestDeserialize: deserialize_pulumirpc_RunPluginRequest,
responseSerialize: serialize_pulumirpc_RunPluginResponse,
responseDeserialize: deserialize_pulumirpc_RunPluginResponse,
},
// GenerateProgram generates a given PCL program into a program for this language.
generateProgram: {
path: '/pulumirpc.LanguageRuntime/GenerateProgram',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.GenerateProgramRequest,
responseType: pulumi_language_pb.GenerateProgramResponse,
requestSerialize: serialize_pulumirpc_GenerateProgramRequest,
requestDeserialize: deserialize_pulumirpc_GenerateProgramRequest,
responseSerialize: serialize_pulumirpc_GenerateProgramResponse,
responseDeserialize: deserialize_pulumirpc_GenerateProgramResponse,
},
// GenerateProject generates a given PCL program into a project for this language.
generateProject: {
path: '/pulumirpc.LanguageRuntime/GenerateProject',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.GenerateProjectRequest,
responseType: pulumi_language_pb.GenerateProjectResponse,
requestSerialize: serialize_pulumirpc_GenerateProjectRequest,
requestDeserialize: deserialize_pulumirpc_GenerateProjectRequest,
responseSerialize: serialize_pulumirpc_GenerateProjectResponse,
responseDeserialize: deserialize_pulumirpc_GenerateProjectResponse,
},
// GeneratePackage generates a given pulumi package into a package for this language.
generatePackage: {
path: '/pulumirpc.LanguageRuntime/GeneratePackage',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.GeneratePackageRequest,
responseType: pulumi_language_pb.GeneratePackageResponse,
requestSerialize: serialize_pulumirpc_GeneratePackageRequest,
requestDeserialize: deserialize_pulumirpc_GeneratePackageRequest,
responseSerialize: serialize_pulumirpc_GeneratePackageResponse,
responseDeserialize: deserialize_pulumirpc_GeneratePackageResponse,
},
// Pack packs a package into a language specific artifact.
pack: {
path: '/pulumirpc.LanguageRuntime/Pack',
requestStream: false,
responseStream: false,
requestType: pulumi_language_pb.PackRequest,
responseType: pulumi_language_pb.PackResponse,
requestSerialize: serialize_pulumirpc_PackRequest,
requestDeserialize: deserialize_pulumirpc_PackRequest,
responseSerialize: serialize_pulumirpc_PackResponse,
responseDeserialize: deserialize_pulumirpc_PackResponse,
},
Switch to parent pointers; display components nicely This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud::cloud:function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew.
2017-11-17 02:21:41 +00:00
};
exports.LanguageRuntimeClient = grpc.makeGenericClientConstructor(LanguageRuntimeService);