feat: Integrate Git functionality and enable container-based agent support

[TheApeMachine]

WIP: This commit is still under development and not all features are fully implemented.
Just opening an early PR to get feedback on the approach, and maybe someone wants to join in.

This is based off some work I have been doing in my own project, only that uses Go. The basic idea is to let the LLMs loose inside Docker containers, where they get to use the full power of the OS. Their prompting mechanism is hooked up to stdout and stderr of the container, and their responses are fed back into the stdin. This has worked really well in my project, and I think it's a great way to let the LLMs interact with the code, without messing things up. The have shown to be very capable of using Git workflows as well.

We can prompt them to use a specific Git flow, and always work on a branch, create early PRs, etc.

If you also implement Github WebHooks, you could even create a cycle of development and code review. All AI.

• Git Integration:

  • Extended ActionType to include git actions.
  • Implemented GitAction type in actions.ts to handle repository URL, branch creation, commit messages, and pull requests.
  • Updated ActionRunner to process Git actions, including cloning repositories, creating branches, committing changes, pushing to remote, and creating pull requests via GitHub API.
  • Added DockerGitActionForm component to the frontend for users to input Git-related details and initiate Git actions.

• Docker Enhancements:

  • Created a custom Docker image (my-node-git:latest) with Git installed to support Git operations within containers.
  • Updated DockerService to utilize the custom Docker image for Git-related actions.
  • Ensured Docker containers are properly managed and cleaned up after executing Git commands to prevent resource leaks.

• Security Improvements:

  • Implemented secure handling of GitHub tokens, recommending the use of OAuth for enhanced security.
  • Added environment variables for GitHub OAuth credentials.

• Documentation:

  • Updated README.md to include instructions on using the new Git integration features.
  • Provided examples and important notes regarding token security and permissions.

• Testing:

  • Added unit tests for Git actions in action-runner.spec.ts to ensure reliability and handle error scenarios.

This commit enhances Bolt.new by enabling AI agents to interact with Git repositories directly from Docker containers, facilitating automated branch management and pull request creation. These features streamline the development workflow, allowing for more efficient version control and collaboration.

[wonderwhy-er]

This makes this repo fully local.

I am interested in hosting such things online, meaning that it should work in a browser/worker
Docker would not be available, right?

I never tried anything with git purely from frontends or through the backend
But what I want to look at is
https://isomorphic-git.org/

[TheApeMachine]

This makes this repo fully local.

I am interested in hosting such things online, meaning that it should work in a browser/worker Docker would not be available, right?

I never tried anything with git purely from frontends or through the backend But what I want to look at is https://isomorphic-git.org/

Could use Kubernetes for running containers, depends on what you mean by hosting online... I mean, you can install Docker on any virtual machine, if you have control over it. I will look into providing an alternate option though keeping in mind a non-local situation :)

[wonderwhy-er]

This makes this repo fully local.
I am interested in hosting such things online, meaning that it should work in a browser/worker Docker would not be available, right?
I never tried anything with git purely from frontends or through the backend But what I want to look at is https://isomorphic-git.org/

Could use Kubernetes for running containers, depending on what you mean by hosting online... I mean, you can install Docker on any virtual machine, if you have control over it. I will look into providing an alternate option though keeping in mind a non-local situation :)

But then you would need the ability to spawn those containers per user, may be even multiple per user if he is working on multiple things at the same time.
I am not DevOps enough to know how to do something like that.

I have a feeling there are two types of "demand" from open-source Bolt.New
Running it locally for yourself.
And running it online for others.

I wonder if it even makes sense to try to do both and I wonder which demand is bigger. Could be that its running it locally.

[Felitendo]

I would say running it online for others is a way higher demand.
I would love to work on my projects in remote

[hillct]

This makes this repo fully local.
But then you would need the ability to spawn those containers per user, may be even multiple per user if he is working on multiple things at the same time. I am not DevOps enough to know how to do something like that.

I have a feeling there are two types of "demand" from open-source Bolt.New Running it locally for yourself. And running it online for others.

I wonder if it even makes sense to try to do both and I wonder which demand is bigger. Could be that its running it locally.

If I understand your thinking here, you would deploy Bolt.new in a docker container, and expose the docker socket (file) to the container, such hat the bolt.new application could itself, issue docker commands (via the docker API) to be run on the parent bare metal/VM. This is the approach taken by Coolify in their efforts to crate a deployment management platform much like hat offered by Vercel. This use case could be either much simplified, or alternatively, forego local docker management entirely in favor of integration with the likes of Coolify, at the Git actions/triggers level and avoid the hassles associated with reinventing the wheel.

[TheApeMachine]

This makes this repo fully local.
I am interested in hosting such things online, meaning that it should work in a browser/worker Docker would not be available, right?
I never tried anything with git purely from frontends or through the backend But what I want to look at is https://isomorphic-git.org/

Could use Kubernetes for running containers, depending on what you mean by hosting online... I mean, you can install Docker on any virtual machine, if you have control over it. I will look into providing an alternate option though keeping in mind a non-local situation :)

But then you would need the ability to spawn those containers per user, may be even multiple per user if he is working on multiple things at the same time. I am not DevOps enough to know how to do something like that.

