Type something to search...



1.2k 79
04 May, 2024

What is AutoPR ?

AutoPR automates various tasks in the pull request workflow. It features automated generation of living summaries of code in READMEs, keeps track of TODOs in GitHub issues, and maintains a history of API call results in git. Additionally, it can automatically summarize changes in pull requests when a β€œsummarize” label is added. Users can configure AutoPR through YAML files to tailor its functionality to their specific needs.

🌟 AutoPR Features

  • 🌳 Living summaries of your code in nested READMEs

  • πŸ“ TODOs kept track of in issues

  • ⏳ Keep history of an API call’s result in git

  • πŸ“„ Summarize changes by adding a β€œsummarize” label to a PR

  • 🫡 Custom actions configured in YAML

Install AutoPR


You need your own OpenAI API key.


Follow these steps to set up AutoPR in your GitHub repository:

  • Create a new file in your repository named .github/workflows/autopr.yaml and copy the contents from the GitHub workflow template.

  • Create a new file in your repository named .autopr/triggers.yaml and copy the contents from the triggers template.

  • In your GitHub repository settings, navigate to Secrets and variables -> Actions and add your OpenAI API key as OPENAI_API_KEY.

  • In your GitHub repository settings, go to Actions -> General and scroll down to Workflow permissions. Enable Allow GitHub Actions to create and approve pull requests.

That’s it! Check out the Configuring guide to see how to customize AutoPR for your repository.

🌳 Living Summary

  • This folder contains various files and directories related to automating tasks in a pull request workflow.

  • The Dockerfile sets up a Docker image and installs dependencies using Poetry.

  • The LICENSE.md file contains the MIT License for the software.

  • The Makefile defines targets for formatting, type checking, testing, and more.

  • The action.yml file configures an automatic pull request workflow.

  • The autopr directory contains Python files and directories for actions, services, workflows, and configurations.

  • The entrypoint.sh file is a shell script that sets up Git configuration.

  • The poetry.lock file provides an overview of the project’s dependencies.

  • The pyproject.toml file is a configuration file for the Python project.

  • The strict_workflow_schema.json and trigger_schema.json files define schemas for strict workflows and triggers.

  • The workflow_schema.json file defines a schema for workflow definitions.


πŸ—οΈ Sets up a Docker image based on the duffn/python-poetry:3.9-bullseye image

πŸ”§ Installs git from the bullseye-backports repository

πŸ“₯ Copies an entrypoint script and makes it executable

πŸ“₯ Copies the pyproject.toml and poetry.lock files

πŸ”§ Activates the virtual environment and installs the project dependencies using Poetry

πŸ“₯ Copies the rest of the files to the /app directory

πŸ”§ Installs the application using Poetry

πŸš€ Sets the entrypoint to /entrypoint.sh for running the app


πŸ“„ This file contains the MIT License.

πŸ”’ The license grants permission to use, modify, and distribute the software.

πŸ“ The license requires the copyright notice and permission notice to be included in all copies.

🚫 The software is provided β€œas is” without warranty.

πŸ“… The license is valid until 2023.

πŸ’Ό The license is owned by Raphael Francis Ltd.


πŸ“ This file is a makefile-like configuration file.

πŸ”§ It defines various targets and their associated commands.

πŸ’» The targets are: format , type , test , schema , and all .

πŸ”§ The format target runs a command to format code using the black tool.

πŸ”§ The type target runs a command to perform type checking using pyright .

πŸ”§ The test target runs pytest on the autopr/tests directory.

πŸ”§ The schema target runs a command to generate configuration entrypoints using autopr.models.config .

πŸ”§ The all target runs all the targets in sequence: format , type , test , and schema .

πŸ”§ This file is meant to automate common development tasks and ensure code quality.


πŸ“„ This file is a configuration file for an automatic pull request workflow.

πŸ”§ It specifies the details for running the workflow, such as the Docker image to use.

🎨 It also includes branding information, such as the icon and color to use.

πŸ”‘ The file defines inputs required for the workflow, such as the GitHub token and base branch.

πŸŽ₯ It includes a default loading GIF URL to display while the pull request is being generated.

🌿 The file defines a template for the name of the target branch.

