fastlane: latest_testflight_build_number gets wrong build number, if one failed to process.
New Issue Checklist
- Updated fastlane to the latest version
- I read the Contribution Guidelines
- I read docs.fastlane.tools
- I searched for existing GitHub issues
Issue Description
Using latest_testflight_build_number gets the wrong version number if one failed to process.
It gets the last successfully processed build number.
In the screenshot latest_testflight_build_number got the build number 8, not 9. When fastlane tries to upload the new build, it has the version number v2.6.0 (9) (which already exists), and I get the redundant binary error from iTunes Connect. Then I have to manually upload a build with the version number v2.6.0 (10).
Environment
Please run fastlane env and copy the output below. This will help us help you 👍
If you used --capture_output option please remove this block - as it is already included there.
✅ fastlane environment ✅
Stack
| Key | Value |
|---|---|
| OS | 10.12.6 |
| Ruby | 2.4.1 |
| Bundler? | false |
| Git | git version 2.13.5 (Apple Git-94) |
| Installation Source | /usr/local/bin/fastlane |
| Host | Mac OS X 10.12.6 (16G29) |
| Ruby Lib Dir | /usr/local/Cellar/ruby/2.4.1_2/lib |
| OpenSSL Version | OpenSSL 1.0.2l 25 May 2017 |
| Is contained | false |
| Is homebrew | false |
| Is installed via Fabric.app | false |
| Xcode Path | /Applications/Xcode.app/Contents/Developer/ |
| Xcode Version | 9.0 |
System Locale
| Variable | Value | |
|---|---|---|
| LANG | en_US.UTF-8 | ✅ |
| LC_ALL | ||
| LANGUAGE |
fastlane files:
`./fastlane/Fastfile`
# More documentation about how to customize your build
# can be found here:
# https://docs.fastlane.tools
fastlane_version "2.55.0"
default_platform :ios
import_from_git(url: "git@bitbucket.org:hashidevs/fastlane.git")
No Appfile found
fastlane gems
| Gem | Version | Update-Status |
|---|---|---|
| fastlane | 2.59.0 | ✅ Up-To-Date |
Loaded fastlane plugins:
| Plugin | Version | Update-Status |
|---|---|---|
| fastlane-plugin-versioning | 0.2.8 | ✅ Up-To-Date |
Loaded gems
| Gem | Version |
|---|---|
| did_you_mean | 1.1.0 |
| slack-notifier | 1.5.1 |
| rouge | 2.0.7 |
| xcpretty | 0.2.8 |
| terminal-notifier | 1.8.0 |
| unicode-display_width | 1.3.0 |
| terminal-table | 1.8.0 |
| plist | 3.3.0 |
| CFPropertyList | 2.3.5 |
| public_suffix | 2.0.5 |
| addressable | 2.5.2 |
| multipart-post | 2.0.0 |
| word_wrap | 1.0.0 |
| tty-screen | 0.5.0 |
| babosa | 1.0.2 |
| colored | 1.2 |
| highline | 1.7.8 |
| commander-fastlane | 4.4.5 |
| excon | 0.59.0 |
| faraday | 0.13.1 |
| unf_ext | 0.0.7.4 |
| unf | 0.1.4 |
| domain_name | 0.5.20170404 |
| http-cookie | 1.0.3 |
| faraday-cookie_jar | 0.0.6 |
| fastimage | 2.1.0 |
| gh_inspector | 1.0.3 |
| mini_magick | 4.5.1 |
| multi_json | 1.12.2 |
| multi_xml | 0.6.0 |
| rubyzip | 1.2.1 |
| security | 0.1.3 |
| xcpretty-travis-formatter | 0.0.4 |
| dotenv | 2.2.1 |
| bundler | 1.15.4 |
| faraday_middleware | 0.12.2 |
| uber | 0.1.0 |
| declarative | 0.0.10 |
| declarative-option | 0.1.0 |
| representable | 3.0.4 |
| retriable | 3.1.1 |
| mime-types-data | 3.2016.0521 |
| mime-types | 3.1 |
| little-plugger | 1.1.4 |
| logging | 2.2.2 |
| jwt | 1.5.6 |
| memoist | 0.16.0 |
| os | 0.9.6 |
| signet | 0.7.3 |
| googleauth | 0.5.3 |
| httpclient | 2.8.3 |
| google-api-client | 0.13.6 |
| json | 2.1.0 |
| io-console | 0.4.6 |
| openssl | 2.0.3 |
| claide | 1.0.2 |
| colored2 | 3.1.2 |
| nanaimo | 0.2.3 |
| xcodeproj | 1.5.2 |
| fastlane-plugin-versioning | 0.2.8 |
generated on: 2017-09-29
About this issue
- Original URL
- State: closed
- Created 7 years ago
- Reactions: 3
- Comments: 22 (5 by maintainers)
I’m seeing this too.
Heyyy 👋 Just wanted to update everyone. I started working on this last night and have a WIP PR open for it (#12054). I was able to get a fix in for when a build is manually expired but still working on a fix for when a process is failed. It turns out that we currently don’t have any API calls that show builds that have failed processing 😢
I will have to dig a bit deeper on this one and search out a new API with Charles Proxy or open a radar with Apple about this 😬
I too am seeing this issue. It seems latest_testflight_build_number doesn’t get the ‘processing’ build #.
Would be nice if it did - but not sure what’s possible with the various iTunes API?
Any idea of a work around - or a way to include the ‘processing’ build number as the actual latest_testflight_build_number?
Thanks