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
856: Minimal dependency versions + local check script + more r=Bromeon a=Bromeon
### Local `check.sh` script
Remove the outdated pre-commit hook, replaced with bash script to run checks locally.
You can execute this script to run tests, formatting, clippy etc.
All with the right settings as expected by our CI.
### Dependency policy
Dependencies in all `Cargo.toml` files have been downgraded to their minimum compatible version of the current major/minor branch (e.g. `2.1.3` -> `2`, `0.6.5` -> `0.6`). This increases compatibility with user dependencies, while still serving the latest versions (with bugfixes/improvements) to users by default.
Further:
* Add CI job to verify minimal dependency versions.
* Remove explicit versions for intra-dependencies (i.e. `0.9.3` when referring to another `gdnative` crate).
* Update parking_lot (0.11 -> 0.12) and glam (0.19 -> 0.20).
### Chores
* Fix nightly clippy yet another time
* Add `im` and `im-rc` to cargo-deny
* Minor changelog update
* Formatting in CI (semicolons)
* .gitignore update
Co-authored-by: Jan Haller <[email protected]>
The godot-rust bindings developers welcome contribution from everyone. Here are the guidelines if you are thinking of helping us:
4
4
5
-
## Contributions
6
5
7
-
Contributions should be made in the form of GitHub pull requests (PRs). Each pull request will be reviewed by a core contributor (someone with permission to land patches) and either landed in the main tree or given feedback for changes that would be required.
6
+
## Submitting a PR
8
7
9
-
When opening a PR, our continuous integration (CI) pipeline will automatically perform a few basic checks (formatting, lints, unit tests). Please make sure those checks pass, adjusting your code if necessary.
8
+
Contributions should be made in the form of GitHub pull requests (PRs). Each pull request will be reviewed by the godot-rust team or other contributors.
10
9
11
-
Should you wish to work on an issue, please claim it first by commenting on the GitHub issue that you want to work on it. This is to prevent duplicated efforts from contributors on the same issue.
12
10
13
-
##Getting started
11
+
### Picking a task
14
12
15
-
Have a look at the [issues](https://github.com/godot-rust/godot-rust/issues) to find good tasks to start with.
13
+
Have a look at the [issue tracker] to find good tasks to start with. Should you wish to work on an issue, please claim it first by commenting in it. This is to prevent duplicated efforts from contributors on the same issue.
16
14
17
-
## Pull Request Checklist
15
+
We especially appreciate input on the issues labeled [`help wanted`]. The label [`good first issue`] encompasses issues which do not require a deep prior knowledge of the godot-rust intricacies and could be picked up by a newcomer.
18
16
19
-
- Branch from the master branch and, if needed, rebase to the current master branch before submitting your pull request. If it doesn't merge cleanly with master you may be asked to rebase your changes.
17
+
You can also open a pull request directly without an associated issue. Note however that discussing the issue with other developers beforehand increases the chances of a PR being accepted, and may save time on both your and the reviewer's end. Such discussions can also happen in our Discord server.
20
18
21
-
- Use one commit per logical change. Often, PRs only consist of a single commit. If you change unrelated parts of the code, split it into separate commits.
22
19
23
-
- If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment.
20
+
### Git workflow
24
21
25
-
- Whenever applicable, add tests relevant to the fixed bug or new feature.
22
+
* Branch from the `master` branch and, if needed, rebase to the current `master` branch before submitting your pull request. If it doesn't merge cleanly, you may be asked to rebase your changes.
26
23
27
-
- Use `cargo fmt` to format your code.
24
+
* Use one commit per logical change. Often, PRs only consist of a single commit. If you change unrelated parts of the code, split it into separate commits.
28
25
29
-
## Testing
26
+
* If your patch is not getting reviewed or you need a specific person to review it, you can @-reply a reviewer asking for a review in the pull request or a comment.
30
27
31
-
Everywhere: run `cargo test --workspace` from the root of the repository.
Whenever applicable, add tests relevant to the fixed bug or new feature.
41
32
42
-
The `godot` command in the above snippet is your local installation of godot and may vary depending on how it was installed.
33
+
Some types and functions can only be used if the engine is running. In order to test them, use the `godot_test!` macro, and explicitly invoke the test functions in [test/src/lib.rs](test/src/lib.rs). Don't hesitate to see how existing code does this.
43
34
44
-
### Automating tests
35
+
36
+
### Local and CI checks
45
37
46
-
If you are on a bash-compatible system, you can use the `pre-commit.sh` to automatically run your tests every time you try to commit code. You can install it with:
38
+
The repository root contains a script `check.sh`. If you invoke it without arguments, it will run a list of basic checks locally. This tool also allows you to quickly build RustDoc documentation of changed APIs. Please run `./check.sh --help` for more information about its usage.
If you use Windows, you might consider using a Unix shell interpreter (e.g. one shipped with Git-for-Windows, or WSL2, or similar).
52
41
53
-
If you don't need to run tests on your commit, you can simply run `git commit --no-verify` to skip the pre-commit script. The pre-commit script handles a few edge cases as well, by stashing all of your changes before running tests, just in case your unstashed changes mask errors in the bare commit. This is especially useful if you've stopped working on something to make a quick patch.
42
+
Additionally, when opening a PR, our continuous integration (CI) pipeline will automatically perform a few checks (formatting, lints, unit tests). Please make sure all of them pass, adjusting your code where necessary.
54
43
55
-
## Writing tests
56
-
57
-
Some types can only be used if the engine is running, in order to test them, use the `godot_test!` macro (see examples in [variant.rs](gdnative/src/variant.rs)), and explicitly invoke the test functions in [test/src/lib.rs](test/src/lib.rs).
58
44
59
45
## Communication
60
46
61
-
Primary communication between developers of the project happens on the `godot-rust` Discord server. [Invite link here](https://discord.gg/FNudpBD).
47
+
Primary communication between developers of the project happens on the `godot-rust` Discord server. [Invite link here][godot-rust-discord].
62
48
63
-
For questions about using `godot-rust` the `#gdnative` channel on the [Godot Engine community Discord server](https://godotengine.org/community) can be used.
64
-
On IRC the `#godotengine-gdnative` channel on freenode can be used for questions as well.
49
+
For questions about Godot, check out the options on the [Godot community page][godot-community]. For example, their Discord server hosts a `#gdnative-dev` channel for questions regarding GDNative interface. The contributor chat is helpful in case of discussions about Godot's own design and implementation.
65
50
66
-
If you are only interested in occasional announcements and showcases, follow [@GodotRust on Twitter](https://twitter.com/GodotRust). For questions and design discussions, please use Discord.
51
+
If you are only interested in occasional announcements and showcases, follow [@GodotRust on Twitter][godot-rust-twitter]. For questions and design discussions, please use Discord.
67
52
68
53
## License
69
54
70
55
Any contribution submitted for inclusion in the work by you shall be licensed under the [MIT license](LICENSE.md), without any additional terms or conditions.
![bors[bot]](https://avatars.githubusercontent.com/in/1847?v=4&size=40){kind=avatar}
0 commit comments