πŸ”„ It specifies whether to overwrite existing branches and pull requests when creating from issues.


This folder contains a collection of Python files and directories that provide various actions, services, workflows, and configurations for automating tasks in a pull request workflow. The files include actions for running commands, generating choices, publishing comments on GitHub issues, committing changes, searching for keywords, making API calls, and more. There are also files for managing logging, defining triggers and workflows, configuring services, and defining data models. The directories contain additional files for managing and running actions, defining workflows, and handling events. Overall, this folder provides a comprehensive set of tools and functionalities for automating tasks in a pull request workflow.


πŸ“ The file is a shell script

πŸ”§ It sets the Git configuration for a specific directory

βœ‰οΈ It sets the user email and name for Git commits

πŸ“¦ It activates a virtual environment

🐍 It runs a Python module called autopr.gh_actions_entrypoint


πŸ“„ This file is an executive summary of a project or report

πŸ” It provides a high-level overview of the main points

πŸ“ It highlights key findings, conclusions, and recommendations

πŸ“Š It may include a summary of data or analysis

πŸ‘₯ It is intended for someone who is new to the project or report

🚫 It does not include trivial details or technical explanations

πŸ’‘ It gives a clear understanding of the purpose and scope of the project

πŸ‘€ It provides a quick glance at the content without going into depth

πŸ’Ό It serves as a starting point for further exploration or discussion

πŸ“Œ It is concise and easy to read, even if the file is empty


πŸ“‹ This file is a configuration file for a Python project using Poetry.

πŸ” It contains information about the project’s name, version, and authors.

πŸ“„ The license of the project is specified as MIT.

πŸ“¦ It lists the packages and their dependencies required for the project.

πŸ§ͺ There are separate dependencies for testing and development.

πŸ”§ The build system used is Poetry.

πŸ” The file also includes configuration for the Pyright static type checker.

πŸ” It specifies the line length and target version for the Black code formatter.


πŸ“„ The file is a JSON schema describing a strict workflow definition.

πŸ” It defines various actions that can be performed within the workflow.

πŸ”€ Actions include commenting, setting issue titles, walking files, making API calls, running bash commands, and more.

πŸ“ Each action has its own set of inputs and outputs.

πŸ”„ The workflow steps are defined as an array of actions.

πŸ“š The schema also includes definitions for various data types and declarations used within the actions.

πŸ“ The purpose of the file is to provide a standardized structure for defining and executing strict workflows.

πŸ—‚οΈ The schema can be used to validate and ensure the correctness of workflow definitions.

🧩 It allows for easy integration with other tools and systems that support the schema.

πŸ“š The file can serve as a reference for understanding the structure and capabilities of strict workflows.


πŸ“„ This file is a JSON schema definition for a configuration file.

🏷️ It defines various action models and trigger models.

πŸ”€ The action models represent different actions that can be performed in a workflow.

πŸ”„ The trigger models represent different triggers that can initiate a workflow.

πŸ”– The schema provides a structure for defining inputs, outputs, and other properties for each action and trigger.

πŸ“ It also defines different types of declarations and templates that can be used within the actions and triggers.

πŸ”€ The β€œTopLevelTriggerConfig” object is the main configuration object that contains an array of triggers.

πŸ“Œ Each trigger can be of type β€œlabel”, β€œcomment”, β€œpush”, or β€œcron”.

🌐 Overall, this file provides a standardized structure for defining workflows and their triggers and actions.


πŸ“„ This file is a JSON schema definition for a workflow definition.

πŸ”§ It defines various types and properties for different actions and declarations used in the workflow.

πŸ“ The schema includes definitions for actions like commenting, setting issue title, walking files, making API calls, running bash commands, etc.

πŸ“š It also defines different types of declarations like template, variable, constant, and lambda declarations.

πŸ“‹ The workflow definition includes a name, description, inputs, and outputs.

πŸ”’ It consists of a list of steps which can be actions, workflow invocations, or conditional statements.

πŸ”€ Conditional statements can have if-else branches and support different conditions like lambda expressions and context checks.

πŸ”„ Workflow invocations can be either regular or iterable.

πŸ”‘ Overall, this file provides a structured definition for creating and executing workflows with various actions and conditions.