Assign Uploaded Build to Test Group

[awgeorge]

Feature Request

Ability to assign an uploaded build to another testing group #11249

Motivation Behind Feature

We have many groups configured in our organisation to control the flow of our releases. For example the build first gets uploaded for developers, then progresses to QA, continues to PMs and so forth.

Our CI pipeline can handle this, however we get an error message when trying to assign a build to a new group.

Feature Description

Allow upload_to_testflight to skip_binary_upload on subsequent calls, to enable assigning the already uploaded build to a new group.

Currently trying to upload the same IPA again, but to a different group results in an error:

ERROR ITMS-90189: "Redundant Binary Upload. You've already uploaded a build with build number '160775' for version number '1.0.4'. Make sure you increment the build string before you upload your app to App Store Connect. Learn more in Xcode Help (http://help.apple.com/xcode/mac/current/#/devba7f53ad4)."
Return status of iTunes Transporter was 1: ERROR ITMS-90189: "Redundant Binary Upload. You've already uploaded a build with build number '160775' for version number '1.0.4'. Make sure you increment the build string before you upload your app to App Store Connect. Learn more in Xcode Help (http://help.apple.com/xcode/mac/current/#/devba7f53ad4)."
The call to the iTMSTransporter completed with a non-zero exit status: 1. This indicates a failure.

First call to upload the binary and distribute externally (as today):

upload_to_testflight(
      ipa: options[:ipa],
      username: ENV["APP_STORE_USERNAME"],
      groups: ["1) DeveloperTesting"],
      distribute_external: true,
      changelog: changelog
 )

Second call with a change of groups would succeed either by modifing the command to skip_binary_upload or by detecting the response error ITMS-90189 and handle it accordingly.

upload_to_testflight(
      ipa: options[:ipa],
      username: ENV["APP_STORE_USERNAME"],
      groups: ["2) QA"],
      skip_binary_upload: true
)

One would assume a different error would be returned from the service if you were trying to assign a build to a group that already have that build - but would require investigation. Otherwise I do not see a reason why this would be a negative change.

Alternatives or Workarounds

Maybe using spaceship you could code something, but modifying the upload_to_testflight is likely the sensible and easiest approach.

[fastlane-bot]

It seems like this issue might be related to code signing 🚫

Have you seen our new Code Signing Troubleshooting Guide? It will help you resolve the most common code signing issues 👍

[fastlane-bot]

It seems like you have not included the output of fastlane env

To make it easier for us help you resolve this issue, please update the issue to include the output of fastlane env 👍

[awgeorge]

@fastlane-bot - As I marked this as a feature request, there was no mentioning in the ticket that I needed to include my environment.

However, I'll give you a snippet

fastlane gems

Gem	Version	Update-Status
fastlane	2.100.1	✅ Up-To-Date

Loaded fastlane plugins:

Plugin	Version	Update-Status
fastlane-plugin-changelog	0.9.0	✅ Up-To-Date

Loaded gems

Gem	Version
did_you_mean	1.0.0
slack-notifier	2.3.2
rouge	2.0.7
xcpretty	0.2.8
terminal-notifier	1.8.0
terminal-table	1.8.0
public_suffix	2.0.5
addressable	2.5.2
multipart-post	2.0.0
word_wrap	1.0.0
tty-spinner	0.8.0
babosa	1.0.2
colored	1.2
commander-fastlane	4.4.6
http-cookie	1.0.3
faraday-cookie_jar	0.0.6
gh_inspector	1.1.3
mini_magick	4.5.1
multi_xml	0.6.0
rubyzip	1.2.1
security	0.1.3
xcpretty-travis-formatter	1.0.0
bundler	1.16.0
faraday_middleware	0.12.2
uber	0.1.0
declarative	0.0.10
declarative-option	0.1.0
representable	3.0.4
mime-types-data	3.2016.0521
mime-types	3.1
httpclient	2.8.3
google-api-client	0.21.2
emoji_regex	0.1.1
tty-cursor	0.6.0
tty-screen	0.6.5
faraday	0.15.2
json	2.1.0
highline	1.7.10
io-console	0.4.5
excon	0.62.0
CFPropertyList	3.0.0
libxml-ruby	2.9.0
plist	3.4.0
atomos	0.1.2
claide	1.0.2
colored2	3.1.2
xcodeproj	1.5.9
little-plugger	1.1.4
logging	2.2.2
jwt	2.1.0
memoist	0.16.0
os	0.9.6
signet	0.8.1
googleauth	0.6.2
unf	0.1.4
domain_name	0.5.20180417
fastimage	2.1.3
unicode-display_width	1.4.0
fastlane-plugin-changelog	0.9.0

generated on: 2018-07-30

[joshdholtz]

@awgeorge Thank you for appeasing @fastlane-bot 😊 It can be a bit needy

IMO, I think it makes the most sense for your case to make a custom lane, private_lane, or action to doing exactly what your process needs using spaceship

lane :add_group_to_tf_build do
  fastlane_require 'spaceship'
 
  Spaceship::Tunes.login("your@email.com")
  app = Spaceship::Tunes::Application.find("com.bundle.id")
  build = Spaceship::TestFlight::Build.latest(app_id: app.apple_id, platform: 'ios')
 
  group_name = 'the name of your group'
  group = Spaceship::TestFlight::Group.find(app_id: app.apple_id, group_name: group_name)
  build.add_group!(group)
end

If Spaceship::TestFlight::Build.latest isn't what you want, you can use any of these methods to get the build you want - https://github.com/fastlane/fastlane/blob/master/spaceship/lib/spaceship/test_flight/build.rb#L99-L129

[awgeorge]

If you think that's the best approach - I can confirm it does work. It doesn't seem to pick up the Appfile settings, however, so I would personally lean towards the API I outlined above. But you're the boss :D

[fastlane-bot]

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 👍

[fastlane-bot]

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 👍