* ui: Add the most basic workspace root in /ui
* We already have a LICENSE file in the repository root
* Change directory path in build scripts ui-v2 -> ui
* Make yarn install flags configurable from elsewhere
* Minimal workspace root makefile
* Call the new docker specific target
* Update yarn in the docker build image
* Reconfigure the netlify target and move to the higher makefile
* Move ui-v2 -> ui/packages/consul-ui
* Change repo root to refleect new folder structure
* Temporarily don't hoist consul-api-double
* Fixup CI configuration
* Fixup lint errors
* Fixup Netlify target
* ui: Reduce discovery-chain log spam
Currently the only way that the UI can know whether connect is enabled
or not is whether we get 500 errors from certain endpoints.
One of these endpoints we already use, so aswell as recovering from a
500 error, we also remember that connect is disabled for the rest of the
page 'session' (so until the page is refreshed), and make no further
http requests to the endpoint for that specific datacenter.
This means that log spam is reduced to only 1 log per page refresh/dc
instead of 1 log per service navigation.
Longer term we'll need some way to dynamically discover whether connect
is enabled per datacenter without relying on something that will add
error logs to consul.
* ui: Combine all "see/don't see" steps into one step
* Fix up broken tests
* Add some test meta data/titles
* Test out proxies in the service listing
* Remove comments
* Create ConsulServiceInstanceList with styling and test
* Implement ConsulServiceInstanceList to Service Detail page
* Implement ConsulExternalSource to Services Show page header
* Update services/show page object
* Update the styling of CompositeRow
* Refactor ConsulServiceList component and styling
* Update ConsulExternalSource to say 'Registered via...'
* Upgrade consul-api-double to patch 2.14.1
* Fix up tests to not use Kind in service models
* Update ListCollection with clickFirstAnchor action
* Add $typo-size-450 to typography base variables
When connect is disabled the discovery-chain endpoint returns a 500
error status, which we previoulsy did not gracefully cope with.
This commit gracefully copes with any errors from the disco-chain
endpoint by supressing the error and hiding the Routing tab from the
Service detail page.
Acceptance test included
* Adds conditional in route to not make discovery-chain request if service kind is equal to `connect-proxy` or `mesh-gateway`
* Adds conditional in template to not show Routing tab if `chain` returns as null
* Creates a new acceptance test to test the Routing tab not being displayed for a service proxy
* Adds `tabs` to the services/show page object
John Cowen