New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Build] Add retry_count to #all_processing_builds #10656
[Build] Add retry_count to #all_processing_builds #10656
Conversation
@Ruenzuo Sorry about this, but we had an issue in our unit tests, which has since been fixed on |
@mpirri sorry for the late reply, rebased now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @Ruenzuo - thanks for this! Its definitely a nice change, I'm just wondering about the one question above, and thinking out loud, should we have an option to pass in for this? Why do we think that retrying twice is enough?
This is definitely an awesome PR, just want to be sure we are making the right choice there before merging.
Thanks!
@@ -23,7 +23,7 @@ def wait_for_build_processing_to_be_complete(app_id: nil, platform: nil, poll_in | |||
private | |||
|
|||
def watching_build(app_id: nil, platform: nil) | |||
processing_builds = Spaceship::TestFlight::Build.all_processing_builds(app_id: app_id, platform: platform) | |||
processing_builds = Spaceship::TestFlight::Build.all_processing_builds(app_id: app_id, platform: platform, retry_count: 2) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a particular reason for having 2 as the default?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the default value FastlaneCore::BuildWatcher#matching_build
is using. I kept the same default value but besides of that no other reason.
@ohayon it would be nice to have a global fastlane configuration (i.e. environment variable) for all I can only find one usage of this, although I'm not sure if my query is correct. If so, this one would be the second one. Would a different PR for that make sense? |
Hey @Ruenzuo, it would be cool to have some more config around this, but I worry that we would need to change a bit of code to make sure certain places maintained their same behavior. I think you made a good point by using the same number of retries as the matching build situation. Thanks for this PR 🚀 |
Hey @Ruenzuo 👋 Thank you for your contribution to fastlane and congrats on getting this pull request merged 🎉 Please let us know if this change requires an immediate release by adding a comment here 👍 |
Congratulations! 🎉 This was released as part of fastlane 2.63.0 🚀 |
Checklist
bundle exec rspec
from the root directory to see all new and existing tests passbundle exec rubocop -a
to ensure the code style is validMotivation and Context
Same motivations and context explained in #9331
Today fastlane raised
Spaceship::Client::UnexpectedResponse
with the following trace:The retry logic implemented in #9331 helps with
FastlaneCore::BuildWatcher#matching_build
, but not with#watching_build
.Description
This PR adds
retry_count
argument toSpaceship::TestFlight::Build#all_processing_builds