Skip to content

APP-8173: Make local testing for viam apps easier #5036

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

Draft
wants to merge 7 commits into
base: main
Choose a base branch
from
Draft

Conversation

jr22
Copy link
Member

@jr22 jr22 commented Jun 5, 2025

APP-8173

Work done

  • Created a new CLI command for testing viam apps locally viam module local-app-testing
  • Running this command opens a go server that has a page where you can enter in api key info, hostname and the local address for your app.
  • Once youve entered this info, it redirects you to your local app so you can make sure everythings working properly

Things this doesnt do

  • It wont catch issues with proxying (like having the base set in your vite config) I think thats fine if that is something we only catch when you deply

Ask for reviewers

Can you please manually test with a viam app that you have? Will require the following steps:

  1. pull this branch
  2. run your application locally
  3. build the CLI: go build -o ~/go/bin/viam cli/viam/main.go
  4. run the new command: go run cli/viam/main.go module local-app-testing
  5. enter in machine info in the browser window that is opened
  6. ensure you can locally test your app!
Screenshot 2025-06-05 at 3 16 59 PM

@viambot viambot added the safe to test This pull request is marked safe to test from a trusted zone label Jun 5, 2025
@jr22 jr22 requested a review from bashar-515 June 5, 2025 19:21
@@ -0,0 +1,82 @@
package cli
Copy link
Member Author

Choose a reason for hiding this comment

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

a lot of this file is autogenerated by cursor so keep 👀 for stupid stuff

@@ -0,0 +1,470 @@
<!DOCTYPE html>
Copy link
Member Author

Choose a reason for hiding this comment

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

same here. lots of vibe coding

const hostnameString = document.getElementById('hostname').value;
const machineCookie = JSON.stringify({id: apiKeyId, key: apiKey, hostname: hostnameString});
const machineIdCookie = `${machineIdString}=${machineCookie}; path=/; domain=localhost; SameSite=Lax`;
const currentMachineCookie = `currentMachine=${machineIdString}; path=/; domain=localhost; SameSite=Lax`;
Copy link
Member Author

@jr22 jr22 Jun 5, 2025

Choose a reason for hiding this comment

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

NOTE FOR MANUAL TESTING: this assumes your local application is using the currentMachine cookie for testing. might have to update your application to pull that instead of the machine id from the URL

@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Jun 5, 2025
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Jun 5, 2025
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Jun 5, 2025
@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Jun 9, 2025
@jr22
Copy link
Member Author

jr22 commented Jun 9, 2025

@bashar-515 this is ready for manual testing! will move it out of "draft" mode once youve confirmed with manually testing an app of yours that this works as expected

Copy link
Member

@bashar-515 bashar-515 left a comment

Choose a reason for hiding this comment

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

So does this mean that in development I should NOT look to the path to retrieve either the hostname or machine ID but then in prod I should? Is there any way we can avoid making the developer have distinct code for different environments?

@viambot viambot added safe to test This pull request is marked safe to test from a trusted zone and removed safe to test This pull request is marked safe to test from a trusted zone labels Jun 20, 2025
@jr22 jr22 requested a review from ohEmily June 20, 2025 18:11
@jr22
Copy link
Member Author

jr22 commented Jun 20, 2025

@bashar-515 thanks for the feedback! something was wrong in my localapp that was causing this to work before when it shouldn't have. try again! will move out of draft mode once you've had a chance to test this and verify it works. then we can get into cleaning up the code :)

@ohEmily
Copy link
Member

ohEmily commented Jun 20, 2025

So does this mean that in development I should NOT look to the path to retrieve either the hostname or machine ID but then in prod I should? Is there any way we can avoid making the developer have distinct code for different environments?

this is exactly how Gambit is set up today and I filed a ticket in their thing to align the experiences, full circle

