Init reporter

[peraltafederico]

We've decided to forgo using the reporter to normalize the JSON payload and, instead, at a later stage, refactor it to report payloads to the remote backend. For now, disable the API; however, keep the types in place so it's not accidentally relied on.

Motivation

Normalize the payload before sending it to the Platform. The primary reason for this is to create a ready-to-use payload that can be sent to the Platform. Currently, it mainly filters out outputs that are not "stdout" but as we move the Platform GraphQL request to the Kernel, this behavior may change as needed.

(See also https://github.com/stateful/platform/pull/822 and stateful/vscode-runme#1558)

[peraltafederico]

Needed to make it work in Linux

[sourishkrout]

Ln 11-30, we should group into one or multiple sub-messages. Protos are practically immutable and this laundry list of properties at the request message level is likely a long-term liability. Host, Env, VSC? Honestly not even as important how it's grouped but it needs grouping.

I mean, I like ReporterExtension, ReporterGit, etc.

[peraltafederico]

Got it. I structured it this way so the "Transform" function can return the payload in the shape defined by the proto file, eliminating the need to do this on the client side. But I totally get your point 👍

[sourishkrout]

Right. Perhaps group them under a single message that's part of TransformRequest.

[peraltafederico]

Addresed with a single "extension" message.

[sourishkrout]

Normalize the payload before sending it to the Platform.

Can you please elaborate @peraltafederico why you chose to propose this "Transform" architecture?

[peraltafederico]

Normalize the payload before sending it to the Platform.

Can you please elaborate @peraltafederico why you chose to propose this "Transform" architecture?

@sourishkrout Absolutely! The primary reason was to create a ready-to-use payload that can be sent to the Platform. Currently, it mainly filters out outputs that are not 'stdout,' but as we move the Platform GraphQL request to the Kernel, this behavior may change as needed.

Any suggestions on this approach?

[sourishkrout]

Normalize the payload before sending it to the Platform.

Can you please elaborate @peraltafederico why you chose to propose this "Transform" architecture?

@sourishkrout Absolutely! The primary reason was to create a ready-to-use payload that can be sent to the Platform. Currently, it mainly filters out outputs that are not 'stdout,' but as we move the Platform GraphQL request to the Kernel, this behavior may change as needed.

Any suggestions on this approach?

In the PR's description, please. It's mainly to contextualize and memoize the intention of this PR more clearly.

[sourishkrout]

Converted to draft. Let's keep this open while we finalize the other PRs mentioned. As discussed, we are deferring bringing the reporter API into the picture at a later time.

I'll be sure to make this mergeable so it won't dangle for too long.

[sourishkrout]

Merging this as per the decision outlined in the description.

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
96.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud