App Store connect latest build number detection improvements

[priitlatt]

This is a follow up to PR #300.

The changes that were introduced in #300 expected that when App Store or prerelease versions were listed for an app so that builds are also included in the responses, then there is a correspondence between the included resources (builds in our case) and the queried versions. However this does not always hold and as such the approach can lead to unexpected results.

Changes here choose the highest version (App Store or prerelease) that has builds and then returns the highest build number from this patch of builds.

In addition to this, add mutually exclusive optional arguments --expired and --not-expired to action app-store-connect get-latest-testflight-build-number to include or exclude expired builds from the latest build number lookup. (Fixes #305)

Example usage of new flags

$ app-store-connect get-latest-build-number "1481211155"
Found build number 2.0.320.508 from TestFlight version 2.0.320
2.0.320.508
$ app-store-connect get-latest-testflight-build-number "1481211155"
Found build number 2.0.320.508 from TestFlight version 2.0.320
2.0.320.508
$ app-store-connect get-latest-testflight-build-number "1481211155" --pre-release-version "01.04.01"
Found build number 134 from TestFlight version 01.04.01
134
$ app-store-connect get-latest-testflight-build-number "1481211155" --pre-release-version "01.04.01" --expired
Found build number 134 from TestFlight version 01.04.01
134
$ app-store-connect get-latest-testflight-build-number "1481211155" --pre-release-version "01.04.01" --not-expired
Did not find latest build for app 1481211155

Updated actions

• app-store-connect get-latest-testflight-build-number
• app-store-connect get-latest-app-store-build-number
• app-store-connect get-latest-build-number

[nouman-hanif]

this change is breaking backward compatibility. I just spent half a day fixing the issue with my deployment pipeline. The default behavior without --expired or --not-expired switches was to return highest build number from builds that weren't expired. After this update, the behavior changed for the older deployment and it started returning highest build number from expired and non-expired combined. This should have remained unchanged.

Also, the documentation of the script is not updated so there was no way to quickly figure out what had gone wrong. Can you please make sure to update the documentation?

Thanks

[priitlatt]

Hi @nouman-hanif. We're terribly sorry for the inconveniences that those changes have brought up to you and your team.
The original (breaking) change came from PR #300 and its aftermath is discussed under #303. We were well aware that this change is going to break some workflows, but as the previous solution was downright wrong as build with version 2.0 (3) is more recent than 1.9 (99) by the rules that Apple has set (the latter would have been chosen before changes), then the behaviour of the action really had to be updated.

In case you have a good idea on how the action documentation should be changed, then please let us know.

And, again, sorry for the troubles this has caused you.

[nouman-hanif]

@priitlatt thanks for the explanation. I understand sometimes to improve a solution it is impossible to maintain backward compatibility. The reason it took me more time to figure was because the documentation of the action on GitHub wasn't up to date with the changes. I am talking about readme at get-latest-testflight-build-number. If the two new optional switches --expired --not-expired can be added then anybody facing similar problem can figure out quickly. I ended up on this doc page from Codemagic docs topic Automatic build versioning, where I would imagine almost everybody would first look.

Nouman

[priitlatt]

@nouman-hanif Web docs for aapp-sotre-connect get-latest-testflight-build-number were updated in commit
ce1fb8f and reflect --expired and --not-expired flags now.

[nouman-hanif]

great!! @priitlatt :) thanks for the quick update. much appreciated!!