Skip to content

Conversation

Copy link
Contributor

Copilot AI commented Oct 18, 2025

Problem

Builds were not reproducible because GitHub Actions workflows were running ci/pub_upgrade.sh, which executes flutter pub upgrade. This command updates dependencies to their latest compatible versions and modifies the pubspec.lock files before each build, resulting in different dependency versions across builds even when the source code hasn't changed.

Solution

This PR introduces a new ci/pub_get.sh script that uses flutter pub get instead of flutter pub upgrade. The key difference is:

  • flutter pub upgrade: Updates dependencies to latest compatible versions, modifying lockfiles
  • flutter pub get: Installs exact versions specified in lockfiles, ensuring reproducibility

All CI/CD workflows have been updated to use the new pub_get.sh script:

  • presubmit.yml
  • postsubmit.yml
  • android-release-to-org-openfoodfacts-scanner.yml
  • ios-release-to-org-openfoodfacts-scanner.yml
  • waldo_sessions.yml
  • on-demand.yml

What's Changed

  1. Added ci/pub_get.sh: New script for CI/CD that respects lockfiles
  2. Updated all workflows: Changed from pub_upgrade.sh to pub_get.sh
  3. Preserved pub_upgrade.sh: Kept for developers to manually update dependencies locally
  4. Added documentation: Created ci/README.md explaining when to use each script

Benefits

Reproducible builds: Building the same commit multiple times will always produce identical results
Consistent testing: Tests run against the exact same dependency versions that were validated
Better debugging: Issues can be reliably reproduced with the same dependency versions
Developer flexibility: Developers can still update dependencies using pub_upgrade.sh when needed

Migration Notes

No action required from developers. The pubspec.lock files are already tracked in git, so all builds will automatically use the committed lockfile versions. When you need to update dependencies, continue using ci/pub_upgrade.sh locally and commit the updated lockfiles.

Fixes issue about reproducible builds.

Original prompt

This section details on the original issue you should resolve

<issue_title>Reproducible builds</issue_title>
<issue_description>Builds should be reproducible. Right now, GitHub Actions run ci/pub_upgrade.sh in multiple places, which arguable reduces the reproducibility of the builds, because it updates the Flutter/Dart lockfiles before the build.</issue_description>

Comments on the Issue (you are @copilot in this section)

Fixes #7065


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

@hangy
Copy link
Member

hangy commented Oct 18, 2025

@copilot You're a Flutter DevOps specialist that knows how to create reproducible Flutter application bundles for cross-platform builds with GitHub Actions. Your aim is to keep the current build process intact, but to make builds more reproducible at the same time.

Copilot AI changed the title [WIP] Fix reproducibility of builds in GitHub Actions Fix reproducible builds by using pub get instead of pub upgrade in CI workflows Oct 18, 2025
Copilot AI requested a review from hangy October 18, 2025 21:44
Copilot finished work on behalf of hangy October 18, 2025 21:44
@hangy hangy requested a review from a team October 18, 2025 21:45
@hangy hangy changed the title Fix reproducible builds by using pub get instead of pub upgrade in CI workflows ci: Fix reproducible builds by using pub get instead of pub upgrade in CI workflows Oct 18, 2025
Copilot finished work on behalf of hangy October 18, 2025 21:47
@hangy hangy marked this pull request as ready for review October 18, 2025 21:56
Copy link
Member

@teolemon teolemon left a comment

Choose a reason for hiding this comment

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

@hangy what was the driver for this ? F-Droid ?

@hangy
Copy link
Member

hangy commented Oct 20, 2025

@hangy what was the driver for this ? F-Droid ?

I didn't know about F-Droid discussing reproducible builds. I just noticed that builds are not deterministic due to the flutter pub upgrade command being executed in the CI steps. They're not fully reproducible the way that F-Droid documents, but actually using pinned deps is more deterministic.

@hangy hangy requested a review from a team October 20, 2025 15:08
@g123k
Copy link
Collaborator

g123k commented Oct 20, 2025

Honestly, it won't change anything.
In the project, all dependencies are "hardcoded" (eg: 1.0.0) and don't use the ^ pattern (eg: ^1.0.0).