@@ -2479,6 +2479,24 @@ Note: There is no progress meter while copying is in progress.
UsageText: createUsageText("module", nil, false, true),
HideHelpCommand: true,
Subcommands: []*cli.Command{
{
Name: "local-app-testing",
Copy link
Member

Choose a reason for hiding this comment

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

[nit] subcommand seems longer than necessary? e.g. local-test

@ohEmily
Copy link
Member

ohEmily commented Jun 20, 2025

Something I'm not understanding but want to make sure to bring up now since the CLI is shipped software and we can't hit "undo" with releases the way we can with our cloud software.

[q] What is the advantage of adding support for this UI versus a local testing environment that supports integrating into a Viam auth app? Reading from the Viam auth cookie is one of the main integration points for anyone building out a Viam App so I feel that local testing isn't all too useful without that support.

@jr22
Copy link
Member Author

jr22 commented Jun 20, 2025

Something I'm not understanding but want to make sure to bring up now since the CLI is shipped software and we can't hit "undo" with releases the way we can with our cloud software.

[q] What is the advantage of adding support for this UI versus a local testing environment that supports integrating into a Viam auth app? Reading from the Viam auth cookie is one of the main integration points for anyone building out a Viam App so I feel that local testing isn't all too useful without that support.

does gambit use the auth cookie and not the machine credentials? i dont think we expose any documentation or guarantees about how were storing that information etc.

@ohEmily
Copy link
Member

ohEmily commented Jun 20, 2025

Something I'm not understanding but want to make sure to bring up now since the CLI is shipped software and we can't hit "undo" with releases the way we can with our cloud software.
[q] What is the advantage of adding support for this UI versus a local testing environment that supports integrating into a Viam auth app? Reading from the Viam auth cookie is one of the main integration points for anyone building out a Viam App so I feel that local testing isn't all too useful without that support.

does gambit use the auth cookie and not the machine credentials?

Sorry I don't understand this question. I'll try to rephrase to see if we can get clarity.

We just cut Gambit over to extracting the API key, machine ID, and hostname stored in the cookie -- that was the message I sent over Slack. What I'm saying is that -- because they are unable to support authenticating on localhost, they instead display a page to pop in an API key ID and auth entity (key string). This has the unfortunate consequence of making it impossible to test auth changes outside of a cloud environment for them.

@ohEmily
Copy link
Member

ohEmily commented Jun 20, 2025

replaces the part of the Gambit onboarding flow that asks you to do this:

### 3. Start and access the frontend
1. (from a new terminal window) start the frontend by running `make dev-frontend`.
2. Put together a URL of the following format, pulling from the remote fragment overwrite above:

http://localhost:5173/?host=your-machine-dev.example.cloud&api-key=your-key&authEntity=your-entity&suffix=-dev

> Make sure the url has the `&suffix=-dev` suffix or the developer machine will not work
3. Open the URL above from your browser.

Comment on lines +2492 to +2496
&cli.StringFlag{
Name: "app-url",
Usage: "url where local app is running",
Required: true,
},
Copy link
Member

@ohEmily ohEmily Jun 20, 2025

Choose a reason for hiding this comment

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

[q] why do we need this? why isn't it just localhost?

Copy link
Member Author

Choose a reason for hiding this comment

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

feedback from sync emily call: can we make them both port otherwise it seems like theyre more connected

Comment on lines +221 to +222
apiKey: document.getElementById('apiKey').value.trim(),
apiKeyId: document.getElementById('apiKeyId').value.trim(),
Copy link
Member

Choose a reason for hiding this comment

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

should this maybe be nested to follow the same schema as the auth cookie?

@ohEmily
Copy link
Member

ohEmily commented Jun 20, 2025

tl;dr from huddle is that this code will get moved out of RDK and into Viam Apps so folks can import as a library, better versioning, and allow us to be more careful with additive features

@jr22
Copy link
Member Author

jr22 commented Jun 20, 2025

@bashar-515 actually, no need to look at this yet. i spoke to @ohEmily and our biggest takeaway is that we probably should have most of this code live alongside viam apps and not in the CLI. then we can import the shared code and things wont get as out of sync

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
safe to test This pull request is marked safe to test from a trusted zone
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants