feat: 🎸 Auto-populate hcp cluster id

[ZedLi]

trafficstars

✅ Closes: ICU-6200

:tickets: Jira ticket

Description

This PR attempts at a front end only solution for auto-populating the HCP cluster ID. Ideally we would have an API we could hit that could return what the current cluster is and any other meta data but in the absence of that, we can attempt a best effort solution. This currently just pulls the guid from the URL and auto-populates the cluster ID.

Some other ideas I considered was passing a query string or saving the ID from the cluster in local storage from the HCP side but that requires navigation from the portal or a specific link; this is the simplest way to auto populate the ID from just a normal url.

There was some talk in the future (see this thread) that we might allow CNAME-ing so customers will have more friendly URLs. This wouldn't work in those scenarios but it would just revert to the current functionality and the user would have to manually fill it out.

Cleaned up the form: there was an unused @cancel and I had to pull the route action up to a parameter so it can be integration-tested easier.

Unfortunately this can't be easily tested but I included some integration tests to show what kind of URLs it will populate. Take a look here if you want to play around with the regex yourself or want an explanation of it.

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
boundary-ui	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Nov 2, 2022 at 6:15PM (UTC)
boundary-ui-desktop	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Nov 2, 2022 at 6:15PM (UTC)
boundary-ui-storybook	✅ Ready (Inspect)	Visit Preview	💬 Add your feedback	Nov 2, 2022 at 6:15PM (UTC)

[ZedLi]

Just curious is adding this new package is worth it for accessing the hostname.

Not sure I'm understanding the question, the package I added is only used to help mock out the global window. In non-testing environments it's just a passthrough to the normal global window object which I could access without any package.

I wasn't aware of the wrapper we've previously used with window but I'm not sure I see the benefit using it here. In those scenarios it accesses the same global window which you could now mock out in a route or controller.

I'm accessing the window from a component and just want to test that, I don't see much benefit to indirectly wrapping the global window when I'd have to still pass in a window to the component most likely from a route or controller to correctly mock it out. I brought in the package to simplify this aspect but if there's a better or simpler way, I'd love to see an example.

[cameronperera]

Just curious is adding this new package is worth it for accessing the hostname.

Not sure I'm understanding the question, the package I added is only used to help mock out the global window. In non-testing environments it's just a passthrough to the normal global window object which I could access without any package.

I wasn't aware of the wrapper we've previously used with window but I'm not sure I see the benefit using it here. In those scenarios it accesses the same global window which you could now mock out in a route or controller.

I'm accessing the window from a component and just want to test that, I don't see much benefit to indirectly wrapping the global window when I'd have to still pass in a window to the component most likely from a route or controller to correctly mock it out. I brought in the package to simplify this aspect but if there's a better or simpler way, I'd love to see an example.

After reading through the conversation you had with Randy, I am withdrawing my comment. 😄 Nice work!

[ZedLi]

Let's use the test helpers provided by the feature flag addon rather than manipulating the configuration in tests.

Have we used this before? ~~It can't find the import and the docs says it depends on ember-cli-qunit which is now deprecated~~

Edit: Uh so I think the docs are just both outdated and documenting unreleased work but the version we use (which is the most recent version) doesn't include the disableFeature as seen here. The codebase currently has it as it's part of the docs but it's never been released it looks like...

[ghost]

Let's use the test helpers provided by the feature flag addon rather than manipulating the configuration in tests.

Have we used this before? ~It can't find the import and the docs says it depends on ember-cli-qunit which is now deprecated~

Edit: Uh so I think the docs are just both outdated and documenting unreleased work but the version we use (which is the most recent version) doesn't include the disableFeature as seen here. The codebase currently has it as it's part of the docs but it's never been released it looks like...

You are absolutely right. The disableFeature test helper hasn't been released yet. I looked and it seems the test helper just calls service.disable(feature) under the hood. You could try that, just so we're going through the service rather than modifying the config directly: https://github.com/kategengler/ember-feature-flags/blob/v6.0.0/addon/services/features.js#L35

[cameronperera]

You are absolutely right. The disableFeature test helper hasn't been released yet. I looked and it seems the test helper just calls service.disable(feature) under the hood. You could try that, just so we're going through the service rather than modifying the config directly: https://github.com/kategengler/ember-feature-flags/blob/v6.0.0/addon/services/features.js#L35

In regards to the disableFeature functionality, I had to do the same thing for ssh targets when we implemented it. You can see that here, then on line 142 I call featuresService.disable('ssh-target');. The plan was to build a custom feature flag helper since ember-feature-flags hasn't released that feature yet. Now might be the time to create the helper (separate of this PR).

[calcaide]

@cameronperera Totally down to work on those helpers. Not necessary but wondering, if we work on those test helpers, do we need to keep using ember-feature-flags? or we will be able to get rid of that package?

[cameronperera]

@cameronperera Totally down to work on those helpers. Not necessary but wondering, if we work on those test helpers, do we need to keep using ember-feature-flags? or we will be able to get rid of that package?

If we created the helper we would be able to remove that package entirely. It would be relatively easy to handle both enableFeature and disableFeature. ~~Plus one less package!~~ I misspoke. We will still need this for our production build use cases. The helper would only be for running our tests.

[ZedLi]

If we created the helper we would be able to remove that package entirely. It would be relatively easy to handle both enableFeature and disableFeature. Plus one less package!

Just so I'm clear, are we suggesting just writing our own test helpers for those two functions, which currently are very thin wrappers, or are we suggesting writing our own template helper and service for ember-feature-flags to replace the package?