feat: change order of actions when performing a patch

[szelemeh]

Description

Currently the order of steps when patching is as follows: ✓ Fetching apps ✓ Building release ✓ Detected release version ✓ Fetching releases

It first builds the release and only then detects release version from pubspec.yaml. Apps that use solutions like Codemagic for automatic versioning during CI/CD, might have different version and/or build number in their pubspec.yaml file which leads to the following error:

Release not found: "x.y.z+n"

Patches can only be published for existing releases.
Please create a release using "shorebird release" and try again.

So, I think it would be better to check if the release exists before proceeding to the building step since build takes most of the time when patching and failing early would save a lot of time.

Requirements

• [ ] Steps ✓ Detected release version and ✓ Fetching releases happen before the ✓ Building release step.

[bryanoltman]

If we derived the version number from the pubspec.yaml, I would 100% agree. However, it is possible for the pubspec's app version to not match the actual version of the app (if the user edits the app's build.gradle or the xcode project file to no longer use the values provided by Flutter at build time, for example). Because of this, we need to get the build number from the built app itself, as that is the only fully reliable way we have to determine the release version that the app will report when checking for patches.

[szelemeh]

I see, thank you for your reply!