docs: Add AGENTS.md and llms.txt#2797
Conversation
another-rex
left a comment
another-rex
left a comment
There was a problem hiding this comment.
Hmm I was thinking this would also include how osv-scanner and osv-scalibr works together and the plugin system...etc
Not sure if that fits into this file though
| - **Strict Issue-First Workflow:** You must follow the issue-first workflow before opening any Pull Request. The required path is always: **Issue Assignment -> Pull Request**. | ||
| - **Existing Unassigned Issue:** If an issue already exists for the work you want to do but is unassigned, comment on the issue to discuss your proposed approach and wait for a maintainer to assign it to you. | ||
| - **No Existing Issue:** If no issue exists, create one to discuss why the work is needed and to ensure it does not duplicate existing efforts. Wait for the issue to be assigned to you before proceeding. |
There was a problem hiding this comment.
technically this does not cover "an existing issue that is assigned to someone else" - I suspect LLMs might be able to infer that enough that it means we won't get tons of PRs via that as a loophole, but still something we might as well cover 🤷
Yeah I also think it will be helpful if we could explain in more details how osv-scanner works with osv-scalibr, so that if there is an issue with scalibr, the agent knows to open an issue or make contributions there. |
|
|
||
| ### 3.3 Commit Messages and PR Titles | ||
|
|
||
| - **Conventional Commits:** You must follow the [Conventional Commits](https://www.conventionalcommits.org/) specification for all pull request titles and commit messages. |
There was a problem hiding this comment.
also mention that we have a section for that in https://github.com/google/osv-scanner/blob/main/CONTRIBUTING.md#making-commits as well
|
|
||
| - **Coverage:** Any new feature, bug fix, or refactor should be accompanied by relevant tests (unit, integration, or snapshot tests). | ||
| - **Snapshots:** If your changes modify behavior that affects snapshot tests, update the snapshots (e.g., using `make test SNAPS=true`) and explicitly note this in the PR description. | ||
| - **VCR Cassettes:** If your changes add new HTTP interactions in tests that use `go-vcr`, ensure the appropriate cassettes are recorded or updated as described in `CONTRIBUTING.md`. |
There was a problem hiding this comment.
maybe also mention that Makefile has the definition as well, and it can also be useful to understand the use cases for other testing usage.
Co-authored-by: Gareth Jones <3151613+G-Rath@users.noreply.github.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #2797 +/- ##
==========================================
+ Coverage 79.14% 79.26% +0.12%
==========================================
Files 121 122 +1
Lines 8203 8258 +55
==========================================
+ Hits 6492 6546 +54
Misses 1329 1329
- Partials 382 383 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Co-authored-by: Rex P <106129829+another-rex@users.noreply.github.com>
| ### 4.2 Testing Standards | ||
|
|
||
| - **Coverage:** Any new feature, bug fix, or refactor should be accompanied by relevant tests (unit, integration, or snapshot tests). | ||
| - **Snapshots:** If your changes modify behavior that affects snapshot tests, update the snapshots (e.g., using `make test SNAPS=true`) and explicitly note this in the PR description. |
There was a problem hiding this comment.
When resolving merge conflicts, if snapshots conflict it's normally easier to rebuild the snapshots rather than trying to resolve them.
5 participants
Attempt at: