The changes in this commit create a virtual environment for the aider application in the Docker image. The key changes are:
1. Removes the permission-related commands that were modifying system directories.
2. Creates a virtual environment at `/venv` and adds it to the PATH.
3. Installs aider and its dependencies into the virtual environment.
4. Updates the ENTRYPOINT to use the aider executable from the virtual environment.
5. Copies the aider source to a temporary directory (`/tmp/aider`) for installation, then removes it after installation.
These changes should address the concerns about modifying system permissions while still allowing the container to function properly for different users.
The changes in this commit add support for running the Docker container as a non-root user. Specifically:
- Set permissions on the /.aider and /app directories to allow read/write/execute access for all users.
- Configure Git to consider the /app directory as a safe directory, which prevents Git from complaining about unusual permissions when running as a non-root user.
- Ensure that the Python site-packages directory and other relevant directories have read/write/execute permissions for all users, so that pip installs work even when running as a non-root user.
These changes will allow the Docker container to be run with the `--user` flag, which is a common requirement for running containers in production environments.
The test for `test_get_commit_message_with_custom_prompt` has been updated to correctly access the message content from the positional arguments of the `simple_send_with_retries` function call. This ensures that the test accurately reflects the implementation in the `GitRepo` class.
The new test case `test_get_commit_message_with_custom_prompt` ensures that when a custom `commit_prompt` is provided to the `GitRepo` constructor, it's used instead of the default prompt when generating commit messages. The test checks that:
1. The custom commit prompt is passed correctly to the `simple_send_with_retries` function.
2. The returned commit message is as expected.
3. The `simple_send_with_retries` function is called only once (since we're using a single model).
This new test case, along with the existing `test_get_commit_message_no_strip_unmatched_quotes` test, provides better coverage for the `get_commit_message` method in the `GitRepo` class.
The commit_prompt parameter is added to the Coder.__init__ method and passed to the GitRepo initialization. This allows users to provide a custom commit prompt when using the Coder class.
The GitRepo class in the aider/repo.py file has been updated to support a new `commit_prompt` argument. This allows overriding the default `prompts.commit_system` when generating commit messages.
The changes include:
1. Adding the `commit_prompt` parameter to the `__init__` method of the `GitRepo` class.
2. Storing the `commit_prompt` value in the `self.commit_prompt` attribute.
3. Modifying the `get_commit_message` method to use the `self.commit_prompt` value if it's provided, otherwise falling back to the default `prompts.commit_system`.
This change provides more flexibility in customizing the commit message generation process, allowing users to provide their own custom prompts if needed.
The new `--commit-prompt` switch allows users to specify a custom prompt for generating commit messages. This feature is implemented by adding the new argument to the argument parser in `aider/args.py` and passing it to the `Coder.create` method in `aider/main.py`.
BREAKING CHANGE: update tag regex to match semver pattern `v[0-9]+.[0-9]+.[0-9]+`
This change separates the concerns of PyPI release and Docker image release into two separate workflows. The original `release.yml` file has been renamed to `PyPI Release` and now only handles the PyPI package release. A new `docker-release.yml` file has been created to handle the Docker image build and push.
Both workflows are now triggered on tags matching the semver pattern `v[0-9]+.[0-9]+.[0-9]+`, which corresponds to tags like `vX.Y.Z`. The Docker-related steps have been moved from the original workflow to the new Docker-specific workflow.
This change ensures that both PyPI and Docker releases are triggered on the same semver-compliant tag pattern, while separating the concerns of the two release processes.
