- Why the iPad Mini 7 is the ultraportable tablet to beat this holiday travel season - and it's $50 off
- The best iPads for college: Expert tested and reviewed
- One of the best mid-range sports watches I've tested is on sale for Black Friday
- This monster 240W charger has features I've never seen on other accessories (and get $60 off this Black Friday)
- This laptop power bank has served me well for years, and this Black Friday deal slashes the price in half
How an AI Assistant Can Help Configure Your Project’s Git Hooks | Docker
This ongoing Docker Labs GenAI series will explore the exciting space of AI developer tools. At Docker, we believe there is a vast scope to explore, openly and without the hype. We will share our explorations and collaborate with the developer community in real-time. Although developers have adopted autocomplete tooling like GitHub Copilot and use chat, there is significant potential for AI tools to assist with more specific tasks and interfaces throughout the entire software lifecycle. Therefore, our exploration will be broad. We will be releasing things as open source so you can play, explore, and hack with us, too.
Can an AI assistant help configure your project’s Git hooks?
Git hooks can save manual work during repetitive tasks, such as authoring commit messages or running checks before committing an update. But they can also be hard to configure, and are project dependent. Can generative AI make Git hooks easier to configure and use?
Simple prompts
From a high level, the basic prompt is simple:
How do I set up git hooks?
Although this includes no details about the actual project, the response from many foundation models is still useful. If you run this prompt in ChatGPT, you’ll see that the response contains details about how to use the .git/hooks
folder, hints about authoring hook scripts, and even practical next steps for what you’ll need to learn about next. However, the advice is general. It has not been grounded by your project.
Project context
Your project itself is an important source of information for an assistant. Let’s start by providing information about types of source code in a project. Fortunately, there are plenty of existing tools for extracting project context, and these tools are often already available in Docker containers.
For example, here’s an image that will analyze any Git repository and return a list of languages being used. Let’s update our prompt with this new context.
How do I set up git hooks?
{{# linguist }}
This project contains code from the language {{ language }} so if you have any
recommendations pertaining to {{ language }}, please include them.
{{/linguist}}
In this example, we use moustache templates to bind the output of our “linguist” analysis into this prompt.
The response from an LLM-powered assistant will change dramatically. Armed with specific advice about what kinds of files might be changed, the LLM will generate sample scripts and make suggestions about specific tools that might be useful for the kinds of code developed in this project. It might even be possible to cut and paste code out of the response to try setting up hooks yourself.
The pattern is quite simple. We already have tools to analyze projects, so let’s plug these in locally and give the LLM more context to make better suggestions (Figure 1).
Expertise
Generative AI also offers new opportunities for experts to contribute knowledge that AI assistants can leverage to become even more useful. For example, we have learned that pre-commit can be helpful to organize the set of tools used to implement Git hooks.
To represent this learning, we add this prompt:
When configuring git hooks, our organization uses a tool called
[pre-commit](https://github.com/pre-commit/pre-commit).
There’s also a base configuration that we have found useful in all projects. We also add that to our assistant’s knowledge base.
If a user wants to configure git hooks, use this template which will need to be written to pre-commit-config.yaml
in the root of the user's project.
Start with the following code block:
```yaml
repos:
- repo: http://github.com/pre-commit/pre-commit-hooks
rev: v2.3.0
hooks:
- id: check-yaml
- id: trailing-whitespace
- id: check-merge-conflict
- repo https://github.com/jorisroovers/gitlint
rev: main
hooks:
- id: gitlint
- repo: local
hooks:
```
Finally, as we learn about new tools that are useful for certain projects, we describe this information. For example, as an expert, I might want to suggest that teams using Golang include a particular linting tool in the Git hooks configuration.
If we detect `Go` in the project, add the following hook to the hooks entry in the `local` repo entry.
```yaml
id: golangcli-lint
name: golang cli
entry: golangci/golangci-lint
files "\.go$"
```
With these additions, the response from our assistant becomes precise. We have found that our assistant can now write hooks scripts and write complete YAML configuration files that are project-specific and ready to copy directly into a project.
Somewhat surprisingly, the assistant can also now recommend tools not mentioned explicitly in our prompts but that use the same syntax established for other tools. Using these examples, the LLM appears to be capable of extending the assistant’s capabilities to other tools. Using our examples as guidance, the LLM suggests new tools but still configures them using our suggested framework and syntax.
Most importantly, the response from the assistant is now not only actionable to the developer, saving them time, but it is also specific enough that we could pass the response to a simple agent to take the action automatically.
Adding tools
For this example, the only tool we really need is a file-writer. The change to our prompt is to add one instruction to go ahead and write the configuration into the project.
Write the final yaml content to our project at the path pre-commit-config.yaml. Write both the `pre-commit` and `commit-message` scripts to `git/hooks` and make them executable.
Besides the prompt, there is another crucial step that we are skipping at this point. The assistant must be told that it is capable of writing content into files. However, this is really just a registration step.
The important thing is that we can give our agent the tools it needs to perform tasks. In doing so, the response from the LLM undergoes a transition. Instead of text output, the LLM responds with instructions for our agent. If we’re using an OpenAI function call, we’ll see a request that looks something like the following .json file. It’s not meant to be read by us, of course. It’s an instruction to the agent that knows how to update your project for you.
{
"id": "call_4LCo0CQqCHCGGZea3qlaTg5h",
"type": "function",
"function": {
"name": "write_file",
"arguments": "{n "path": "pre-commit-config.yaml",n "content": "repos:\n - repo: http://github.com/pre-commi
t/pre-commit-hooks\n rev: v2.3.0\n hooks:\n - id: check-yaml\n - id: trailing-whitespace\n - id
: check-merge-conflict\n - repo https://github.com/jorisroovers/gitlint\n rev: main\n hooks:\n - id: gitlint\n
- repo: local\n hooks:\n - id: markdownlint\n name: markdown linter\n entry: markdownlint/mar
kdownlint\n files: \"\\.md$\"\n - id: python-black\n name: python black formatter\n e
ntry: black\n files: \"\\.py$\""n}"
}
}
A more sophisticated version of the file-writer function might communicate with an editor agent capable of presenting recommended file changes to a developer using native IDE concepts, like editor quick-fixes and hints. In other words, tools can help generative AI to meet developers where they are. And the answer to the question:
How do I set up git hooks?
becomes, “Let me just show you.”
Docker as tool engine
The tools mentioned in the previous sections have all been delivered as Docker containers. One goal of this work has been to verify that an assistant can bootstrap itself starting from a Docker-only environment. Docker is important here because it has been critical in smoothing over many of the system/environment gaps that LLMs struggle with.
We have observed that a significant barrier to activating even simple local assistants is the complexity of managing a safe and reliable environment for running these tools. Therefore, we are constraining ourselves to use only tools that can be lazily pulled from public registries.
For AI assistants to transform how we consume tools, we believe that both tool distribution and knowledge distribution are key factors. In the above example, we can see how LLM responses can be transformed by tools from unactionable and vague to hyper-project-focused and actionable. The difference is tools.
To follow along with this effort, check out the GitHub repository for this project.