2023-12-04 15:22:44 +00:00
|
|
|
// 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";
|
2023-12-04 15:22:44 +00:00
|
|
|
|
|
|
|
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 = {
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2024-09-04 10:36:45 +00:00
|
|
|
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;
|
2024-09-04 10:36:45 +00:00
|
|
|
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;
|
2024-09-04 10:36:45 +00:00
|
|
|
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;
|
2024-09-04 10:36:45 +00:00
|
|
|
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>};
|
2024-09-04 10:36:45 +00:00
|
|
|
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
|
|
|
}
|
|
|
|
|
2024-09-04 10:36:45 +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,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2023-12-04 15:22:44 +00:00
|
|
|
export enum LogSeverity {
|
|
|
|
DEBUG = 0,
|
|
|
|
INFO = 1,
|
|
|
|
WARNING = 2,
|
|
|
|
ERROR = 3,
|
|
|
|
}
|