feat: warn on unroutable --routing-urls

[patrick91]

Hi there :)

I've noticed a couple of instances where we had either:

rover subgraph publish my-supergraph@my-variant \
  --schema "./accounts/schema.graphql" \
  --name accounts \
  --routing-url "my-running-subgraph.com/api" # note the missing scheme here

or

rover subgraph publish my-supergraph@my-variant \
  --schema "./accounts/schema.graphql" \
  --name accounts \
  --routing-url $NON_EXISTENT_VAR

leading to issues in our Cloud Router due to wrong or empty URLs. In our codebase we mention:

    /// Url of a running subgraph that a supergraph can route operations to
    /// (often a deployed subgraph). May be left empty ("") or a placeholder url
    /// if not running a gateway or router in managed federation mode

I wonder if we could improve this. Passing the flag with an empty URL feels a bit strange to me and it might have been caused by a misconfiguration (like in the second case there).

I don't have all the context so maybe being allowed to at least use a placeholder url is fine, but maybe we can validate the format[1]? so if you need a placeholder you can do http://abc?

Does this all make sense? 😊

[1] we should also have this check on the router/cloud-router to be fair

[EverlastingBugstopper]

This is a great point @patrick91 and one that I was tripped up on when we first introduced this command. I think there's a lot we can do here to make the experience better, but we'll need to be sure that we don't break existing workflows that may depend on invalid or placeholder values.

Here's what I'm thinking:

When a --routing-url is passed to rover subgraph publish:

• In the case where a human is manually doing a publish (this can be determined by checking for a TTY) then Rover prints a warning that the URL is invalid with a prompt ([y/N]) to continue with the publish.

• In the case where CI or a script is doing the publish (check for a TTY) then Rover prints a warning saying the routing url is invalid, but still allow the publish to go through. We might also want to make the warning include a notice that this behavior may break in future versions of Rover if the --allow-invalid-routing-url flag is not passed.

• In both scenarios (and in future versions of Rover), passing the --allow-invalid-routing-url flag should disable the warnings entirely and allow the invalid routing url to be used.

When a --routing-url is not passed to rover subgraph publish:

• Perform a GraphQL query against the platform API to get the routing url for that subgraph
• If that URL is invalid, follow the same error/warn procedure as described above