Error: login failed: sign in request failed: request failed with status 400:
"minimum string length is 3" (at /password)
```
The CLI surfaces a clear, actionable error. Exit code is `1`.
> **Note:** The raw OpenAPI schema validation error is exposed directly to the user. A more user-friendly message such as `"Invalid email or password"` would improve UX.
Error: multiple apps named 'pem-inclusion-test' — use 'gy list apps' to see them all
```
The **duplicate names bug** (previously documented for `gy delete app`) also affects `gy logs`. Any command that resolves apps by friendly name is impacted. Running `gy logs` **from within the project directory** (without specifying a name) correctly resolves the app and works as expected.
> **Bug:** The CLI should warn or refuse to deploy an empty directory, not silently deploy a broken container. An empty deployment wastes resources and may confuse users who expect a valid running application.
---
### 7. PEM & secrets.json File Inclusion
| Field | Details |
|---|---|
| **Command** | `gy deploy --debug` |
| **Test** | Verified whether `.pem` private key and `secrets.json` are included in the deployed container |
| **Result** | ❌ Fail — both files appear in container |
**Steps:**
1. Created a project containing `fake_key.pem` (RSA private key format) and `secrets.json` (fake DB password).
2. Deployed without a `.dockerignore`.
3. Inspected container via `gy logs --no-follow`.
**Output (logs):**
```
=== FILE LIST ===
-rw-rw-r-- Dockerfile
-rw-rw-r-- fake_key.pem
-rw-rw-r-- secrets.json
=== PEM CHECK ===
-----BEGIN RSA PRIVATE KEY-----
FAKEFAKEFAKEFAKEFAKEFAKE
-----END RSA PRIVATE KEY-----
=== SECRETS CHECK ===
FAKE_DB_PASSWORD=supersecret123
```
> **Security Issue:** This confirms that the sensitive file inclusion problem is not limited to `.env` files. **Any file** — including private keys (`.pem`, `id_rsa`) and JSON secrets — is included in the deployed container if no `.dockerignore` is configured. The CLI provides no warning about sensitive files.
The `ARG` value is **empty at runtime** because Docker `ARG` variables are scoped to the build stage and are not inherited by the running container unless explicitly promoted to `ENV`.
> **Note:** While `ARG` secrets are not exposed at container runtime, they **can appear in the Docker build history** (`docker history --no-trunc`). The CLI still produced no warning about the `ARG` instruction containing a secret-like value.
---
## Verdict Summary Table
## Verdict Summary Table
| Test | Command | Status | Notes |
| Test | Command | Status | Notes |
@@ -543,10 +729,18 @@ Application started
| Go Web Deploy | `gy deploy --port=8000` | ✅ Pass | Auto-detected + deployed |
| Go Web Deploy | `gy deploy --port=8000` | ✅ Pass | Auto-detected + deployed |
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
