You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -34,73 +33,102 @@ was for a different project), you probably don't need to do it again.
34
33
Visit <https://cla.developers.google.com/> to see your current agreements or to
35
34
sign a new one.
36
35
37
-
## Review our community guidelines
36
+
###Review our community guidelines
38
37
39
38
This project follows
40
39
[Google's Open Source Community Guidelines](https://opensource.google/conduct/).
41
40
42
-
#Contribution workflow
41
+
### Code reviews
43
42
44
-
## Finding Issues to Work On
43
+
All submissions, including submissions by project members, require review. We
44
+
use GitHub pull requests for this purpose. Consult
45
+
[GitHub Help](https://help.github.com/articles/about-pull-requests/) for more
46
+
information on using pull requests.
45
47
46
-
- Browse issues labeled **`good first issue`** (newcomer-friendly) or **`help wanted`** (general contributions).
47
-
- For other issues, please kindly ask before contributing to avoid duplication.
48
+
## Contribution workflow
48
49
50
+
### Finding Issues to Work On
49
51
50
-
## Requirement for PRs
52
+
- Browse issues labeled **`good first issue`** (newcomer-friendly) or **`help
53
+
wanted`** (general contributions).
54
+
- For other issues, please kindly ask before contributing to avoid
55
+
duplication.
51
56
52
-
- All PRs, other than small documentation or typo fixes, should have a Issue associated. If not, please create one.
53
-
- Small, focused PRs. Keep changes minimal—one concern per PR.
54
-
- For bug fixes or features, please provide logs or screenshot after the fix is applied to help reviewers better understand the fix.
55
-
- Please include a `testing plan` section in your PR to talk about how you will test. This will save time for PR review. See `Testing Requirements` section for more details.
57
+
### Requirement for PRs
56
58
57
-
## Large or Complex Changes
58
-
For substantial features or architectural revisions:
59
+
- All PRs, other than small documentation or typo fixes, should have a Issue
60
+
associated. If not, please create one.
61
+
- Small, focused PRs. Keep changes minimal—one concern per PR.
62
+
- For bug fixes or features, please provide logs or screenshot after the fix
63
+
is applied to help reviewers better understand the fix.
64
+
- Please include a `testing plan` section in your PR to talk about how you
65
+
will test. This will save time for PR review. See `Testing Requirements`
66
+
section for more details.
59
67
60
-
- Open an Issue First: Outline your proposal, including design considerations and impact.
61
-
- Gather Feedback: Discuss with maintainers and the community to ensure alignment and avoid duplicate work
68
+
### Large or Complex Changes
62
69
63
-
## Testing Requirements
70
+
For substantial features or architectural revisions:
71
+
72
+
- Open an Issue First: Outline your proposal, including design considerations
73
+
and impact.
74
+
- Gather Feedback: Discuss with maintainers and the community to ensure
75
+
alignment and avoid duplicate work
64
76
65
-
To maintain code quality and prevent regressions, all code changes must include comprehensive tests and verifiable end-to-end (E2E) evidence.
77
+
### Testing Requirements
66
78
79
+
To maintain code quality and prevent regressions, all code changes must include
80
+
comprehensive tests and verifiable end-to-end (E2E) evidence.
67
81
68
-
### Unit Tests
82
+
####Unit Tests
69
83
70
-
Please add or update unit tests for your change. Please include a summary of passed `pytest` results.
84
+
Please add or update unit tests for your change. Please include a summary of
85
+
passed `pytest` results.
71
86
72
87
Requirements for unit tests:
73
88
74
-
-**Coverage:** Cover new features, edge cases, error conditions, and typical use cases.
75
-
-**Location:** Add or update tests under `tests/unittests/`, following existing naming conventions (e.g., `test_<module>_<feature>.py`).
76
-
-**Framework:** Use `pytest`. Tests should be:
77
-
- Fast and isolated.
78
-
- Written clearly with descriptive names.
79
-
- Free of external dependencies (use mocks or fixtures as needed).
80
-
-**Quality:** Aim for high readability and maintainability; include docstrings or comments for complex scenarios.
89
+
-**Coverage:** Cover new features, edge cases, error conditions, and typical
90
+
use cases.
91
+
-**Location:** Add or update tests under `tests/unittests/`, following
- Free of external dependencies (use mocks or fixtures as needed).
97
+
-**Quality:** Aim for high readability and maintainability; include
98
+
docstrings or comments for complex scenarios.
81
99
82
-
### Manual End-to-End (E2E) Tests
100
+
####Manual End-to-End (E2E) Tests
83
101
84
-
Manual E2E tests ensure integrated flows work as intended. Your tests should cover all scenarios. Sometimes, it's also good to ensure relevant functionality is not impacted.
102
+
Manual E2E tests ensure integrated flows work as intended. Your tests should
103
+
cover all scenarios. Sometimes, it's also good to ensure relevant functionality
104
+
is not impacted.
85
105
86
106
Depending on your change:
87
107
88
-
-**ADK Web:**
89
-
- Use the `adk web` to verify functionality.
90
-
- Capture and attach relevant screenshots demonstrating the UI/UX changes or outputs.
91
-
- Label screenshots clearly in your PR description.
108
+
-**ADK Web:**
109
+
110
+
- Use the `adk web` to verify functionality.
111
+
- Capture and attach relevant screenshots demonstrating the UI/UX changes
112
+
or outputs.
113
+
- Label screenshots clearly in your PR description.
92
114
93
-
-**Runner:**
94
-
- Provide the testing setup. For example, the agent definition, and the runner setup.
95
-
- Execute the `runner` tool to reproduce workflows.
96
-
- Include the command used and console output showing test results.
97
-
- Highlight sections of the log that directly relate to your change.
115
+
-**Runner:**
98
116
99
-
## Documentation
117
+
- Provide the testing setup. For example, the agent definition, and the
118
+
runner setup.
119
+
- Execute the `runner` tool to reproduce workflows.
120
+
- Include the command used and console output showing test results.
121
+
- Highlight sections of the log that directly relate to your change.
100
122
101
-
For any changes that impact user-facing documentation (guides, API reference, tutorials), please open a PR in the [adk-docs](https://github.com/google/adk-docs) repository to update relevant part before or alongside your code PR.
123
+
### Documentation
124
+
125
+
For any changes that impact user-facing documentation (guides, API reference,
126
+
tutorials), please open a PR in the
127
+
[adk-docs](https://github.com/google/adk-docs) repository to update relevant
128
+
part before or alongside your code PR.
102
129
103
130
## Development Setup
131
+
104
132
1.**Clone the repository:**
105
133
106
134
```shell
@@ -110,11 +138,13 @@ For any changes that impact user-facing documentation (guides, API reference, tu
110
138
111
139
2. **Install uv:**
112
140
113
-
Check out [uv installation guide](https://docs.astral.sh/uv/getting-started/installation/).
If you want to contribute by leveraging viber coding, the AGENTS.md (https://github.com/google/adk-python/tree/main/AGENTS.md) could be used as context to your LLM.
235
+
If you want to contribute by leveraging viber coding, the AGENTS.md
236
+
(https://github.com/google/adk-python/tree/main/AGENTS.md) could be used as
0 commit comments