Open j-q-arnold opened 4 years ago
I communicated a bit with @j-q-arnold over slack, but the problem here was that servers
blocks cannot have string descriptions (yet they can have comments). Individual server
s, on the other hand, can have descriptions.
Example (Allowed):
// These are my servers
servers {
/REST
"This is the test server"
server = "http://test-api.liveramp.com:{port:8080}"
...
Example (Not Allowed):
"These are my servers"
servers {
/REST
"This is the test server"
server = "http://test-api.liveramp.com:{port:8080}"
...
I'm going to remove the bug label, but leave this open with the documentation and enhancement labels - Jim raised a bunch of good points.
This is issue concerns multiple aspects of 'server blocks'. (I probably should break this into multiple issues, but perhaps they can be addressed in a single release.)
reslang
compiler does not accept the syntax.This error from a simple server block that mirrors the example documentation. After further investigation, this was caused by a description string before the
servers
block. The language accepts a comment but rejects a description. If similarity with other blocks (resources, etc.), I recommend allowing a description string (even if that string has no effect on the generated yaml).servers
name of the block implies the block can define multiple servers. Please document how this is done.server
attribute. This could be in an implementation section specific to LiveRamp, but it should exist somewhere.server
attribute? Should give full details about the value supplied in the block and the value used in the output OpenAPI/event server spec. This includes the port handling.prefix
, etc.) affect the behavior. How do the command line values interact with values from the source code? Is it possible to defineprefix
in the reslang source? As a recommendation, anything that one can specify on the command line should have an analog in the reslang language.environment = PROD
, implying other types of servers might be available. Need to document those environments and their values. Also should document the LiveRamp conventions for each environment.protocol
attribute./events
section appears to take a "string comment" that describes the server. One imagines this can be done for the/REST
section's servers, but the example is unclear.environment
seems rather generic. The "environment" is a general mechanism for passing multiple name-value pairs around the ecosystem. Pickingenvironment
as the specific name of one name-value pair seems likely to cause confusion. Using--env
as the command-line flag adds ambiguity. I would expect the currentenvironment
value to be one of the names passed through the--vars
mechanism. Suggestion:deployment
seems like a reasonable name for this value, for example,--vars deployment=STAGING