Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add apps open command #654

Merged
merged 1 commit into from
Mar 17, 2023
Merged

Add apps open command #654

merged 1 commit into from
Mar 17, 2023

Conversation

janelletavares
Copy link
Contributor

@janelletavares janelletavares commented Mar 17, 2023

Description of change

Convenience methods for seeing app details in the dashboard and interacting with it there.

Fixes https://github.com/meroxa/turbine-project/issues/219

Type of change

  • New feature
  • Bug fix
  • Refactor
  • Documentation

How was this tested?

  • Unit Tests
  • Tested in staging
  • Tested in minikube

Demo

before after

Additional references

Documentation updated

Copy link
Contributor

@jayjayjpg jayjayjpg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This reads great so far and I can also give this a try locally in just a bit!

cmd/meroxa/root/apps/open.go Outdated Show resolved Hide resolved
err := open.Start(dashboardURL)
if err != nil {
o.logger.Errorf(ctx, "meroxa: can't open browser to URL %s: %s\n", dashboardURL, err)
//os.Exit(1)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would this one be included or better be removed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, i meant to check that this was necessary from the code that i copied... it's hard to test because the binary being used is compiled in... oh well, i'll just remove it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIce test coverage! ✨

@jayjayjpg
Copy link
Contributor

This already works great! One thing I noticed, that I'm not sure about if we should solve it: meroxa apps open currently only works in production application but wouldn't be something that we could use in other test environments, such as staging:

appsopenname

If this is not a concern (e.g. meroxa apps describe also uses the hard-coded link to point to the production dashboard regardless of the CLI environment variables) this PR should be good to go!

Copy link
Contributor

@jayjayjpg jayjayjpg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This works great for all different application identification options:

m apps open by name m apps open by uuid m apps open by --path
appsopenprod appsopenprod_uuid appsopenprod_path

Copy link
Contributor

@samirketema samirketema left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks great! just one nit about a nolint / redundant test setup. love this feature!

desc: "Successfully open app link with arg",
appArg: "app-name",
path: func() string {
return filepath.Join("/tmp", uuid.New().String()) //nolint:gocritic
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder what linting error was ignored here. This brings up two more thoughts:

  • Does path need to be a function? seems like the function is defined exactly the same for each test case, we could remove the nolint if we drop path
  • Should we enable whyNoLint to have comments on nolint? I guess this also depends on how many nolints are already used in CLI

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i want it to be a different path for each use case, so i don't want to reuse this path value, but not it doesn't need to be a function. i copied the nolint from somewhere else, but it seems like it doesn't need to be there at all!


// open a browser window to the application details
dashboardURL := fmt.Sprintf("https://dashboard.meroxa.io/apps/%s/detail", nameOrUUID)
err := open.Start(dashboardURL)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is a single error return. We can have this instead:

if err := open.Start(dashboardURL); err != nil {
    o.logger.Errorf(ctx, "meroxa: can't open browser to URL %s: %s\n", dashboardURL, err)
}

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

then i'd have to return nil on 102 because err wouldn't be defined. either way

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

actually, i want to return the error and not just print it for proper exit codes. so then maybe i don't want to print it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

$ m apps open --path ../demos/tenth
can't open browser to URL https://dashboard.meroxa.io/apps/tenth/detail
Error: forcing

looks like this now

@janelletavares
Copy link
Contributor Author

janelletavares commented Mar 17, 2023

This already works great! One thing I noticed, that I'm not sure about if we should solve it: meroxa apps open currently only works in production application but wouldn't be something that we could use in other test environments, such as staging:

@jayjayjpg yeah, I noticed that too. Everywhere that we mention the dashboard in the CLI, the URL is hardcoded to the prod version, so i think we're stuck with this for now, or we'd have to change something across the board (maybe checking one of the environment variables, which would be a small ticket) to have testing support for staging URLs.

@jayjayjpg
Copy link
Contributor

@jayjayjpg yeah, I noticed that too. Everywhere that we mention the dashboard in the CLI, the URL is hardcoded to the prod version, so i think we're stuck with this for now, or we'd have to change something across the board (maybe checking one of the environment variables, which would be a small ticket) to have testing support for staging URLs.

@janelletavares Sounds good and thank you for confirming!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants