1- ## Pull Requests
1+ # Contributing guide
2+
3+ ## Pull requests
24
35All changes, no matter how trivial, must be done via pull request. Commits
46should never be made directly on the ` main ` branch. Prefer rebasing over
5- merging ` main ` into your PR branch to update it and resolve conflicts.
7+ merging ` main ` into your pull request branch to update it and resolve conflicts.
68
7- ## Building And Running Locally
9+ ## Building and running locally
810
9111 . ` git clone https://github.com/MobileNativeFoundation/rules_xcodeproj.git `
10- 1 . ` cd rules_xcodeproj `
11- 1 . ` bazel run //tools/generators/legacy:xcodeproj ` to generate an Xcode project
12- and develop in Xcode, or just open the directory in your favourite text
13- editor.
14- 1 . Build with Xcode:
15- 1 . Select the ` generator ` scheme to compile the executable.
16- 1 . Select the ` tests ` scheme to run the tests.
17- 1 . Build with Bazel:
18- 1 . ` bazel build //tools/generators/legacy:generator ` to compile the executable.
19- 1 . ` bazel test //tools/generators/legacy/test/... ` to run the tests.
12+ 2 . ` cd rules_xcodeproj `
13+ 3 . ` bazel run //tools:xcodeproj ` to generate an Xcode project and develop in
14+ Xcode, or just open the directory in your favorite text editor.
15+ 4 . Building locally:
16+ * ` bazel build //tools/... ` to compile the tools.
17+ * ` bazel test //tools/... ` to run the tests.
2018
2119## Developing
2220
@@ -32,38 +30,41 @@ into the directory if the example app is in a separate `WORKSPACE` with
3230` cd examples/integration; bazel run //:xcodeproj ` .
3331
3432You can run the internal tests as well:
35- ` bazel test //test/internal/xcschemes:all `
33+
34+ ```
35+ bazel test //test/internal/xcschemes:all
36+ ```
3637
3738You can even test your changes in a separate project living outside this
38- repo by overriding the module or repository in your ` .bazelrc ` .
39+ repo by overriding the module or repository in your ` .bazelrc ` :
40+
3941```
4042# With bzlmod:
4143build --override_module=rules_xcodeproj=/path/to/rules_xcodeproj
4244# Without bzlmod:
4345build --override_repository=rules_xcodeproj=/path/to/rules_xcodeproj
4446```
47+
4548It's important to add it to the ` .bazelrc ` instead of passing it as a
4649flag to ensure all invocations will use the same configuration.
4750
48- ## Test fixtures
49-
50- While developing, you might need to regenerate the test fixtures.
51- You can do so with ` ./test/update_all_fixtures.sh ` .
52-
53- All of the test fixture projects aren't buildable, because we use empty files in
54- place of things that are the same in every project. If you need to verify
55- anything in those projects, regenerate them locally.
56-
5751## Updating docs
5852
59- Run ` ./ docs/update_docs.sh` to generate to documentation based on the comments.
53+ Run ` docs/update_docs.sh ` to generate to documentation based on the comments.
6054
6155## Linting and formatting
6256
63- Before submitting your PR you should run the linter and formatter to
64- make sure everything if formatted properly in your bazel files
57+ Before submitting your pull request you should run the linter and formatter to
58+ make sure everything if formatted properly in your bazel files:
6559
66- ` bazel run //:buildifier.fix `
60+ ```
61+ bazel run //:buildifier.fix
62+ ```
6763
68- you can run ` bazel run //:buildifier.check ` to make sure your formatting
64+ You can run ` bazel run //:buildifier.check ` to make sure your formatting
6965is correct.
66+
67+ ## Changelog
68+
69+ If warranted, add an entry to ` CHANGELOG.md ` . Try to predict the pull request
70+ number, or adjust it after opening the pull request.
0 commit comments