feat(server): make it possible to POST custom typings for testing during typing creation

[Vampire]

With this you can for example do curl --data-binary @action-types.yml https://bindings.krzeminski.it/pbrisbin/setup-tool-action/v2/setup-tool-action-v2.pom
then get as result coordinates containing a UUID in the group field which you can then use for an hour (or from the Maven Local cache thereafter) to test with
the supplied typing.

[Vampire]

• feat(server): make it possible to POST custom typings for testing during typing creation #1602 👈 (View in Graphite)
• refactor: unify content of ActionCoords name #1646 : 3 other dependent PRs (#1608 , #1609 , #1610 )
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[krzema12]

Did the next pass, not fully reviewed. Moderately actionable on you.

[krzema12]

How about making toBindingArtifacts communicate such case via its returned value? Then we'd avoid adding a direct dependency on snakeyam-engine-kmp, and generally having parsing these encapsulated in the function (not mentioning it's an abstraction leak because it's not realistic to have anything else than YAML here).

[Vampire]

Actually, I don't really agree.
The value is coming from the HTTP request, so is user input.
User input should always be considered to be not what you expect and be validated.

The body is an "argument" to the "API" and the "API" defines this has to be valid YAML.
So imho it is the right thing to explicitly validate the body to be valid YAML and also do that as soon as possible, not implicitly after several method calls two modules deep.

Also imho doing it that way would be the abstraction leak.
Because currently the place that parses the YAML is not aware that it is run behind an HTTP API.
Doing this change would need to make it aware that it is run behind an HTTP request, because it has to differentiate whether the types are coming as "API argument" so that it can result in "this is an unprocessable entity user error". If any of the other YAMLs has a parsing error, this is not a 4xx user error, as the user calling the HTTP API did not make an error, but it is a 5xx error as something on the server side is not working properly.

[krzema12]

I think we can make it better - adding types looks like a carveout in this function, and implies some hacks across the project like adding typesUuid to ActionCoords. I'd expect that just parsing of the YAML is triggered if the types as string are provided. I'll think about how to structure it better.

[Vampire]

What do you mean by "carveout"?

It says "give me the types, here is the YAML to use, if I don't give one explicitly default to requesting them from the action or catalog". For me this is not a "carveout" unless I don't get what you mean.

I also do not really see what "hacks" you mean. The "typesUuid" for me is not a hack but a generated part of the coordinates. It also is part of the coordinates, it is just split once and then stored into a separate field.