We can accept this PR. But at the end, it will generate the same build as today.

@hangy
Copy link
Member

hangy commented Oct 20, 2025

Honestly, it won't change anything. In the project, all dependencies are "hardcoded" (eg: 1.0.0) and don't use the ^ pattern (eg: ^1.0.0).

We can accept this PR. But at the end, it will generate the same build as today.

I don't think that's accurate. Lockfiles often also contain information about transitive dependencies. Those seem to be updated due to flutter pub upgrade. For example, one build for commit 9b4666f logs the following (excerpt):

Running 'flutter pub upgrade' in /home/runner/work/smooth-app/smooth-app/packages/smooth_app
Resolving dependencies...
Downloading packages...
> _fe_analyzer_shared 91.0.0 (was 88.0.0)
> analyzer 8.4.0 (was 8.1.1)
> build 4.0.2 (was 3.0.2)
> built_value 8.12.0 (was 8.11.1)
> camera_android_camerax 0.6.23+2 (was 0.6.19+1)
> camera_avfoundation 0.9.22+1 (was 0.9.21+1)
> camera_platform_interface 2.11.0 (was 2.10.0)
  characters 1.4.0 (1.4.1 available)
> code_builder 4.11.0 (was 4.10.1)
  device_info_plus 12.1.0 (12.2.0 available)
> file_selector_macos 0.9.4+5 (was 0.9.4+4)
> flutter_plugin_android_lifecycle 2.0.32 (was 2.0.29)
  flutter_secure_storage_linux 1.2.3 (2.0.1 available)
  flutter_secure_storage_macos 3.1.3 (4.0.0 available)
  flutter_secure_storage_platform_interface 1.1.2 (2.0.1 available)
  flutter_secure_storage_web 1.2.1 (2.0.0 available)
  flutter_secure_storage_windows 3.1.2 (4.0.0 available)
> image_picker_android 0.8.13+5 (was 0.8.13)
> image_picker_ios 0.8.13+1 (was 0.8.13)
> image_picker_macos 0.2.2+1 (was 0.2.2)
  in_app_review 2.0.10 (2.0.11 available)
  js 0.6.7 (0.7.2 available)
> leak_tracker 11.0.2 (was 11.0.1)
> logger 2.6.2 (was 2.6.1)
  material_color_utilities 0.11.1 (0.13.0 available)
  meta 1.16.0 (1.17.0 available)
  mobile_scanner 6.0.10 (7.1.2 available)
  objective_c 8.0.0 (8.1.0 available)
> path_provider_android 2.2.20 (was 2.2.17)
> path_provider_foundation 2.4.3 (was 2.4.2)
  provider 6.1.5 (6.1.5+1 available)
  share_plus 12.0.0 (12.0.1 available)
> shared_preferences_android 2.4.15 (was 2.4.11)
> shared_preferences_foundation 2.5.5 (was 2.5.4)
> source_gen 4.0.2 (was 3.1.0)
> sqlite3 2.9.3 (was 2.9.0)
  test_api 0.7.6 (0.7.7 available)
  unicode 0.3.1 (1.1.8 available)
> url_launcher_android 6.3.24 (was 6.3.17)
> url_launcher_ios 6.3.5 (was 6.3.4)
> url_launcher_macos 3.2.4 (was 3.2.3)
> watcher 1.1.4 (was 1.1.2)
> win32 5.15.0 (was 5.14.0)
These packages are no longer being depended on:
- build_config 1.2.0
- build_daemon 4.0.4
- build_resolvers 3.0.2
- build_runner 2.7.0
- build_runner_core 9.3.0
- checked_yaml 2.0.4
- frontend_server_client 4.0.0
- http_multi_server 3.2.2
- io 1.0.5
- pool 1.5.1
- pubspec_parse 1.5.0
- shelf 1.4.2
- shelf_web_socket 3.0.0
- timing 1.0.2
- web_socket 1.0.1
- web_socket_channel 3.0.3
Changed 42 dependencies!
17 packages have newer versions incompatible with dependency constraints.
⋮

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

Status: 💬 To discuss and validate

Development

Successfully merging this pull request may close these issues.

Reproducible builds

4 participants