-
Notifications
You must be signed in to change notification settings - Fork 29.1k
Fix handling of generate lock files #172124
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
base: master
Are you sure you want to change the base?
Fix handling of generate lock files #172124
Conversation
It looks like this pull request may not have tests. Please make sure to add tests or get an explicit test exemption before merging. If you are not sure if you need tests, consider this rule of thumb: the purpose of a test is to make sure someone doesn't accidentally revert the fix. Ask yourself, is there anything in your PR that you feel it is important we not accidentally revert back to how it was before your fix? Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing.If you believe this PR qualifies for a test exemption, contact "@test-exemption-reviewer" in the #hackers channel in Discord (don't just cc them here, they won't see it!). The test exemption team is a small volunteer group, so all reviewers should feel empowered to ask for tests, without delegating that responsibility entirely to the test exemption group. |
8975a5d
to
a259dcb
Compare
I'm working on a test. |
This pull request has been changed to a draft. The currently pending flutter-gold status will not be able to resolve until a new commit is pushed or the change is marked ready for review again. For more guidance, visit Writing a golden file test for Reviewers: Read the Tree Hygiene page and make sure this patch meets those guidelines before LGTMing. |
In context of adding a test of [Fix handling of generate lock files](flutter/flutter#172124) I noticed that the migration guide had a bug. When you keep the "build" sub directory the android artifacts will land in `build/build/outputs` instead of `build/outputs` and will break the rest of the build pipeline. _Issues fixed by this PR:_ Part of [#172124](flutter/flutter#172124) verified via [test](https://github.com/flutter/flutter/pull/172124/files#diff-69f1017db6d0164855e2cc56f273edcca2cc4bff1d5b14b716b0259252568d52R49-R51) ## Presubmit checklist - [x] If this PR is not meant to land until a future stable release, mark it as draft with an explanation. - [x] This PR follows the [Google Developer Documentation Style Guidelines](https://developers.google.com/style)—for example, it doesn't use _i.e._ or _e.g._, and it avoids _I_ and _we_ (first-person pronouns). - [x] This PR uses [semantic line breaks](https://github.com/dart-lang/site-shared/blob/main/doc/writing-for-dart-and-flutter-websites.md#semantic-line-breaks) of 80 characters or fewer.
@@ -332,7 +332,7 @@ class FlutterPlugin : Plugin<Project> { | |||
} | |||
|
|||
private fun addTaskForLockfileGeneration(rootProject: Project) { | |||
try { | |||
if ((rootProject.tasks as? DefaultTaskContainer)?.findByName("generateLockfiles") == null) { |
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.
Is there a reason you are casting here? I believe you could do
rootProject.tasks.findByName("generateLockfiles")
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
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.
You are right, that cast is useless will remove it now
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.
is removed now
/// The Gradle root directory of the Android host app. This is the directory | ||
/// containing the `app/` subdirectory and the `settings.gradle` file that | ||
/// includes it in the overall Gradle project. | ||
Directory get hostAppGradleRoot { | ||
if (hasGradleSettingsInProjectRoot) { |
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.
Can I ask why these changes to the gradle file getters are required? I would expect that the goal of the pr (the missed exception) would be fixed by just checking if the task exists before registering (i.e., what we are doing in FlutterPlugin.kt
).
I'd like to avoid this configuration (that is specific to this specific IDE use case) creeping in scope across the flutter tool if possible, so I'm hesitant about these changes.
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 already expected questions like that. I should have made notes about it. Anyway there are many checks for the build.gradle[.kts]
or settings.gradle[.kts]
since my original change aims to move those files there are lots of tests which break in those cases. Like the detection of the embedding since it starts looking in the wrong directory since it is currently relative to the settings.gradle[.kts]
.
This just becomes visible when you use the new file location in a test. This is also the reason why my draft PR, which moves the gradle files in the template, has lots of failing tests.
I tough all the time that the failing tests here were just flaky (the tree was quite often broken when I checked it)
I see not really how I broke them. I just removed a not required cast in my change set. Can someone tell me what I do not see? |
test/integration.shard/android_run_flutter_gradle_plugin_tests_test.dart appears to be file test failing and that does seem related.
What do you get when you run |
Converting back to draft since I have no time the next two weeks to get this resolved. |
While preparing a migration guide for supporting Dart and Kotlin files in one Android Studio instance I noticed that within #167332 a wrong exception was caught. This results in the exception mentioned in #172093 and this PR also fixes #172093. This is the "master" version of #172101
For the review the exception within gradle is thrown here:
Pre-launch Checklist
///
).