docs: add LEARNING.md with development insights\n\n- Initial commit of LEARNING.md to track mistakes and solutions.\n\n🤖 Generated with Gemini CLI\nCo-Authored-By: Gemini <noreply@google.com>

This commit is contained in:
2025-09-04 11:27:01 -05:00
parent d74cdc091b
commit fd910f1a72

33
LEARNING.md Normal file
View File

@@ -0,0 +1,33 @@
# Learning Log - Gemini CLI
This document records mistakes made during interactions and their corresponding solutions, aiming to improve future performance and accuracy.
## Docker and File Operation Mistakes
### 1. `config.yaml` not found during Docker build
- **Mistake**: Assumed `config.yaml` would be present for `COPY` instruction in Dockerfile when it was dynamically generated by `start.sh` at runtime.
- **Solution**: Created a placeholder `config.yaml` file in the build context to satisfy the `COPY` instruction during the Docker build process. The `start.sh` script then overwrites this placeholder with the dynamically generated content.
### 2. `apt-get` permission denied during Docker build
- **Mistake**: Encountered `E: Could not open lock file /var/lib/apt/lists/lock - open (13: Permission denied)` during `apt-get update` or `install` in Dockerfile.
- **Solution**: Explicitly set `USER root` before `apt-get` commands in the Dockerfile to ensure they run with necessary privileges. Also, ensured `DEBIAN_FRONTEND=noninteractive` was used to prevent interactive prompts.
### 3. `chown: invalid user: 'cloudron:cloudron'`
- **Mistake**: Attempted to change ownership of files to `cloudron:cloudron` before the `cloudron` user and group were created in the Docker image.
- **Solution**: Added explicit `RUN groupadd -r cloudron && useradd -r -g cloudron cloudron` commands in the Dockerfile *before* the `chown` instruction to ensure the user and group exist.
### 4. `docker run -it` "the input device is not a TTY"
- **Mistake**: Attempted to run Docker containers with `-it` flags in a non-interactive environment, leading to TTY errors.
- **Solution**: For running containers in the background, use detached mode (`-d`) and rely on `docker logs` or `docker cp` for inspecting output and files. Avoid `-it` unless a true interactive terminal session is required and supported by the environment.
### 5. `replace` tool "No changes to apply" or "Expected 1 occurrence but found X"
- **Mistake**: Provided `old_string` to the `replace` tool that either did not exactly match the target text or matched multiple times, leading to failed or unintended operations.
- **Solution**: Always read the file content immediately before using `replace` to obtain the *exact* `old_string` (including all whitespace, indentation, and line endings). For complex blocks or when multiple matches are a risk, consider overwriting the entire file content using `write_file` if appropriate for the context.
### 6. `start.sh` duplication
- **Mistake**: Unintended duplication of script content within `start.sh` due to imprecise `replace` operations, where a section of the script was inadvertently appended to itself.
- **Solution**: When making significant structural changes or large modifications to a script, it is safer and more reliable to read the entire file, perform the modifications in memory, and then overwrite the entire file using `write_file`.
### 7. APISIX etcd connection issues (local testing)
- **Mistake**: Presumed APISIX would run in a truly standalone mode for local testing without an etcd instance, or that `localhost` would correctly resolve to a host-exposed etcd port from within the container.
- **Solution**: For local testing of applications with external dependencies like etcd, explicitly spin up the dependent service in a separate container. Connect the application container to the dependency container using a user-defined Docker network and refer to the dependency by its service name (e.g., `apisix-etcd`) as the hostname. This accurately simulates the Cloudron environment where addons are provided as networked services.