-
Notifications
You must be signed in to change notification settings - Fork 221
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upgrade Flutter and packages; hold back firebase_core; record Flutter commit IDs #1117
Conversation
a24c425
to
a278119
Compare
CI failed initially but should be fixed now. The fix was adding this commit: |
Running with this on my phone since last night, I noticed this morning I hadn't gotten any notifications, even though there were messages that should have caused notifications. Debugging found #1119, and I've added a commit to fix it. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! LGTM with one small question below. Seeing some iOS build issues actually; investingating.
# Check the commit is an acceptable commit. | ||
local commit_count | ||
commit_count=$( | ||
"${flutter_git[@]}" rev-list --count origin/main.."${flutter_commit}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've named the remote "upstream" instead of "origin", so "origin/main" doesn't work for me (here and below). I've named it back to "origin" for testing this new code; should I keep it that way or should the code adapt to handle the "upstream" name?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd suggest just switching back to "origin". It'd be possible to make this handle both conventions, but would make the logic more complicated.
I don't think the Flutter install steps do anything to override Git's default here, so most contributors will have "origin".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(Personally I switched back from using "upstream" to using "origin" a little while ago, for Git repos in general, partly just because I find "origin" is quicker for me to reliably type — "upstream" has long runs on the same hand.)
Oh I did notice an auto-generated change from diff --git ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme
index 5e31d3d34..c53e2b314 100644
--- ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme
+++ ios/Runner.xcodeproj/xcshareddata/xcschemes/Runner.xcscheme
@@ -48,6 +48,7 @@
ignoresPersistentStateOnLaunch = "NO"
debugDocumentVersioning = "YES"
debugServiceExtension = "internal"
+ enableGPUValidationMode = "1"
allowLocationSimulation = "YES">
<BuildableProductRunnable
runnableDebuggingMode = "0"> |
Hmm, seeing iOS build issues actually—investigating.
Hmm, seeing some iOS build issues actually—please hold off merging while I investigate. Here is the output:
|
Hmm, the build succeeded just now when I requested it from the Xcode gui. The output above is from |
OK, and it succeeds for me now after running |
Thanks for the review! Evidently I had not tried I reproduce that build failure, and also reproduce that Before
|
Merging, after adding this:
There was also a similar change in |
Fixes zulip#1118, or anyway the main part of it. Upcoming commits will add a suite in tools/check that validates this information, in case this line gets updated manually rather than using this script.
Future runs of `tools/upgrade` will keep this up to date.
Otherwise the clone doesn't know about the branch name `main`, which would confuse the logic in a check we're about to add.
Fixes zulip#1119. With Flutter from main, in release mode, the app would no longer show notifications on Android when it was in the background. This error message appears in logcat: ``` DartVM E ERROR: To access 'package:zulip/notifications/receive.dart::NotificationService' from native code, it must be annotated. ERROR: See https://github.com/dart-lang/sdk/blob/master/runtime/docs/compiler/aot/entry_point_pragma.md ``` It looks like the relevant upstream commit is probably this one: dart-lang/sdk@9b06e26 AFAICT those docs don't actually say that we should need to annotate the class. We already do annotate the static *method* on this class which we ask native code to call, namely `_onBackgroundMessage`. At least the error message is nice and clear, though.
And apply auto-upgrades that appear after `flutter run` for iOS and macOS respectively.
The upgrade to the Dart package firebase_core 3.4.0 (from 3.3.0) leads to the CocoaPods pod Firebase/CoreOnly 11.0.0 (from 10.29.0) and the further pod Firebase/Messaging 11.0.0 (from 10.29.0). That produces the following `pod update` error message when attempting to run `tools/upgrade pub`: ``` + pod update --project-directory=macos/ Update all pods Updating local specs repositories Analyzing dependencies firebase_core: Using Firebase SDK version '11.0.0' defined in 'firebase_core' firebase_messaging: Using Firebase SDK version '11.0.0' defined in 'firebase_core' [!] CocoaPods could not find compatible versions for pod "Firebase/Messaging": In Podfile: firebase_messaging (from `Flutter/ephemeral/.symlinks/plugins/firebase_messaging/macos`) was resolved to 15.1.0, which depends on Firebase/Messaging (~> 11.0.0) Specs satisfying the `Firebase/Messaging (~> 11.0.0)` dependency were found, but they required a higher minimum deployment target. ``` Fundamentally that should be fixable, but with some effort just now I wasn't able to actually increase that minimum deployment target in a way that satisfied CocoaPods so as to resolve this error. So, filed zulip#1116 for that. Meanwhile, let our other upgrades proceed.
This required a manual fixup step to update generated files for the Drift upgrade: $ tools/check --fix --all-files build_runner drift
This has been addressed in Greg's upstream PR: simolus3/drift#3022 which was pulled in by the Drift upgrade in 8b564e4 (zulip#1117). Signed-off-by: Zixuan James Li <[email protected]>
Fixes #1118.
Fixes #1119.
This upgrades Flutter and some of our other dependencies.
OTOH
firebase_core
and the other Firebase packages can't immediately be upgraded; I ran into #1116, which I just filed. So hold those back.And at the start of the branch, I augment
tools/upgrade
a bit so that it records the actual commit ID in the Flutter tree in a comment in pubspec.yaml, and givetools/check
a tiny new suiteflutter_version
that validates that information.On several occasions I've wanted the ability to look back and see what Flutter commit was used in a given published (beta) release, in particular. I already make a practice of doing so with the exact minimum version recorded in
pubspec.yaml
, in order to make it reproducible; but it's somewhat annoying to identify that commit from the version number that normally appears there. So this solves that problem. (… OK, and filed #1118 to describe that.)Selected commit messages
f5395d9 tools/upgrade: Record commit ID of Flutter into pubspec.yaml
Fixes #1118, or anyway the main part of it.
Upcoming commits will add a suite in tools/check that validates
this information, in case this line gets updated manually rather
than using this script.
a940b8a check: Add suite flutter_version
72e01d1 check: In flutter_version, verify version bound matches commit
a29b614 notif: Add vm:entry-point pragma on class, too
Fixes #1119.
[…]
479c518 deps: Upgrade Flutter to 3.27.0-1.0.pre.744
b1e7728 deps: Upgrade packages within constraints (tools/upgrade pub)
This required a manual fixup step to update generated files
for the Drift upgrade:
$ tools/check --fix --all-files build_runner drift