pulumi/sdk/nodejs/proto/engine_pb.d.ts

149 lines
6.2 KiB
TypeScript
Raw Permalink Normal View History

// package: pulumirpc
// file: pulumi/engine.proto
/* tslint:disable */
/* eslint-disable */
import * as jspb from "google-protobuf";
import * as google_protobuf_empty_pb from "google-protobuf/google/protobuf/empty_pb";
implement the engine bits for debugging support (#17072) We want to introduce dubugging support for Pulumi programs. This PR implements the engine changes necessary for that. Namely, we pass the information whether we expect a debugger to be started to the language runtime, and introduce a way for the language runtime plugins to report to the engine that we're waiting for a debugger to attach. The language runtime is expected to include the information relevant for the user to be able to attach to the debugger, as well as a shortened message. The idea is that the configuration can be picked up by an IDE, and the debugger can attach automatically. Meanwhile the short message should contain enough information to be able to attach a debugger manually, while being short enough to be displayed to the user in the CLI output. (this will commonly be either the port of the debugger, or the PID of the process being debugged). The implementation of the CLI flags and each of the language runtimes will follow in subsequent PRs. I tried adding a test to this, but I'm not sure it's possible with our current testing infrastructure. To do this properly, we'd need to make a RPC call to the engine, but we don't have that available in the lifecycletests (? please let me know if I'm missing something). Once more of the feature is implemented we might be able to implement an integration test for it. (Not straightforward either, as we'll have to tell the debugger to continue, but that should be more doable). Another thing that's not clear to me is that @EronWright mentions this could be used for MLC/provider debugging as well. However I'm not seeing how that's going to work, as MLCs/providers are being run as a binary plugin, which we don't compile from pulumi/pulumi, and thus wouldn't necessarily even know which debugger to launch it under without a bunch of additional configuration, that might be better in a shim around the program (or just keeping the debugging the way we're currently doing, launching the program and then letting the engine attach to it). --------- Co-authored-by: Eron Wright <eron@pulumi.com> Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
import * as google_protobuf_struct_pb from "google-protobuf/google/protobuf/struct_pb";
export class LogRequest extends jspb.Message {
getSeverity(): LogSeverity;
setSeverity(value: LogSeverity): LogRequest;
getMessage(): string;
setMessage(value: string): LogRequest;
getUrn(): string;
setUrn(value: string): LogRequest;
getStreamid(): number;
setStreamid(value: number): LogRequest;
getEphemeral(): boolean;
setEphemeral(value: boolean): LogRequest;
serializeBinary(): Uint8Array;
toObject(includeInstance?: boolean): LogRequest.AsObject;
static toObject(includeInstance: boolean, msg: LogRequest): LogRequest.AsObject;
static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};
static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};
static serializeBinaryToWriter(message: LogRequest, writer: jspb.BinaryWriter): void;
static deserializeBinary(bytes: Uint8Array): LogRequest;
static deserializeBinaryFromReader(message: LogRequest, reader: jspb.BinaryReader): LogRequest;
}
export namespace LogRequest {
export type AsObject = {
severity: LogSeverity,
message: string,
urn: string,
streamid: number,
ephemeral: boolean,
}
}
export class GetRootResourceRequest extends jspb.Message {
serializeBinary(): Uint8Array;
toObject(includeInstance?: boolean): GetRootResourceRequest.AsObject;
static toObject(includeInstance: boolean, msg: GetRootResourceRequest): GetRootResourceRequest.AsObject;
static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};
static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};
static serializeBinaryToWriter(message: GetRootResourceRequest, writer: jspb.BinaryWriter): void;
static deserializeBinary(bytes: Uint8Array): GetRootResourceRequest;
static deserializeBinaryFromReader(message: GetRootResourceRequest, reader: jspb.BinaryReader): GetRootResourceRequest;
}
export namespace GetRootResourceRequest {
export type AsObject = {
}
}
export class GetRootResourceResponse extends jspb.Message {
getUrn(): string;
setUrn(value: string): GetRootResourceResponse;
serializeBinary(): Uint8Array;
toObject(includeInstance?: boolean): GetRootResourceResponse.AsObject;
static toObject(includeInstance: boolean, msg: GetRootResourceResponse): GetRootResourceResponse.AsObject;
static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};
static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};
static serializeBinaryToWriter(message: GetRootResourceResponse, writer: jspb.BinaryWriter): void;
static deserializeBinary(bytes: Uint8Array): GetRootResourceResponse;
static deserializeBinaryFromReader(message: GetRootResourceResponse, reader: jspb.BinaryReader): GetRootResourceResponse;
}
export namespace GetRootResourceResponse {
export type AsObject = {
urn: string,
}
}
export class SetRootResourceRequest extends jspb.Message {
getUrn(): string;
setUrn(value: string): SetRootResourceRequest;
serializeBinary(): Uint8Array;
toObject(includeInstance?: boolean): SetRootResourceRequest.AsObject;
static toObject(includeInstance: boolean, msg: SetRootResourceRequest): SetRootResourceRequest.AsObject;
static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};
static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};
static serializeBinaryToWriter(message: SetRootResourceRequest, writer: jspb.BinaryWriter): void;
static deserializeBinary(bytes: Uint8Array): SetRootResourceRequest;
static deserializeBinaryFromReader(message: SetRootResourceRequest, reader: jspb.BinaryReader): SetRootResourceRequest;
}
export namespace SetRootResourceRequest {
export type AsObject = {
urn: string,
}
}
export class SetRootResourceResponse extends jspb.Message {
serializeBinary(): Uint8Array;
toObject(includeInstance?: boolean): SetRootResourceResponse.AsObject;
static toObject(includeInstance: boolean, msg: SetRootResourceResponse): SetRootResourceResponse.AsObject;
static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};
static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};
static serializeBinaryToWriter(message: SetRootResourceResponse, writer: jspb.BinaryWriter): void;
static deserializeBinary(bytes: Uint8Array): SetRootResourceResponse;
static deserializeBinaryFromReader(message: SetRootResourceResponse, reader: jspb.BinaryReader): SetRootResourceResponse;
}
export namespace SetRootResourceResponse {
export type AsObject = {
}
}
export class StartDebuggingRequest extends jspb.Message {
implement the engine bits for debugging support (#17072) We want to introduce dubugging support for Pulumi programs. This PR implements the engine changes necessary for that. Namely, we pass the information whether we expect a debugger to be started to the language runtime, and introduce a way for the language runtime plugins to report to the engine that we're waiting for a debugger to attach. The language runtime is expected to include the information relevant for the user to be able to attach to the debugger, as well as a shortened message. The idea is that the configuration can be picked up by an IDE, and the debugger can attach automatically. Meanwhile the short message should contain enough information to be able to attach a debugger manually, while being short enough to be displayed to the user in the CLI output. (this will commonly be either the port of the debugger, or the PID of the process being debugged). The implementation of the CLI flags and each of the language runtimes will follow in subsequent PRs. I tried adding a test to this, but I'm not sure it's possible with our current testing infrastructure. To do this properly, we'd need to make a RPC call to the engine, but we don't have that available in the lifecycletests (? please let me know if I'm missing something). Once more of the feature is implemented we might be able to implement an integration test for it. (Not straightforward either, as we'll have to tell the debugger to continue, but that should be more doable). Another thing that's not clear to me is that @EronWright mentions this could be used for MLC/provider debugging as well. However I'm not seeing how that's going to work, as MLCs/providers are being run as a binary plugin, which we don't compile from pulumi/pulumi, and thus wouldn't necessarily even know which debugger to launch it under without a bunch of additional configuration, that might be better in a shim around the program (or just keeping the debugging the way we're currently doing, launching the program and then letting the engine attach to it). --------- Co-authored-by: Eron Wright <eron@pulumi.com> Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
hasConfig(): boolean;
clearConfig(): void;
getConfig(): google_protobuf_struct_pb.Struct | undefined;
setConfig(value?: google_protobuf_struct_pb.Struct): StartDebuggingRequest;
implement the engine bits for debugging support (#17072) We want to introduce dubugging support for Pulumi programs. This PR implements the engine changes necessary for that. Namely, we pass the information whether we expect a debugger to be started to the language runtime, and introduce a way for the language runtime plugins to report to the engine that we're waiting for a debugger to attach. The language runtime is expected to include the information relevant for the user to be able to attach to the debugger, as well as a shortened message. The idea is that the configuration can be picked up by an IDE, and the debugger can attach automatically. Meanwhile the short message should contain enough information to be able to attach a debugger manually, while being short enough to be displayed to the user in the CLI output. (this will commonly be either the port of the debugger, or the PID of the process being debugged). The implementation of the CLI flags and each of the language runtimes will follow in subsequent PRs. I tried adding a test to this, but I'm not sure it's possible with our current testing infrastructure. To do this properly, we'd need to make a RPC call to the engine, but we don't have that available in the lifecycletests (? please let me know if I'm missing something). Once more of the feature is implemented we might be able to implement an integration test for it. (Not straightforward either, as we'll have to tell the debugger to continue, but that should be more doable). Another thing that's not clear to me is that @EronWright mentions this could be used for MLC/provider debugging as well. However I'm not seeing how that's going to work, as MLCs/providers are being run as a binary plugin, which we don't compile from pulumi/pulumi, and thus wouldn't necessarily even know which debugger to launch it under without a bunch of additional configuration, that might be better in a shim around the program (or just keeping the debugging the way we're currently doing, launching the program and then letting the engine attach to it). --------- Co-authored-by: Eron Wright <eron@pulumi.com> Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
getMessage(): string;
setMessage(value: string): StartDebuggingRequest;
implement the engine bits for debugging support (#17072) We want to introduce dubugging support for Pulumi programs. This PR implements the engine changes necessary for that. Namely, we pass the information whether we expect a debugger to be started to the language runtime, and introduce a way for the language runtime plugins to report to the engine that we're waiting for a debugger to attach. The language runtime is expected to include the information relevant for the user to be able to attach to the debugger, as well as a shortened message. The idea is that the configuration can be picked up by an IDE, and the debugger can attach automatically. Meanwhile the short message should contain enough information to be able to attach a debugger manually, while being short enough to be displayed to the user in the CLI output. (this will commonly be either the port of the debugger, or the PID of the process being debugged). The implementation of the CLI flags and each of the language runtimes will follow in subsequent PRs. I tried adding a test to this, but I'm not sure it's possible with our current testing infrastructure. To do this properly, we'd need to make a RPC call to the engine, but we don't have that available in the lifecycletests (? please let me know if I'm missing something). Once more of the feature is implemented we might be able to implement an integration test for it. (Not straightforward either, as we'll have to tell the debugger to continue, but that should be more doable). Another thing that's not clear to me is that @EronWright mentions this could be used for MLC/provider debugging as well. However I'm not seeing how that's going to work, as MLCs/providers are being run as a binary plugin, which we don't compile from pulumi/pulumi, and thus wouldn't necessarily even know which debugger to launch it under without a bunch of additional configuration, that might be better in a shim around the program (or just keeping the debugging the way we're currently doing, launching the program and then letting the engine attach to it). --------- Co-authored-by: Eron Wright <eron@pulumi.com> Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
serializeBinary(): Uint8Array;
toObject(includeInstance?: boolean): StartDebuggingRequest.AsObject;
static toObject(includeInstance: boolean, msg: StartDebuggingRequest): StartDebuggingRequest.AsObject;
implement the engine bits for debugging support (#17072) We want to introduce dubugging support for Pulumi programs. This PR implements the engine changes necessary for that. Namely, we pass the information whether we expect a debugger to be started to the language runtime, and introduce a way for the language runtime plugins to report to the engine that we're waiting for a debugger to attach. The language runtime is expected to include the information relevant for the user to be able to attach to the debugger, as well as a shortened message. The idea is that the configuration can be picked up by an IDE, and the debugger can attach automatically. Meanwhile the short message should contain enough information to be able to attach a debugger manually, while being short enough to be displayed to the user in the CLI output. (this will commonly be either the port of the debugger, or the PID of the process being debugged). The implementation of the CLI flags and each of the language runtimes will follow in subsequent PRs. I tried adding a test to this, but I'm not sure it's possible with our current testing infrastructure. To do this properly, we'd need to make a RPC call to the engine, but we don't have that available in the lifecycletests (? please let me know if I'm missing something). Once more of the feature is implemented we might be able to implement an integration test for it. (Not straightforward either, as we'll have to tell the debugger to continue, but that should be more doable). Another thing that's not clear to me is that @EronWright mentions this could be used for MLC/provider debugging as well. However I'm not seeing how that's going to work, as MLCs/providers are being run as a binary plugin, which we don't compile from pulumi/pulumi, and thus wouldn't necessarily even know which debugger to launch it under without a bunch of additional configuration, that might be better in a shim around the program (or just keeping the debugging the way we're currently doing, launching the program and then letting the engine attach to it). --------- Co-authored-by: Eron Wright <eron@pulumi.com> Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
static extensions: {[key: number]: jspb.ExtensionFieldInfo<jspb.Message>};
static extensionsBinary: {[key: number]: jspb.ExtensionFieldBinaryInfo<jspb.Message>};
static serializeBinaryToWriter(message: StartDebuggingRequest, writer: jspb.BinaryWriter): void;
static deserializeBinary(bytes: Uint8Array): StartDebuggingRequest;
static deserializeBinaryFromReader(message: StartDebuggingRequest, reader: jspb.BinaryReader): StartDebuggingRequest;
implement the engine bits for debugging support (#17072) We want to introduce dubugging support for Pulumi programs. This PR implements the engine changes necessary for that. Namely, we pass the information whether we expect a debugger to be started to the language runtime, and introduce a way for the language runtime plugins to report to the engine that we're waiting for a debugger to attach. The language runtime is expected to include the information relevant for the user to be able to attach to the debugger, as well as a shortened message. The idea is that the configuration can be picked up by an IDE, and the debugger can attach automatically. Meanwhile the short message should contain enough information to be able to attach a debugger manually, while being short enough to be displayed to the user in the CLI output. (this will commonly be either the port of the debugger, or the PID of the process being debugged). The implementation of the CLI flags and each of the language runtimes will follow in subsequent PRs. I tried adding a test to this, but I'm not sure it's possible with our current testing infrastructure. To do this properly, we'd need to make a RPC call to the engine, but we don't have that available in the lifecycletests (? please let me know if I'm missing something). Once more of the feature is implemented we might be able to implement an integration test for it. (Not straightforward either, as we'll have to tell the debugger to continue, but that should be more doable). Another thing that's not clear to me is that @EronWright mentions this could be used for MLC/provider debugging as well. However I'm not seeing how that's going to work, as MLCs/providers are being run as a binary plugin, which we don't compile from pulumi/pulumi, and thus wouldn't necessarily even know which debugger to launch it under without a bunch of additional configuration, that might be better in a shim around the program (or just keeping the debugging the way we're currently doing, launching the program and then letting the engine attach to it). --------- Co-authored-by: Eron Wright <eron@pulumi.com> Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
}
export namespace StartDebuggingRequest {
implement the engine bits for debugging support (#17072) We want to introduce dubugging support for Pulumi programs. This PR implements the engine changes necessary for that. Namely, we pass the information whether we expect a debugger to be started to the language runtime, and introduce a way for the language runtime plugins to report to the engine that we're waiting for a debugger to attach. The language runtime is expected to include the information relevant for the user to be able to attach to the debugger, as well as a shortened message. The idea is that the configuration can be picked up by an IDE, and the debugger can attach automatically. Meanwhile the short message should contain enough information to be able to attach a debugger manually, while being short enough to be displayed to the user in the CLI output. (this will commonly be either the port of the debugger, or the PID of the process being debugged). The implementation of the CLI flags and each of the language runtimes will follow in subsequent PRs. I tried adding a test to this, but I'm not sure it's possible with our current testing infrastructure. To do this properly, we'd need to make a RPC call to the engine, but we don't have that available in the lifecycletests (? please let me know if I'm missing something). Once more of the feature is implemented we might be able to implement an integration test for it. (Not straightforward either, as we'll have to tell the debugger to continue, but that should be more doable). Another thing that's not clear to me is that @EronWright mentions this could be used for MLC/provider debugging as well. However I'm not seeing how that's going to work, as MLCs/providers are being run as a binary plugin, which we don't compile from pulumi/pulumi, and thus wouldn't necessarily even know which debugger to launch it under without a bunch of additional configuration, that might be better in a shim around the program (or just keeping the debugging the way we're currently doing, launching the program and then letting the engine attach to it). --------- Co-authored-by: Eron Wright <eron@pulumi.com> Co-authored-by: Julien <julien@caffeine.lu>
2024-08-30 10:31:28 +00:00
export type AsObject = {
config?: google_protobuf_struct_pb.Struct.AsObject,
message: string,
}
}
export enum LogSeverity {
DEBUG = 0,
INFO = 1,
WARNING = 2,
ERROR = 3,
}