Skip to content
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

[all_packages] Enforce property assignment for compile sdk over method assignment #8897

Conversation

reidbaker
Copy link
Contributor

No issue I just noticed that we were almost consistent in our approach to compileSdk.

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I read the [Tree Hygiene] page, which explains my responsibilities.
  • I read and followed the [relevant style guides] and ran the auto-formatter. (Unlike the flutter/flutter repo, the flutter/packages repo does use dart format.)
  • I signed the [CLA].
  • The title of the PR starts with the name of the package surrounded by square brackets, e.g. [shared_preferences]
  • I [linked to at least one issue that this PR fixes] in the description above.
  • I updated pubspec.yaml with an appropriate new version according to the [pub versioning philosophy], or I have commented below to indicate which [version change exemption] this PR falls under[^1].
  • I updated CHANGELOG.md to add a description of the change, [following repository CHANGELOG style], or I have commented below to indicate which [CHANGELOG exemption] this PR falls under[^1].
  • I updated/added any relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or I have commented below to indicate which [test exemption] this PR falls under[^1].
  • All existing and new tests are passing.

@reidbaker reidbaker marked this pull request as ready for review March 25, 2025 17:06
Copy link
Contributor

@stuartmorgan-g stuartmorgan-g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tool changes LGTM, but I'm still seeing ~40 violations of this locally.

