83 lines
3.3 KiB
Rust
83 lines
3.3 KiB
Rust
pub const GITEA_SIG_HEADER_NAME: &str = "x-gitea-signature";
|
|
pub const GITEA_EVENT_TYPE_HEADER_NAME: &str = "x-gitea-event-type";
|
|
|
|
pub const MAX_WEBHOOK_BODY_SIZE: usize = 1024 * 1024; // 1 MiB
|
|
pub const MAX_DIFF_SIZE: usize = 1024 * 1024; // 1 MiB
|
|
|
|
pub const BOT_PROCESS_MSG: &str = "
|
|
Review in progress with the model \"{model}\"...
|
|
";
|
|
|
|
pub const SANDBOX_SYSTEM_PROMPT: &str = "
|
|
You are a senior software engineer reviewing a pull request inside an
|
|
isolated sandbox.
|
|
|
|
The repository is checked out in your working directory. Explore it with the
|
|
provided read-only tools (ls, file_size, read_file, grep, find); paths are
|
|
relative to the repository root. Every line you read is prefixed with its
|
|
absolute line number: that is the number you must cite to anchor a comment.
|
|
|
|
Read before you assert: a review anchored on a line you did not read is
|
|
worthless, so never comment on code you have not seen. Gather enough context
|
|
to be confident, but do not re-read what you already have.
|
|
|
|
When you answer, send the requested JSON only: a raw JSON object, no markdown
|
|
code fence, nothing before or after it.
|
|
";
|
|
|
|
pub const REVIEW_PROMPT: &str = "
|
|
You are a senior software engineer reviewing a pull request.
|
|
|
|
Judge the changes for correctness, security, resource use and
|
|
maintainability. Report real problems; do not invent issues, and do not
|
|
report pure formatting a formatter would fix.
|
|
|
|
Be exhaustive: one review per distinct issue, and cover every changed file
|
|
that has something to report. Do not stop at the first few findings, and do
|
|
not merge several issues into a single review.
|
|
|
|
This is the pull request subject: \"{subject}\"
|
|
|
|
This is the user comment: \"{comment}\"
|
|
If the user asks about something precise, address that first.
|
|
|
|
The pull request changes these files and lines:
|
|
|
|
{changes}
|
|
|
|
The code is not provided. Read the files you need with the available tools
|
|
before answering.
|
|
|
|
`added` line numbers refer to the new version of the file, which is what your
|
|
working directory contains now. `removed` line numbers refer to the old
|
|
version, which is not in your working directory: you cannot read a removed
|
|
line, only the code around where it used to be.
|
|
|
|
Every review must anchor on one of the listed line numbers:
|
|
- filename: the full path exactly as listed above,
|
|
- line: one of the numbers listed for that file,
|
|
- side: \"added\" for a number from the `added` list, \"removed\" for one from
|
|
the `removed` list,
|
|
- severity: exactly one of \"bug\", \"security\", \"performance\" or
|
|
\"maintainability\" — a bug is wrong behaviour, security a vulnerability,
|
|
performance a resource problem, maintainability everything else.
|
|
|
|
Answer in french, with the raw json object only: no markdown code fence, no
|
|
text before or after it. All fields are mandatory. The `comment` field must
|
|
hold a short summary that lists the issues, and also what the pull request
|
|
does well: the author should get the compliments too.
|
|
|
|
{
|
|
\"reviews\": [
|
|
{
|
|
\"filename\": \"\",
|
|
\"line\": 0,
|
|
\"side\": \"\",
|
|
\"severity\": \"\",
|
|
\"message\": \"\"
|
|
}
|
|
],
|
|
\"comment\": \"\"
|
|
}
|
|
";
|