162 أسطر
8.9 KiB
Plaintext
162 أسطر
8.9 KiB
Plaintext
CLI Test
|
|
|
|
|
|
Version
|
|
|
|
Command: gy version
|
|
Result: Successfully displayed the installed CLI version and confirmed that it is up to date.
|
|
Output:
|
|
Ghaymah CLI v0.0.24
|
|
You're up to date!
|
|
Verdict: Works as expected. The CLI correctly reports its current version and update status
|
|
|
|
Help
|
|
|
|
Command: gy --help
|
|
Result: Successfully displayed the CLI description, available commands, usage examples, and global flags.
|
|
Verdict: Works as expected. The help command provides clear information about the available commands and CLI options.
|
|
Login
|
|
Command: gy login
|
|
Result: Logged in successfully (or gy signup if no account yet — email is the one used for the Ghaymah account).
|
|
|
|
Logout
|
|
|
|
Command: gy logout
|
|
Result: Logout succeeded, but a warning appeared first:
|
|
Remote sign-out call failed with 400 error: "refreshToken" is required
|
|
CLI still cleared local config and confirmed: ✅ Logged out
|
|
Verdict: Non-blocking issue. Logout succeeds locally, but the remote sign-out request should be fixed to include the required refreshToken.
|
|
|
|
Signup
|
|
|
|
Command: gy signup
|
|
Result: Account created successfully and auto-logged in
|
|
Same info log appeared: "config file not found, using defaults" (normal, non-issue)
|
|
Output: ✅ Account created! Logged in as username@gmail.com
|
|
Verdict: Works as expected. Signup creates account + logs in in one step.
|
|
|
|
Whoami
|
|
|
|
Command: gy whoami
|
|
Result: Successfully displayed the currently authenticated user's email and User ID.
|
|
Output:
|
|
✅ Logged in as username@gmail.com
|
|
User ID: also shown
|
|
Verdict: Works as expected. The command correctly identifies the currently logged-in user and displays the associated User ID. No security issue since no authentication tokens or secrets are exposed.
|
|
|
|
List
|
|
|
|
Command: gy list
|
|
Result: Successfully retrieved the projects associated with the authenticated account.
|
|
Output:
|
|
[proj] synced ghaymah-exam-mahmoud-secops
|
|
Verdict: Works as expected. The command successfully lists the available projects and correctly shows their synchronization status.
|
|
|
|
Tunneling
|
|
|
|
Command: gy tunnel start <name>
|
|
Requirements: A successfully deployed application with a reachable configured port.
|
|
Steps: Started the tunnel for the deployed application. The tunnel incorrectly targeted localhost:8080 instead of the configured application port, then returned an empty tunnel URL.
|
|
Result: Tunnel was reported as live, but the endpoint was unreachable.
|
|
Output: Tunnel is live at: https://
|
|
Verdict: Does not work as expected due to incorrect port handling and an invalid tunnel URL
|
|
|
|
Delete
|
|
|
|
project
|
|
Command: gy delete project ghaymah-exam-mahmoud-secops
|
|
Result: Confirmation prompt appeared → confirmed with y
|
|
Output: ✅ Deleted project 'ghaymah-exam-mahmoud-secops'
|
|
Verdict: Works as expected. Project and all its apps deleted successfully with confirmation step.
|
|
|
|
app
|
|
Command: gy delete app <name>
|
|
Requirements: An existing app with a unique name.
|
|
Steps: Tested deleting an app using its name. The delete operation works correctly, but duplicate app names can cause ambiguity when identifying the target app.
|
|
Result: App deletion works as expected, but duplicate names make app selection unreliable.
|
|
Output: Successful deletion / ambiguous target when duplicate names exist.
|
|
Verdict: Works as expected for unique app names; duplicate names should be prevented or handled to avoid ambiguity.
|
|
|
|
Deployment
|
|
|
|
Node.js Deployment
|
|
|
|
Command: gy deploy
|
|
Requirements: A package.json, package-lock.json, and a web server listening on port 8080.
|
|
Steps: Created a minimal Node.js Hello World project, initially tested without a lockfile and got an npm ci error, then generated package-lock.json. The first runtime test also failed because index.js was missing and later returned 502 because the app was not listening on port 8080. Updated index.js to run an HTTP server on port 8080, then redeployed and verified with gy config, gy logs, and the deployed URL.
|
|
Result: Successfully detected, built, and deployed the Node.js application.
|
|
Output: Hello from Node.js!
|
|
Verdict: Works as expected after meeting the required Node.js project and runtime requirements.
|
|
|
|
Flask Deployment
|
|
|
|
Command: gy deploy --port=5000
|
|
Requirements: A Flask application with a web server listening on the configured port.
|
|
Steps: Initially tested the Flask application using the default port 8080, which resulted in a 502 Bad Gateway. Changed the application to listen on port 5000, then deployed using gy deploy --port=5000 and verified that the deployment completed successfully.
|
|
Result: Successfully detected, built, and deployed the Flask application after configuring the correct port.
|
|
Output: Deployed successfully with the configured port 5000.
|
|
Verdict: Works as expected when the application port matches the configured deployment port
|
|
|
|
Go Deployment
|
|
|
|
Command: gy deploy
|
|
Requirements: A valid Go project. The test application is a simple non-web Go program that prints Hello from Go!.
|
|
Steps: Deployed the Go application using the CLI-generated Dockerfile. The project was created successfully, and the deployment artifact was built and uploaded successfully. However, resource creation failed with a resources_pkey uniqueness violation. In an earlier deployment attempt, the CLI also waited for 15 minutes before timing out, while gy logs go-test showed Hello from Go!.
|
|
Result: The application produced logs, but the deployment could not be confirmed as successfully completed in the cloud.
|
|
Output: resources_pkey uniqueness violation / deployment timeout after 15 minutes / Hello from Go!
|
|
Verdict: Does not work as expected: the CLI successfully detects, builds, and uploads the Go application, but deployment does not complete successfully and the CLI leaves the deployment state inconsistent.
|
|
|
|
Go Web Deployment
|
|
|
|
Command: gy deploy --port=8000
|
|
|
|
Requirements: A Go web application with an HTTP server listening on the configured port.
|
|
|
|
Steps: Created a minimal Go HTTP server using net/http that listens on port 8000 and returns a Hello World response. Deployed the application without providing a Dockerfile to test the CLI's Go detection and automatic Dockerfile generation.
|
|
|
|
Result: The CLI successfully detected the Go web application, generated the Dockerfile, built the deployment artifact, and deployed the application successfully.
|
|
|
|
Output: Hello from Go Web!
|
|
|
|
Verdict: Works as expected. The CLI successfully detects, builds, and deploys a Go web application when the application listens on the configured port.
|
|
|
|
FastAPI Deployment
|
|
|
|
Command: gy deploy --port=8000
|
|
Requirements: A FastAPI application with Uvicorn listening on 0.0.0.0:8000.
|
|
|
|
Steps: Initially deployed the FastAPI application using the CLI-generated Dockerfile. Deployment completed successfully, but accessing the generated URL resulted in a 502 Bad Gateway. Investigation showed that the auto-generated Dockerfile used CMD ["sh", "-c", "python main.py"], while main.py only defines the FastAPI application and does not start a web server. The application was then verified locally using Uvicorn with uvicorn main:app --host 0.0.0.0 --port 8000, which successfully served the application.
|
|
|
|
Result: Deployment infrastructure completed successfully, but the generated Dockerfile did not start the FastAPI server correctly, resulting in a 502 Bad Gateway.
|
|
|
|
Output: Deployment completed successfully, but the generated URL returned 502 Bad Gateway.
|
|
|
|
Verdict: Partial / CLI issue — FastAPI deployment succeeds, but the auto-generated Dockerfile incorrectly starts python main.py instead of Uvicorn, causing the deployed application to be unreachable.
|
|
|
|
Problems
|
|
|
|
Duplicate Names Problem
|
|
|
|
Duplicate app names cause ambiguity during deletion: gy delete app <NAME> relies only on the friendly name, so multiple apps with the same name cannot be uniquely targeted. The CLI should either prevent duplicate app names or support deletion by a unique resource ID / interactive selection.
|
|
|
|
Auto listening port problem
|
|
|
|
Incorrect port detection: The CLI assumes port 8080 by default, but applications may listen on a different port, causing deployment failures such as 502 Bad Gateway. The CLI should detect the actual application port or provide a clearer configuration mechanism.
|
|
|
|
Tunneling problem
|
|
|
|
Hardcoded 8080 port instead of using the configured application port.
|
|
Empty tunnel URL returned (https://).
|
|
Tunnel is reported as live despite being unreachable.
|
|
Tunnel port is not synchronized with the deployment configuration.
|
|
|
|
Deployment Timeout / Inconsistent State
|
|
|
|
The Go deployment timed out after 15 minutes, even though the application appears to be running and producing logs. The CLI does not clearly confirm the app's deployment status in the cloud, leaving the deployment state inconsistent.
|
|
|
|
FastAPI Auto-Generated Dockerfile Problem
|
|
|
|
The CLI successfully detects FastAPI and generates a Dockerfile, but the generated Dockerfile uses CMD ["sh", "-c", "python main.py"]. Since the FastAPI application only defines the app object and does not start a web server, the container does not listen on the configured port, resulting in 502 Bad Gateway. The CLI should generate a FastAPI-compatible command such as Uvicorn with 0.0.0.0 and the configured port.
|
|
|
|
|