if (methodAssignmentLine == null) {
printError('${indentation}No compileSdk or compileSdkVersion found.');
} else {
printError('${indentation}No compileSdk = found. Please use property assignment.');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How about No "compileSdk =" found to make this easier to parse if you don't already know what the issue is?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Copy link
Contributor

@stuartmorgan-g stuartmorgan-g left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. All comments optional.

@@ -24,7 +24,7 @@ if (flutterVersionName == null) {

android {
namespace = "com.example.all_packages"
compileSdkVersion flutter.compileSdkVersion
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we actually want to change this one? If we somehow broke it (maybe that's not even possible, but then... gradle), we would want to know presumably. And this is what the template generated at the time.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can see the argument for leaving it, it is code that we once generated.
That said what would break is not our code but agp code and I decided removing the last instance of compileSdkVersion was a good idea. If you feel strongly then I can revert this. I do not think gradle check runs against the legacy project so it wont cause a breakage.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That said what would break is not our code but agp code

If that happened we would want to put in a Flutter Fix or an auto-migrator though, presumably? Getting a warning about needing to do that from our CI could be nice.

I decided removing the last instance of compileSdkVersion was a good idea. If you feel strongly then I can revert this.

I would lean toward leaving it the way it was since in general the idea of legacy_project is to make absolutely minimal changes to it, but I'm fine with you making a call on it either way.

I do not think gradle check runs against the legacy project so it wont cause a breakage.

Right, the check runs on individual packages, and won't include this file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

reverted.



defaultConfig {
// TODO: Specify your own unique Application ID (https://developer.android.com/studio/build/application-id.html).
applicationId "io.flutter.plugins.flutter_plugin_android_lifecycle_example"
minSdkVersion flutter.minSdkVersion
minSdkVersion = flutter.minSdkVersion
targetSdkVersion flutter.targetSdkVersion
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why minSdkVersion but not targetSdkVersion?

Is the plan just to wait and fix the assignment type when standardizing on targetSdk?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

accidental add, removing. I do want to move us to use equals and minSdk and targetSdk but only with the enforcement to keep it that way.

@@ -421,12 +421,21 @@ for more details.''';

bool _validateCompileSdkUsage(
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to enforce the ndkVersion style too?

Copy link
Contributor Author

@reidbaker reidbaker Mar 25, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Eventually, I reverted the min change but most of the ndk versions were adjacent to the compileSdk so I went ahead and did them. I am willing to revert the ndk changes if you want to enforce it with tooling. That said I dont see a world where ndk tooling is important enough to enforce. I do think I will add enforcement for minSdk and targetSdk.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we care about it I think we should eventually enforce it, but I don't see any reason to block incidental updates while touching surrounding code on enforcement.

@reidbaker reidbaker added the autosubmit Merge PR when tree becomes green via auto submit App label Mar 25, 2025
Copy link
Contributor

auto-submit bot commented Mar 25, 2025

autosubmit label was removed for flutter/packages/8897, because - The status or check suite Linux_web web_dart_unit_test_wasm_shard_2 master has failed. Please fix the issues identified (or deflake) before re-applying this label.

@auto-submit auto-submit bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Mar 25, 2025
Copy link
Contributor

@chunhtai chunhtai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@reidbaker
Copy link
Contributor Author

Failures appear unrelated. Hopefully an updated branch will fix the issue.

@reidbaker reidbaker added the autosubmit Merge PR when tree becomes green via auto submit App label Mar 25, 2025
@auto-submit auto-submit bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Mar 25, 2025
Copy link
Contributor

auto-submit bot commented Mar 25, 2025

autosubmit label was removed for flutter/packages/8897, because - The status or check suite Linux_web web_dart_unit_test_wasm_shard_2 master has failed. Please fix the issues identified (or deflake) before re-applying this label.

@reidbaker
Copy link
Contributor Author

Blocked on flutter/flutter#165664

@ditman
Copy link
Member

ditman commented Mar 27, 2025

Clicked "Update branch" because web tests seem to be fixed in master after @stuartmorgan's fix.

@reidbaker reidbaker added the autosubmit Merge PR when tree becomes green via auto submit App label Mar 27, 2025
@auto-submit auto-submit bot removed the autosubmit Merge PR when tree becomes green via auto submit App label Mar 27, 2025
Copy link
Contributor

auto-submit bot commented Mar 27, 2025

autosubmit label was removed for flutter/packages/8897, because - The status or check suite Mac_arm64 ios_platform_tests_shard_2 master has failed. Please fix the issues identified (or deflake) before re-applying this label.

@stuartmorgan-g
Copy link
Contributor

autosubmit label was removed for flutter/packages/8897, because - The status or check suite Mac_arm64 ios_platform_tests_shard_2 master has failed. Please fix the issues identified (or deflake) before re-applying this label.

I'm seeing this same issue on a roller PR. I'm wondering if it's OOB failure from a maps SDK or server change.

@ditman
Copy link
Member

ditman commented Mar 28, 2025

Looking at the build history for the suite, it seems this was the first build broken like this was on: 2025-03-25 @ 09:55:

Associated to this commit:

  • 347d39a (the branch name according to github was "xcode_16_test" 🔮)

@stuartmorgan-g
Copy link
Contributor

Once #8967 lands, merging in main should unblock this.

@matanlurey matanlurey removed their request for review April 2, 2025 15:30
@reidbaker reidbaker added the autosubmit Merge PR when tree becomes green via auto submit App label Apr 3, 2025
@auto-submit auto-submit bot merged commit 4a36dc6 into flutter:main Apr 3, 2025
82 checks passed
engine-flutter-autoroll added a commit to engine-flutter-autoroll/flutter that referenced this pull request Apr 3, 2025
github-merge-queue bot pushed a commit to flutter/flutter that referenced this pull request Apr 3, 2025
flutter/packages@07496eb...4a36dc6

2025-04-03 [email protected] [all_packages]
Enforce property assignment for compile sdk over method assignment
(flutter/packages#8897)
2025-04-03 [email protected] [google_maps_flutter] Fix iOS info
window regression (flutter/packages#8939)
2025-04-02 [email protected] Roll Flutter from
05b5e79 to a0b1b32 (37 revisions) (flutter/packages#8985)

If this roll has caused a breakage, revert this CL and stop the roller
using the controls here:
https://autoroll.skia.org/r/flutter-packages-flutter-autoroll
Please CC [email protected] on the revert to ensure that a
human
is aware of the problem.

To file a bug in Flutter:
https://github.com/flutter/flutter/issues/new/choose

To report a problem with the AutoRoller itself, please file a bug:
https://issues.skia.org/issues/new?component=1389291&template=1850622

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+doc/main/autoroll/README.md
masterromuald pushed a commit to masterromuald/packages that referenced this pull request Apr 3, 2025
…d assignment (flutter#8897)

No issue I just noticed that we were almost consistent in our approach to compileSdk.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants