Closed priitlatt closed 1 year ago
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
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.
@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
@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.
great!! @priitlatt :) thanks for the quick update. much appreciated!!
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 actionapp-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
```shell $ 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