hostRules: improve matchHost validation and parsing

[rarkins]

Describe the proposed change(s).

Goal: massage "incorrect" matchHost values with ports or paths, for example gitlab.company.com:8080 or registry.company.com/some/path.

Improve validation: if a matchHost value contains " or / then we should add https:// as the prefix and check if it's a valid URL. If it's not then I think it's safe for us to raise a config validation error. If it's valid, then we don't need to migrate it, because some config.js configurations may not be possible to migrate (the value comes from env).

Also improve validation of empty matchHost. If the matchHost key is defined, but the value is undefined, then we should warn. This is commonly caused by empty process.env.SOMETHING being used. We should similar do for empty string "".

Finally, we should enhance the addRule function to do similar logic and prefix the matchHost with https:// if it contains : or /.

[RahulGautamSingh]

Improve validation: if a matchHost value contains " or / then we should add https:// as the prefix and check if it's a valid URL.

you mean : or / ?

[rarkins]

Yes I did

[RahulGautamSingh]

Can you confirm these are correct?

gitlab.company.com:8080 -> https://gitlab.company.com:8080
registry.company.com/some/path -> https://registry.company.com/some/path
github.com -> github.com
api.github.com -> api.github.com
https://someurl.com -> https://someurl.com

[rarkins]

Yes, correct

[RahulGautamSingh]

Improve validation: if a matchHost value contains " or / then we should add https:// as the prefix and check if it's a valid URL. If it's not then I think it's safe for us to raise a config validation error. If it's valid, then we don't need to migrate it, because some config.js configurations may not be possible to migrate (the value comes from env)

We only create a migration PR for the repo config, so it should not be an issue if the config.js takes values from the env.

Also improve validation of empty matchHost. If the matchHost key is defined, but the value is undefined, then we should warn.

How should this be detected? Using for...in or hasOwnProperty ?

[rarkins]

Yes something like that

[RahulGautamSingh]

Also improve validation of empty matchHost. If the matchHost key is defined, but the value is undefined, then we should warn.

We already error on this as the matchHost.