Schematize message structure for resources and extensions
Summary of the new feature / enhancement
As a developer working on DSC resources, extensions, or integrations, I want to reference a JSON schema for messages that resources or extensions should emit, So that I can validate my implementation without needing to refer to documentation.
Currently, developers need to rely on documentation and investigation in the repository to understand how to emit messages from their resources or extensions for DSC to consume and bubble up.
While we are in the process of documenting how to emit messages from resources and extensions, it would be even better to provide a JSON schema that enables developers to check their work and describes the expected contract in the same way that we describe the contracts for stdout.
Proposed technical implementation details (optional)
Currently, we do a basic check on the JSON structure for an emitted message:
https://github.com/PowerShell/DSC/blob/12a5faffe5ac667a4da9cb54344cdca344bd80c1/dsc_lib/src/dscresources/command_resource.rs#L917-L932
We should define a type to more accurately represent this structure, which we could then derive a JSON Schema for (and simplify the implementation for this check), like:
#[derive(Clone, Debug, PartialEq, Eq, Serialize, Deserialize, JsonSchema)]
#[serde(rename_all = "camelCase")]
pub enum CommandMessage {
Error(String),
Warn(String),
Info(String),
Debug(String),
Trace(String),
}
Then, in the log_stderr_line function, we can update the implementation to:
} else if let Ok(message_object) = serde_json::from_str<CommandMessage>(trace_line) {
match message_object {
CommandMessage::Error(message) => error!("PID {process_id}: {message}"),
CommandMessage::Warn(message) => warn!("PID {process_id}: {message}"),
CommandMessage::Info(message) => info!("PID {process_id}: {message}"),
CommandMessage::Debug(message) => debug!("PID {process_id}: {message}"),
CommandMessage::Trace(message) => trace!("PID {process_id}: {message}"),
}
} else {
When we eventually support sending structured data in addition to simple messages, we can provide a schema for that struct separately.