Repository navigation
[stable] fix: forward --build-name and --build-number to desktop version.json - #191602
Conversation
…lutter#190130) On desktop, `flutter build linux --build-name=4.5.6` produces a `flutter_assets/version.json` that still shows the pubspec default (`1.0.0`) instead of the value passed on the command line. The same happens with `--build-number`. That `version.json` (read by `package_info_plus`) is generated by the assemble target's `getVersionInfo`, which already honors the `BuildName` and `BuildNumber` defines. The break is upstream in the desktop build pipeline: those defines never reach `flutter assemble`. `BuildInfo.toEnvironmentConfig()`, which produces the environment map written into the generated CMake config, leaves the build name and number out, and `tool_backend.dart` does not forward them when it invokes assemble. Android and web are unaffected because they go through `toBuildSystemEnvironment()`, which already includes both values. This forwards the two values through the desktop path, following the same pattern already used for split-debug-info and tree-shake-icons. `toEnvironmentConfig()` now emits `BUILD_NAME` and `BUILD_NUMBER` via the existing null-aware map entries, and `tool_backend.dart` reads them and adds `-dBuildName` and `-dBuildNumber` to the assemble invocation next to the other optional defines. Because the map entries are null-aware, the keys are simply absent when the flags are not supplied, so default behavior is unchanged. No change is needed in `linux.dart`, which already applies these defines when they are present. Reproduced by the issue triager and reconfirmed by another user on 3.29.2. I added a `toEnvironmentConfig` unit test in `build_info_test.dart` that asserts the new keys appear when a build name and number are set. The existing encoding test keeps passing because null values stay omitted. Fixes flutter#152236 ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [AI contribution guidelines] and understand my responsibilities, or I am not using AI tools. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [ ] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [AI contribution guidelines]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#ai-contribution-guidelines [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md Co-authored-by: Ben Konyi <[email protected]>
|
@bkonyi please fill out the PR description above, afterwards the release team will review this request. |
|
This pull request was opened from and to a release candidate branch. This should only be done as part of the official Flutter release process. If you are attempting to make a regular contribution to the Flutter project, please close this PR and follow the instructions at Tree Hygiene for detailed instructions on contributing to Flutter. Reviewers: Use caution before merging pull requests to release branches. Ensure the proper procedure has been followed. |
There was a problem hiding this comment.
Code Review
This pull request introduces BUILD_NAME and BUILD_NUMBER environment variables to tool_backend.dart and build_info.dart, and adds a test case in build_info_test.dart. The review feedback notes that the syntax used for these variables in build_info.dart is invalid and should be replaced with collection if statements. Additionally, the feedback suggests checking that the variables are non-empty before appending them to the arguments list in tool_backend.dart, and adding a test case to verify the behavior when they are null.
| 'BUILD_NAME': ?buildName, | ||
| 'BUILD_NUMBER': ?buildNumber, |
There was a problem hiding this comment.
Using ?buildName and ?buildNumber is invalid Dart syntax and will cause compilation errors. Instead, use Dart's idiomatic collection if to conditionally include these keys in the map literal only when they are non-null.
if (buildName != null) 'BUILD_NAME': buildName,
if (buildNumber != null) 'BUILD_NUMBER': buildNumber,References
- Follow Effective Dart and Flutter style guidelines for idiomatic Dart code, such as using collection if for conditional map entries. (link)
| if (buildName != null) '-dBuildName=$buildName', | ||
| if (buildNumber != null) '-dBuildNumber=$buildNumber', |
There was a problem hiding this comment.
To prevent passing empty strings as build name or build number arguments (which could cause issues in the build system), check that they are both non-null and non-empty, matching the pattern used for flavor.
| if (buildName != null) '-dBuildName=$buildName', | |
| if (buildNumber != null) '-dBuildNumber=$buildNumber', | |
| if (buildName != null && buildName.isNotEmpty) '-dBuildName=$buildName', | |
| if (buildNumber != null && buildNumber.isNotEmpty) '-dBuildNumber=$buildNumber', |
| expect(buildInfo.toEnvironmentConfig()['BUILD_NAME'], '4.5.6'); | ||
| expect(buildInfo.toEnvironmentConfig()['BUILD_NUMBER'], '7'); | ||
| }); |
There was a problem hiding this comment.
It is good practice to verify the behavior when buildName and buildNumber are null. Since we conditionally omit these keys when they are null, we should assert that they are not present in the returned environment config map.
expect(buildInfo.toEnvironmentConfig()['BUILD_NAME'], '4.5.6');
expect(buildInfo.toEnvironmentConfig()['BUILD_NUMBER'], '7');
const buildInfoNull = BuildInfo(
BuildMode.release,
null,
treeShakeIcons: false,
packageConfigPath: 'foo/.dart_tool/package_config.json',
);
expect(buildInfoNull.toEnvironmentConfig().containsKey('BUILD_NAME'), isFalse);
expect(buildInfoNull.toEnvironmentConfig().containsKey('BUILD_NUMBER'), isFalse);
}78c8547
into
flutter:flutter-3.47-candidate.0
Issue Link:
#152236
Impact Description:
On desktop platforms (Linux, Windows, macOS), passing
--build-nameor--build-numbertoflutter builddoes not forward these values to the desktop assemble build backend. As a result, the generatedflutter_assets/version.jsoncontains default pubspec version values instead of the values passed on the command line, breaking version reporting in packages likepackage_info_plusand CI release pipelines.Changelog Description:
[flutter/152236] Forward
--build-nameand--build-numberflags to the desktop build pipeline so generatedversion.jsonreflects command-line build version parameters on desktop platforms.Workaround:
Manually edit the version string in
pubspec.yamlprior to building.Risk:
Test Coverage:
Validation Steps:
flutter build linux --build-name=4.5.6 --build-number=789(or on windows/macos).build/linux/x64/release/bundle/data/flutter_assets/version.json.version.jsoncontains"version": "4.5.6"and"build_number": "789".