[Feature]: Share environment when starting new tasks on the same repository

[mauriciogior]

I'm testing this out on a very large repository that takes some time to setup. The build files are large and it has to install a bunch of packages to boot it up.

I was thinking of either having a shared environment option when starting tasks from the same repository or having a template environment that we can use when starting a new task.

If you find this feature request or enhancement useful, make sure to add a 👍 to the issue

[mauriciogior]

A "fork" option could work:

[enyst]

You could make a custom docker image, and run the runtime container from it

Or, could write a setup.sh script, placed in .openhands, in the repo, to run every time the agent starts working with the repo, but that doesn't help much with time.

[thefaftek-git]

Are you just looking for dependencies to be pre-installed or for your app to be fully built? In both scenarios, @enyst 's custom docker image would probably be your best bet.

If building/maintaining a custom image is a bit more overhead than you're hoping for, would adding an option to auto-generate a container based on your setup.sh one-time and allow selecting the container to use for an image be what you're hoping to get?

[llamantino]

I was wondering the same thing, actually. Even just having a way to reset the chat while reusing the same container would help a lot.

Reusing the container is faster than creating a new one, avoids reinstalling shared dependencies across tasks, and prevents having to reload files if you’re not using a shared folder with the host. It does make me wonder if creating a new container for each chat is always necessary. Reusing one could be a better default in some scenarios.

[mauriciogior]

Yes, resetting the chat would be amazing, it'd be a nice addition that wouldn't require much development. Ideally we could have a "Start new conversation" that would "duplicate" the user current conversation with same environment, but fresh context.

[jpelletier1]

Marking this related to #8989

I totally empathize with this scenario when using OH OSS. The problem isn't as bad with OH Cloud, but we want to make sure the experience is great for OH OSS users who may have customized their runtimes. Ultimately, the core user problem is runtimes can be slow to start, so reuse may be an acceptable trade-off if it means you can clear the conversation context and start again.

Some solutions I have heard:

• Reset an existing conversation
• Associate runtimes with repos, and allow reuse if the conversation is also using that repo (larger effort)
• Fork a conversation that re-uses runtime (related #8560)

What else am I missing?

[llamantino]

You could also consider pre-warming containers and supporting a container initialization script in the settings, that would be executed right after container creation. This would be dead simple for users (just copy-paste their usual setup commands) and relatively fast to implement as a temporary fix.

Note: be sure to discard any pre-warmed container if the settings change, since they're passed at runtime creation.

Another option: allow users to snapshot containers via docker commit, and select a previously saved image as the base in their settings. This could create issues with older runtime updates becoming incompatible with newer app releases though.

[github-actions[bot]]

This issue is stale because it has been open for 30 days with no activity. Remove stale label or comment or this will be closed in 7 days.

[github-actions[bot]]

This issue is stale because it has been open for 40 days with no activity. Remove the stale label or leave a comment, otherwise it will be closed in 10 days.

[github-actions[bot]]

This issue is stale because it has been open for 40 days with no activity. Remove the stale label or leave a comment, otherwise it will be closed in 10 days.

[github-actions[bot]]

This issue was automatically closed due to 50 days of inactivity. We do this to help keep the issues somewhat manageable and focus on active issues.