fix: `shorebird patch` often fails for customers due to flutter version

[eseidel]

trafficstars

https://discord.com/channels/1030243211995791380/1030243213002412164/1231014847479808010 is another example.

When you run shorebird patch we know what app_id you're using, but we don't yet know what release version you're trying to patch. Since Gradle and XCode can end up changing the final release-version which is built into the application (info.plist, AndroidManifiest.xml) we need to actually perform a full build to figure out what version they're going to use.

The problem is, we don't at this time know which version of flutter to use.

We could also fetch the latest release and use that flutter revision? (that might be wrong if they've checked out an older release for the same app_id that they're patching?) Alternatively we could try looking for an fvm file? Or we could invent a new way in shorebird.yaml or similar to encode a version number?

[eseidel]

The customer also had some confusion about if --release-version referred to the version of Flutter. I suspect this is just general indication that our current UX here needs work. :)

[eseidel]

We should default to either:

1. The version of flutter in your cli.
2. The version of Flutter used by your last release.

the version we currently use (the default shorebird version) is more likely to be wrong than either of those.

[abhinand-kv]

@eseidel How does Shorbird determine the version when using the patch command? Is it the version installed on the machine or the version used for the release?

[felangel]

@eseidel How does Shorbird determine the version when using the patch command? Is it the version installed on the machine or the version used for the release?

It uses the same version that the release was created with.

[eseidel]

@eseidel How does Shorbird determine the version when using the patch command? Is it the version installed on the machine or the version used for the release?

In order to determine which release you're trying to patch we either use --release-version or we first build the app with the system-installed Flutter.

It's that later behavior which causes this confusion, since sometimes users don't use system-installed flutter (e.g. they use per-project fvm) or their system-installed Flutter isn't compatible with the version of their source code they have checked out/are patching.

The reason why we do this extra build is that we can't trust the version number in pubspec.yaml since sometimes apps set their version number via the build system. So we have to either have the --release-version passed to shorebird patch, or we build the app once (as described) and then read the version number out of the built app.

[bizz84]

I just bumped into this issue on my GitHub Actions workflow.

Here's an extract of my build log:

Tip: make your patches build faster by specifying --release-version
⠋ Building patch with Flutter 3.29.0
...
⠴ Building patch with Flutter 3.29.0 (4099421bb7) Task :mixpanel_fl... (32.6s)
✗ Failed to build (37.9s)

Looks like Shorebird incorrectly picked Flutter 3.29.0 even though my release workflow was using 3.27.4:

    - name: Shorebird Android Release
      uses: shorebirdtech/shorebird-release@v0
      id: shorebird-android-release
      with:
        platform: android
        args: --flutter-version=3.27.4

From the comments above, I understand that I can pass --release-version to the patch workflow as a workaround. However this means that I have to update my patch workflow every time I make a new release:

    - name: Shorebird Android Release
      uses: shorebirdtech/shorebird-release@v0
      id: shorebird-android-release
      with:
        platform: android
        args: --release-version=0.3.6+40

This is not ideal and it's likely to trip people up.

Since shorebird patch is applied to the latest release, can it not retrieve the correct flutter version from the release version (which is already stored in the Shorebird server)?

[felangel]

I just bumped into this issue on my GitHub Actions workflow.

Here's an extract of my build log:

Tip: make your patches build faster by specifying --release-version
⠋ Building patch with Flutter 3.29.0
...
⠴ Building patch with Flutter 3.29.0 (4099421bb7) Task :mixpanel_fl... (32.6s)
✗ Failed to build (37.9s)

Looks like Shorebird incorrectly picked Flutter 3.29.0 even though my release workflow was using 3.27.4:

- name: Shorebird Android Release
  uses: shorebirdtech/shorebird-release@v0
  id: shorebird-android-release
  with:
    platform: android
    args: --flutter-version=3.27.4

From the comments above, I understand that I can pass --release-version to the patch workflow as a workaround. However this means that I have to update my patch workflow every time I make a new release:

- name: Shorebird Android Release
  uses: shorebirdtech/shorebird-release@v0
  id: shorebird-android-release
  with:
    platform: android
    args: --release-version=0.3.6+40

This is not ideal and it's likely to trip people up.

Since shorebird patch is applied to the latest release, can it not retrieve the correct flutter version from the release version (which is already stored in the Shorebird server)?

You should be able to pass --release-version=latest to tell Shorebird to always build the patch targeting the newest release (highlight release version).

[eseidel]

Felix and I discussed this this morning (please correct me if I'm remembering incorrectly). We propose we should change shorebird as follows:

shorebird release should:

• use the version passed in --flutter-version as an arg
• use the version present in fvm or similar configuration files if available: https://github.com/shorebirdtech/shorebird/issues/1385
• use the version of flutter --version if flutter is on the path (and error if the version isn't one Shorebird supports).
• prompt with a list of flutter versions (if in an interactive shell)
• Otherwise fail with a message.

Upon choosing such a version, it should print a easily visible message that it's selected version X and why.

shorebird patch should determine the release (which in turn determine the flutter version) via:

• use the release version passed in --release-version arg, including the continued --release-version=latest
• prompt for a release (if an interactive shell)
• use the latest release

Since this is a breaking change, we would bump the major version of shorebird and have a blog explaining the change.

The reason for this change is that it's a common source of confusion both on the release side (why is my build failing even though flutter build works?) and on the patch side ("why is my patch build failing or taking so long").

[felangel]

Since this is a problem only in CI, we've updated our shorebird patch action to require a release version. Closing this for now but happy to continue the discussion if folks still have concerns or issues related to this.