feat: document agent images #298
Conversation
da61352 to
15e56d6
Compare
15e56d6 to
0a98754
Compare
Angelmmiguel
left a comment
There was a problem hiding this comment.
Sorry, but I didn't make the purpose of this file explicit. I agree with the content, but I'm missing the technical details and the decisions behind them.
docs/agent-images.md
Outdated
| Agents in Rover run in isolated environments, as much as possible. The | ||
| idea behind this strategy is that the agent can make as many changes | ||
| as it needs in order to improve, implement, build, check, test... on a | ||
| given project, without impacting the host machine. | ||
|
|
||
| When Rover runs, it is possible to choose what image will be used to | ||
| spawn the agent in. This gives flexibility to have specific OS's | ||
| (e.g. Alpine, Debian, Ubuntu), as well as some core tooling already | ||
| installed for the project, what will increase development speed, | ||
| because the agent won't need to install new packages. |
There was a problem hiding this comment.
Overall, I agree with the content of this file. Your proposal about having an agent-dev and agent images sounds good to me. However, some of the details I see in this document have a different target audience imo.
The documentation files in ./docs focus on the tool (Rover) development. It includes details that will be helpful for developers and AI agents contributing to the Rover codebase. The end-user documentation will be available in https://docs.endor.dev/.
These files might point to relevant articles in the public documentation site, but the content should be tailored to contributing to Rover.
I took these two paragraphs as an example. Here, I see some relevant information to understand how Rover manages multiple sandbox images. Some relevant details are missing, like why we technically chose alpine, and other details are not relevant.
| Agents in Rover run in isolated environments, as much as possible. The | |
| idea behind this strategy is that the agent can make as many changes | |
| as it needs in order to improve, implement, build, check, test... on a | |
| given project, without impacting the host machine. | |
| When Rover runs, it is possible to choose what image will be used to | |
| spawn the agent in. This gives flexibility to have specific OS's | |
| (e.g. Alpine, Debian, Ubuntu), as well as some core tooling already | |
| installed for the project, what will increase development speed, | |
| because the agent won't need to install new packages. | |
| Agents in Rover run in isolated environments ([sandbox](https://docs.endor.dev/rover/concepts/sandbox/)). | |
| These environments give agents a way to modify the environment | |
| to improve, implement, build, check, and test a given project, | |
| without impacting the host machine. | |
| Rover uses Alpine linux as the base image for the default sandbox | |
| images we provide. The main reason is to keep these images minimal | |
| and give agents access to a rich package ecosystem (`apk`). We are | |
| considering Debian as a future alternative because it's more developer | |
| friendly and to fix some issues with `glibc` dependant tools like `cursor`. |
Then, I would add a separate section about Custom images where we add some information about how we handle it internally (environment variable vs parameter vs rover.json).
docs/agent-images.md
Outdated
| Whenever we create a new tag in Rover, a new image will be pushed with | ||
| that tag name at: `ghcr.io/endorhq/rover/agent:<tag>`. | ||
|
|
||
| ## Using your own agent image |
There was a problem hiding this comment.
Same comment here. This seems to be end-user documentation. I would include here the different elements we add to the image and why. For example, here we are not mentioning we build the rover-agent tool and install it right away. Or the approach we took to work with cursor at a high level.
|
|
||
| - `/output`: mountpoint used by Rover to follow the task progress. | ||
|
|
||
| #### Sudo |
There was a problem hiding this comment.
Same here. I think the important idea here is why we are doing this. It should include details about Rootless vs rootful, the permission issues and how we fixed them.
docs/agent-images.md
Outdated
| ### Development images | ||
|
|
||
| The code at the `main` branch points to | ||
| `ghcr.io/endorhq/rover/agent-dev:latest`. Automation builds and pushes | ||
| to this image when a new commit is pushed to the `main` branch. | ||
|
|
||
| ### Tagged images | ||
|
|
||
| Whenever we create a new tag in Rover, a new image will be pushed with | ||
| that tag name at: `ghcr.io/endorhq/rover/agent:<tag>`. |
There was a problem hiding this comment.
I like this idea, but I miss some details about how we these images are built (I know it will be in the future, but we can still document it already).
For example, currently the git tags are created after we bump the version and commit the change in a GitHub action. What would be the process with this new image system?
Angelmmiguel
left a comment
There was a problem hiding this comment.
LGTM!! Thanks for documenting it 😄
Closes: #296