I have a feeling there are two types of "demand" from open-source Bolt.New Running it locally for yourself. And running it online for others.

I wonder if it even makes sense to try to do both and I wonder which demand is bigger. Could be that its running it locally.

Docker just has an API, so you don't need to to anything manually, you can just use the library not only to build and run a container, you could even configure it, as in you would not need a dockerfile. The question otherwise is, how are you going to let the AI work on your code, without being in your way? It is the same dilemma the cursor people are dealing with.

[TheApeMachine]

This makes this repo fully local.
But then you would need the ability to spawn those containers per user, may be even multiple per user if he is working on multiple things at the same time. I am not DevOps enough to know how to do something like that.

I have a feeling there are two types of "demand" from open-source Bolt.New Running it locally for yourself. And running it online for others.
I wonder if it even makes sense to try to do both and I wonder which demand is bigger. Could be that its running it locally.

If I understand your thinking here, you would deploy Bolt.new in a docker container, and expose the docker socket (file) to the container, such hat the bolt.new application could itself, issue docker commands (via the docker API) to be run on the parent bare metal/VM. This is the approach taken by Coolify in their efforts to crate a deployment management platform much like hat offered by Vercel. This use case could be either much simplified, or alternatively, forego local docker management entirely in favor of integration with the likes of Coolify, at the Git actions/triggers level and avoid the hassles associated with reinventing the wheel.

There is a multitude of options. You could run Docker in Docker (DinD), you could even run Kubernetes in Docker (Kind, wich is what the k8s team uses in their test workflows), you could probably also do this entirely without docker, I figured I'd start with what I knew :) I had actually not considered the whole online/offline thing, I just saw a feature I happen to be working on myself, so it was a natural switch to make I guess.

[TheApeMachine]

I would say running it online for others is a way higher demand. I would love to work on my projects in remote

Why not use a CloudFlare tunnel, or ngrok or something?

[TheApeMachine]

This makes this repo fully local.
But then you would need the ability to spawn those containers per user, may be even multiple per user if he is working on multiple things at the same time. I am not DevOps enough to know how to do something like that.

I have a feeling there are two types of "demand" from open-source Bolt.New Running it locally for yourself. And running it online for others.
I wonder if it even makes sense to try to do both and I wonder which demand is bigger. Could be that its running it locally.

If I understand your thinking here, you would deploy Bolt.new in a docker container, and expose the docker socket (file) to the container, such hat the bolt.new application could itself, issue docker commands (via the docker API) to be run on the parent bare metal/VM. This is the approach taken by Coolify in their efforts to crate a deployment management platform much like hat offered by Vercel. This use case could be either much simplified, or alternatively, forego local docker management entirely in favor of integration with the likes of Coolify, at the Git actions/triggers level and avoid the hassles associated with reinventing the wheel.

Maybe I am not understanding you fully, but what I was thinking (and doing in my own project) is not letting the AI execute on the bare metal, but the other way around. So let's say I have an "environment" tool for the AI, what it ultimately does:

Build container: https://github.com/TheApeMachine/amsh/blob/master/container/builder.go
Run container: https://github.com/TheApeMachine/amsh/blob/master/container/runner.go (hijacking stdin sdtout and stderr)

stdout and stderr are the output of the terminal inside the container, feed it in as the prompt for the AI. stdin is the terminal input mechanism, connect it to the response the AI generates. Give it the system prompt below, and it will happily start to use raw terminal commands like grep for searching code, and sed for making changes. Plus it will use git as you describe it in the system prompt.

System Prompt:
You are a helpful assistant that helps me debug my code...
You are currently inside an isolated environment that has the code I need to debug.
This means that when you see file paths, they are relative to /tmp/workspace.

	Start by cloning the repository:

	cd /tmp/workspace
	git clone [email protected]:UserName/project.git
	cd project

	Make sure to use the ssh method to clone the repository, not https. Your SSH key is set up in the container.

	You may have to do some git config stuff first, your username and email are:

	git config --global user.name "youtusername"
	git config --global user.email "youremail"

	You should always create a new git branch before making any changes, using the: aibugfix/<branchname> convention.
	You should also open a PR early, before making any changes, and keep it updated as you work.
	Each time you push to the PR, you will receive a code review, which can be used to guide your work.

	If you write any tests, which is a good idea, you should use Goconvey. You can run the tests with:
	
	go test -v ./...

	REMEMBER: 
	1. Not all Linux commands give an output, in such cases you should just check if the command was successful manually.
	2. Always know where you are in the filesystem, and what you current working directory contains.
	3. Using tree can be very helpful to get an overview of the filesystem.
	4. Install any dependencies you might need using the package manager, remember to update it first.
	5. Don't keep trying the same action over and over again, that's not how this works, switch strategy when you get stuck.
	
	You need to think, and reason your way through the problem, so after each tool call, and after each command execution,
	you should think about what you just did, and what the next best step is, and verify that you are on the right track.

[wonderwhy-er]

Never mind, I misunderstood what this does with docker.

[coleam00]

This looks phenomenal, thank you for working on this @TheApeMachine! I'll be following your progress here!

[github-actions]

This pull request has been marked as stale due to inactivity. If no further activity occurs, it will be closed in 7 days.