Closed PkcDom23 closed 5 years ago
@PkcDom23 Heyyyy ๐ What version/build of your app are you trying to submit and what version/build of your app is it actually submitting? By looking at your output it looks like its trying to submit 2.0.0
. Would you happen to send over a screenshot of the "Activity" page from App Store Connect expanded with all of the versions and builds that it is showing you?
Hello! Sure thing, here you go:
Hope it helps.
Deliver submitted the 41017 (appstore version 1.0.2) version (uploaded to appstore in november, but the whole update was rejected, but not because of invalid binary, so the build stayed in there as a candidate) Yet deliver uploaded the 41018 (appstore version 2.0.0), but just did not wait for it to process, and submitted the 41017 build to the appstore 2.0.0 version instead.
@PkcDom23 Thank you! That formation helps clear up some things on my side ๐ And yes yes, that is definitely a problem ๐ค
So we now need to figure out why deliver is doing this ๐ฑ
INFO [2019-01-09 11:06:09.55]: Selecting the latest build...
INFO [2019-01-09 11:06:11.13]: Selecting build 1.0.2 (41017)...
INFO [2019-01-09 11:06:12.58]: Successfully selected build
I'll work on investigating what could be causing this error ๐ค
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest fastlane
version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:
Bug is still present, pls dont close
We're experiencing this issue also, for about a month now. Here's the output from one of our jobs:
+--------------------------------------+------------------------+
| deliver 2.117.1 Summary |
+--------------------------------------+------------------------+
...
| app_version | 1.11.19 |
| build_number | 7 |
...
+--------------------------------------+------------------------+
[10:28:13]: Making sure the latest version on App Store Connect matches '1.11.19' from the ipa file...
[10:28:22]: Successfully set the version to '1.11.19'
...
[10:30:48]: Selecting existing build-number: 7
[10:30:51]: Selecting build 1.11.18 (7)...
[10:30:56]: Successfully selected build
[10:30:56]: Submitting the app for review...
[10:31:20]: Successfully submitted the app for review!
Actually after pasting that and looking back at our logs, it seems like it always chooses the previous version number but for the same build number. So I've uploaded 1.11.19 (7) but it instead selects 1.11.18 (7). Although that doesn't seem to match @PkcDom23 's experience, so maybe this is a different issue.
There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest fastlane
version and check if that solves the issue. Let us know if that works for you by adding a comment :+1:
This issue will be auto-closed because there hasn't been any activity for a few months. Feel free to open a new one if you still experience this problem :+1:
New Issue Checklist
Issue Description
Deliver still chooses the last available candidate build instead of waiting for processing the one being uploaded.
Deliver still chooses wrong build under certain circumstances. In my case, I transfer an app from one account to another (the app was in Rejected state, but not because of binary issues - the problem was submitting under our account, instead of customers account - we develop whitelabelled apps).
So Im not sure about other scenarios, but if you have an old binary that wasnt submitted, Deliver chooses that one for submitting without checking if the buildversion matches with what you are trying to deliver with Deliver.
After successful app transfer I uploaded a new build with fastlane, but deliver DID NOT wait for the new build to be processed, and instead submitted the one from rejected version. So it seems that deliver still chooses the last available candidate build instead of waiting for processing the one being uploaded. ]
Even though https://github.com/fastlane/fastlane/issues/13297 and https://github.com/fastlane/fastlane/issues/10945 are closed (and https://github.com/fastlane/fastlane/pull/13315 is merged), I experienced this bug as of today.
P.S. the transporter error received is just a warning that the app has different prefix (team_id from provisioning I believe?) than the account which uploads the app, nothing to do with the fact that deliver submits old build, because when there is no old build candidate, deliver submits correct build even with this warning.
Command executed
Fastlane didnt have any errors, just submitted old build candidate
Complete output when running fastlane, including the stack trace and command used
Environment