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
@@ -73,9 +74,17 @@ You can install these plugins from `File > Settings > Plugins` in IntelliJ IDEA.
73
74
```sh
74
75
./gradlew runIde
75
76
```
77
+
78
+
## Testing and Doma Dependency Management
79
+
80
+
When running tests, the plugin creates a virtual project environment with the required Doma dependencies.
81
+
82
+
- The Doma jar files foreach version usedin tests are located in the [`src/test/lib`](src/test/lib) directory.
83
+
- The dependencies forthe virtual project are managedin the `setUp()` method of [`DomaSqlTest`](src/test/kotlin/org/domaframework/doma/intellij/DomaSqlTest.kt).
84
+
76
85
## Code Style
77
86
78
-
We use [Spotless](https://github.com/diffplug/spotless) and [google-java-format](https://github.com/google/google-java-format) for code formatting and style checking.
87
+
We use [spotless](https://github.com/diffplug/spotless) and [google-java-format](https://github.com/google/google-java-format) for code formatting and style checking.
79
88
80
89
- To check or apply formatting, run the following Gradle tasks:
81
90
```sh
@@ -89,9 +98,21 @@ We use [Spotless](https://github.com/diffplug/spotless) and [google-java-format]
89
98
90
99
Please ensure your code is formatted with Spotless before submitting a pull request.
91
100
101
+
### Code Inspection
102
+
103
+
For advanced code inspection and static analysis, consider using [Qodana](https://www.jetbrains.com/qodana/).
104
+
105
+
- Qodana is a static analysis tool by JetBrains that can automatically check code quality in CI pipelines.
106
+
- This repository includes a [`qodana.yml`](qodana.yml) file as an example configuration for Qodana.
107
+
- For more details, refer to the [Qodana official documentation](https://www.jetbrains.com/help/qodana/).
108
+
92
109
## Branch Naming Rules
93
110
94
-
When creating a working branch, please follow the naming rules below according to the type of change:
111
+
When creating a working branch, please follow the naming rules below according to the type of change.
112
+
113
+
These branch paths are used to categorize pull requests by label when automatically creating release drafts.
114
+
115
+
The mapping between branch paths and label names is configured in [`release-drafter.yml`](.github/release-drafter.yml).
95
116
96
117
- Bug fixes: `fix/`
97
118
- Documentation changes: `document/`
@@ -110,3 +131,4 @@ For example, a bug fix branch might be named `fix/typo-in-readme`, and a new fea
110
131
./gradlew check
111
132
```
112
133
3. Submit a pull request with a clear description of your changes.
134
+
4. After creating a pull request, please link any related issues to the PR.
0 commit comments