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
{{ message }}
This repository was archived by the owner on Feb 22, 2023. It is now read-only.
*`git remote add upstream git@github.com:flutter/plugins.git` (So that you
45
-
fetch from the master repository, not your clone, when running `git fetch`
46
-
et al.)
47
-
48
-
49
-
## Setting up tools
50
-
51
-
There are scripts for many common tasks (testing, formatting, etc.) that will likely be useful in preparing a PR.
52
-
See [plugin_tools](./script/tool/README.md) for more details.
53
-
54
-
## Running the examples
55
-
56
-
To run an example with a prebuilt binary from the cloud, switch to that
57
-
example's directory, run `pub get` to make sure its dependencies have been
58
-
downloaded, and use `flutter run`. Make sure you have a device connected over
59
-
USB and debugging enabled on that device.
60
-
61
-
*`cd packages/battery/example`
62
-
*`flutter run`
63
-
64
-
## Setting up XCUITests
65
-
66
-
Sometimes, XCUITests are useful when integration testing a plugin that has native UI on iOS (e.g image_picker, in_app_purchase, camera, share, local_auth etc). Most of the time, XCUITests are not necessary, consider using `integration_test` if the tests are not focused on iOS system UI.
67
-
68
-
If XCUITests has always been set up for the plugin, a RunnerUITests folder under `<the_plugin>/example/ios` directory can be found.
69
-
If XCUITests has not been set up for the plugin, follow these steps to set it up:
70
-
71
-
1. Open <path_to_plugin>/example/ios/Runner.xcworkspace using XCode.
72
-
1. Create a new "UI Testing Bundle".
73
-
1. In the target options window, populate details as following, then click on "Finish".
74
-
* In the "product name" field, type in "RunnerUITests".
75
-
* In the "Team" field, select "None".
76
-
* In the Organization Name field, type in "Flutter". This should usually be pre-populated.
77
-
* In the organization identifer field, type in "com.google". This should usually be pre-populated.
78
-
* In the Language field, select "Objective-C".
79
-
* In the Project field, select the xcodeproj "Runner" (blue color).
80
-
* In the Target to be Tested, select xcworkspace "Runner" (white color).
81
-
1. A RunnerUITests folder should be created and you can start hacking in `RunnerUITests.m`.
82
-
1. To enable the test on CI, the plugin needs to be removed from the "skip" list:
83
-
* Open `./cirrus.yml` and find PLUGINS_TO_SKIP_XCTESTS.
84
-
* Remove the plugin name from the list.
85
-
86
-
## Running the tests
87
-
88
-
### Integration tests
89
-
90
-
To run the integration tests using Flutter driver:
To run integration tests as instrumentation tests on a local Android device:
98
-
99
-
```console
100
-
cd example
101
-
flutter build apk
102
-
cd android && ./gradlew -Ptarget=$(pwd)/../test_driver/<name_of_plugin>_test.dart app:connectedAndroidTest
103
-
```
104
-
105
-
These tests may also be in folders just named "test," or have filenames ending
106
-
with "e2e".
107
-
108
-
### Dart unit tests
109
-
110
-
To run the unit tests:
111
-
112
-
```console
113
-
flutter test test/<name_of_plugin>_test.dart
114
-
```
115
-
116
-
### Java unit tests
117
-
118
-
These can be ran through Android Studio once the example app is opened as an
119
-
Android project.
120
-
121
-
Without Android Studio, they can be ran through the terminal.
122
-
123
-
```console
124
-
cd example
125
-
flutter build apk
126
-
cd android
127
-
./gradlew test
128
-
```
129
-
130
-
### XCTests (iOS)
131
-
132
-
XCUnitTests are typically configured to run with cocoapods in this repo. To run all the XCUnitTests for a plugin:
133
-
134
-
```console
135
-
cd ios
136
-
pod lib lint --allow-warnings
137
-
```
138
-
139
-
XCUITests aren't usually configured with cocoapods in this repo. They are configured in a xcode workspace target named RunnerUITests.
140
-
To run all the XCUITests in a plugin, follow the steps in a regular iOS development workflow [here](https://developer.apple.com/library/archive/documentation/DeveloperTools/Conceptual/testing_with_xcode/chapters/05-running_tests.html)
141
-
142
-
For convenience, a [plugin_tools](./script/tool/README.md) command [xctest](./script/tool/README.md#run-xctests) could also be used to run all the XCUITests in the repo.
143
-
144
-
## Contributing code
145
-
146
-
We gladly accept contributions via GitHub pull requests.
-[Java](https://google.github.io/styleguide/javaguide.html) formatted with
57
+
`google-java-format`
58
+
-[Objective-C](https://google.github.io/styleguide/objcguide.html) formatted with
59
+
`clang-format`
60
+
191
61
### The review process
192
62
193
-
Reviewing PRs often requires a nontrivial amount of time. We prioritize issues, not PRs, so that we use our maintainers' time in the most impactful way. Issues pertaining to this repository are managed in the [flutter/flutter issue tracker and are labeled with "plugin"](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3Aplugin+sort%3Areactions-%2B1-desc). Nontrivial PRs should have an associated issue that will be used for prioritization. See the [prioritization section](https://github.com/flutter/flutter/wiki/Issue-hygiene#prioritization) in the Flutter wiki to understand how issues are prioritized.
63
+
Reviewing PRs often requires a non-trivial amount of time. We prioritize issues, not PRs, so that we use our maintainers' time in the most impactful way. Issues pertaining to this repository are managed in the [flutter/flutter issue tracker and are labeled with "plugin"](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3Aplugin+sort%3Areactions-%2B1-desc). Non-trivial PRs should have an associated issue that will be used for prioritization. See the [prioritization section](https://github.com/flutter/flutter/wiki/Issue-hygiene#prioritization) in the Flutter wiki to understand how issues are prioritized.
194
64
195
65
Newly opened PRs first go through initial triage which results in one of:
196
66
***Merging the PR** - if the PR can be quickly reviewed and looks good.
197
-
***Closing the PR** - if the PR maintainer decides that the PR should not be merged.
198
-
***Moving the PR to the backlog** - if the review requires non trivial effort and the issue isn't a priority; in this case the maintainer will:
199
-
* Make sure that the PR has an associated issue labeled with "plugin".
67
+
***Requesting minor changes** - if the PR can be quickly reviewed, but needs changes.
68
+
***Moving the PR to the backlog** - if the review requires non-trivial effort and the issue isn't currently a priority; in this case the maintainer will:
200
69
* Add the "backlog" label to the issue.
201
70
* Leave a comment on the PR explaining that the review is not trivial and that the issue will be looked at according to priority order.
202
-
***Starting a nontrivial review** - if the review requires nontrivial effort and the issue is a priority; in this case the maintainer will:
71
+
***Starting a non-trivial review** - if the review requires non-trivial effort and the issue is a priority; in this case the maintainer will:
203
72
* Add the "in review" label to the issue.
204
73
* Self assign the PR.
74
+
***Closing the PR** - if the PR maintainer decides that the PR should not be merged.
205
75
206
-
### The release process
207
-
208
-
We push releases manually. Generally every merged PR upgrades at least one
209
-
plugin's `pubspec.yaml`, so also needs to be published as a package release. The
210
-
Flutter team member most involved with the PR should be the person responsible
211
-
for publishing the package release. In cases where the PR is authored by a
212
-
Flutter maintainer, the publisher should probably be the author. In other cases
213
-
where the PR is from a contributor, it's up to the reviewing Flutter team member
214
-
to publish the release instead.
215
-
216
-
Some things to keep in mind before publishing the release:
217
-
218
-
- Has CI ran on the master commit and gone green? Even if CI shows as green on
219
-
the PR it's still possible for it to fail on merge, for multiple reasons.
220
-
There may have been some bug in the merge that introduced new failures. CI
221
-
runs on PRs as it's configured on their branch state, and not on tip of tree.
222
-
CI on PRs also only runs tests for packages that it detects have been directly
223
-
changed, vs running on every single package on master.
Hopefully any bugs or breaking in changes in this PR have already been caught
227
-
in PR review, but now's a second chance to revert before anything goes live.
228
-
- "Don't deploy on a Friday." Consider carefully whether or not it's worth
229
-
immediately publishing an update before a stretch of time where you're going
230
-
to be unavailable. There may be bugs with the release or questions about it
231
-
from people that immediately adopt it, and uncovering and resolving those
232
-
support issues will take more time if you're unavailable.
233
-
234
-
To release a package, a [publish-plugin](./script/tool/README.md#publish-and-tag-release) tool script should be used. This command publishes the new version to pub.dev, and tags the commit in the format of `<package_name>-v<package_version>` then pushes it to upstream.
76
+
Please be aware that there is currently a significant backlog, so reviews for plugin PRs will
77
+
in most cases take significantly longer to begin than the two-week timeframe given in the
78
+
main Flutter PR guide. An effort is underway to work through the backlog, but it will
79
+
take time. If you are interested in hepling out (e.g., by doing initial reviews looking
80
+
for obvious problems like missing or failing tests), please reach out
81
+
[on Discord](https://github.com/flutter/flutter/wiki/Chat) in `#hackers-ecosystem`.
235
82
236
-
Alternatively, one can release a package in the below 2-step process.
83
+
### Releasing
237
84
238
-
1. Push the package update to [pub.dev](https://pub.dev) using `pub publish`.
239
-
2. Tag the commit with git in the format of `<package_name>-v<package_version>`,
240
-
and then push the tag to the `flutter/plugins` master branch. This can be
241
-
done manually with `git tag $tagname && git push upstream $tagname` while
242
-
checked out on the commit that updated `version` in `pubspec.yaml`.
85
+
If you are a team member landing a PR, or just want to know what the release
0 commit comments