Skip to content

Add code-review agent config from merged PR review patterns#439

Open
Copilot wants to merge 2 commits into
mainfrom
copilot/analyze-merged-pr-comments
Open

Add code-review agent config from merged PR review patterns#439
Copilot wants to merge 2 commits into
mainfrom
copilot/analyze-merged-pr-comments

Conversation

Copilot AI commented Jun 8, 2026

Copy link
Copy Markdown

Summary

Adds an explicit "Review effort level: medium" directive to the Copilot code-review agent configuration so reviews surface substantive issues without exhaustive nitpicking.

Changes

  • Added a Review effort level: medium bullet to the top of the "How to review" section in .github/copilot-instructions.md.

Checklist

  • A human-readable description of the changes was provided so that we can include it in CHANGELOG later

@CLAassistant

Copy link
Copy Markdown

CLA assistant check
Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
You have signed the CLA already but the status is still pending? Let us recheck it.

Copilot AI changed the title Add code-review agent config from merged PR review patterns Set Copilot review effort level to medium Jun 8, 2026
@peter-leonov-ch peter-leonov-ch requested a review from Copilot June 8, 2026 18:56

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adds/introduces a GitHub Copilot code-review instruction document for clickhouse-rs, including an explicit “Review effort level: medium” directive intended to keep reviews focused on substantive issues.

Changes:

  • Added .github/copilot-instructions.md with detailed code-review guidance for Copilot.
  • Included a “Review effort level: medium” bullet at the top of the “How to review” section.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread .github/copilot-instructions.md
@peter-leonov-ch peter-leonov-ch changed the title Set Copilot review effort level to medium Add code-review agent config from merged PR review patterns Jun 8, 2026
- When a rule is violated, reference it (e.g. "See Naming & API design") and
suggest the concrete fix.

## Naming & API design

@mshustov mshustov Jun 11, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

seems to be valid for new methods added. should we move sections not related to code review to AGENT.MD?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it reads both, I would say so.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes. the whole idea is that agent reads AGENT.md for development instructions

Comment on lines +55 to +57
- Do not introduce a panic into a previously non-panicking, released code path.
A new panic is a breaking behavior change and must wait for the next major
version.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This requires more nuance. If the panic is catching unsoundness or a programming error that would trigger a more harmful bug down the line, I'd rather have the panic.

In general though, we should prefer returning errors rather than panicking.

Comment on lines +67 to +69
- Every user-visible change needs a `CHANGELOG.md` entry under the correct
heading: `Added`, `Changed`, `Fixed`, or `Removed`. `Removed` is only for
deleted public APIs; internal-only removals go under `Changed`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Contributors tend to be hit-or-miss about writing good CHANGELOG entries so unless they choose to write one themselves, I just go in and add it during release.

deleted public APIs; internal-only removals go under `Changed`.
- When renaming a public API, keep the old name with `#[deprecated]` and
document both the new method and the deprecation; schedule removal for a
future major version.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

schedule removal for a future major version

I don't know what action Copilot should be expected to take here, if any. Maybe recommend opening an issue about removing the old method in a future version or something like that.

- Keep public-API dependencies that release breaking versions on a fast cadence
(e.g. `arrow`) in a separately versioned sub-crate, not in the core
`clickhouse` crate.
- Remove abandoned or unused (dev-)dependencies to keep the graph clean.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like this could tend towards unrelated changes slipping into PRs.

Comment on lines +58 to +60
- Add typed variants to `Error` instead of wrapping everything in
`Error::Other`. Remember each new variant is a SemVer hazard, so batch such
changes at a major-version boundary.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The Error enum is #[non_exhaustive] so adding new variants is backwards-compatible. What is a potential SemVer hazard is adding new variants wrapping errors from external crates that weren't already treated as public dependencies. In that case, Error::Other is the safer path because we can hide behind the type-erasure.

Changing what error variant is emitted for a specific error condition (e.g. #426) is likely a breaking behavior change, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants