Skip to content

[core] Skip repeating the output again when an sh command fails#19545

Merged
iBotPeaches merged 3 commits into
fastlane:masterfrom
tutipeti:fix-sh-spam
Jun 27, 2026
Merged

[core] Skip repeating the output again when an sh command fails#19545
iBotPeaches merged 3 commits into
fastlane:masterfrom
tutipeti:fix-sh-spam

Conversation

@tutipeti

@tutipeti tutipeti commented Oct 28, 2021

Copy link
Copy Markdown
Contributor

Checklist

  • I've run bundle exec rspec from the root directory to see all new and existing tests pass
  • I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
  • I've read the Contribution Guidelines
  • I've updated the documentation if necessary.

Motivation and Context

Resolves #19416
Resolves #11140

Description

I'm changing sh not to repeat the command output again when an error happens.
On output-heavy shell calls (in our case running Unity) this causes the entire output of Unity being repeated for absolutely no gain.
To make matters worse, without passing an error_callback there's even an exception raised that bundler picks up then and decides to repeat the output yet again. Yikes. :)

I've tested my changes both by running the rspec tests (which is also the reason why I had to change the tests) and by calling a script that fails through sh from my own project.

Testing Steps

Simply call any script that should fail and observe the output only appearing once.

If print_command_output is being set then the output was already printed while the command was running.

This only spams the logs too much, and when fastlane is used via bundler and an exception is being raised, the output is even repeated a 3rd time.
@google-cla google-cla Bot added the cla: yes label Oct 28, 2021

@joshdholtz joshdholtz left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm so torn on this 😱 I've totally seen what you saw with large outputs that is very overwhelming but I also like how this error would print out as red (vs the purple/pink) so it was very easy to find the error 🤔

I almost think I'd like this output to be truncated to some length and then maybe have the full output stored somewhere so that it can be seen a bit easier? 🤔

I know this is kind of asking a lot 😅 So I wouldn't mind helping more if you noodle on ideas or by adding some commits but I'd love to know your thoughts!

I really appreciate the effort on this though ❤️

@tutipeti

tutipeti commented Nov 1, 2021

Copy link
Copy Markdown
Contributor Author

Yeah, I feel your "pain" when you say you were torn. I also wasn't sure which approach is the better and kept jumping between "let's just omit it" and "let's add a new parameter so people can control this behaviour!"

My internal argumentation as for why I went with option a) (omitting) was that I had a hard time seeing actual value in duplicating the output. And based on that I thought not keeping it around as a default case would benefit more users than adding a customisation option that nobody would even see 😅

I almost think I'd like this output to be truncated to some length ...

Yeah, I guess that makes sense, especially if your output isn't as bad as mine.
Do you also have a good enough guesstimate about a reasonable length you'd like to see the output being trimmed to? ;)
I think what could make sense here is keeping the last, let's say 1000 characters, assuming that errors likely are printed at the end?
For the record: in my use-case (= Unity) keeping the last 1k characters wouldn't help, as Unity tends to output a lot of spam after errors too, before exiting 😄

and then maybe have the full output stored somewhere so that it can be seen a bit easier? 🤔

That is more or less available, right? Once you pass a callback, of course.
See https://github.com/fastlane/fastlane/blob/master/fastlane/lib/fastlane/helper/sh_helper.rb#L78

Another thought I had while looking at it, but got afraid as that feels like a bigger change, is that I could change from popen2e to some other method that isn't merging stdout and stderr of the executed process.
Which would mean that I would have the possibility to print stderr only in the error case, and not having to repeat the entire stdout again.

What do you think?

@tutipeti

Copy link
Copy Markdown
Contributor Author

Friendly reminder to @joshdholtz, if you have some time please don't forget this small PR ;)

Also, warm welcome to the newcomer 👶 👋

@joshdholtz

Copy link
Copy Markdown
Member

@tutipeti Ahhhh, I missed your response! Thank you for the friendly ping ❤️

@tutipeti

Copy link
Copy Markdown
Contributor Author

@joshdholtz I didn't really have a better idea so ended up placing back the repeated output, but shortened it to the last 500 characters.

If you have another wish please do tell me :) and happy new year 😅

@tutipeti tutipeti requested a review from joshdholtz March 15, 2022 10:52
@tutipeti

Copy link
Copy Markdown
Contributor Author

Hey @joshdholtz, fyi I'm still waiting for an approval here. And the fastlane bot keeps trying to close the issue related to this change request ;)

@mdcarter1

Copy link
Copy Markdown

Any chance we can get this approved?

@iBotPeaches iBotPeaches left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This bugs me to no end. You get a single failure on a RN build and it spews out another 30-50k lines and it takes forever to find the error among the mess.

I don't know if this is the right fix, but I'm trying it out and will iterate. I'm set on changing this before next release since I have a strong opinion as it exists now is extremely annoying.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This pull request aims to reduce log spam when Fastlane::Actions.sh fails by avoiding re-printing large command output in the error path (motivated by output-heavy tools like Unity).

Changes:

  • Truncates the command output appended to the failure message to the last 500 characters.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread fastlane/lib/fastlane/helper/sh_helper.rb
@iBotPeaches iBotPeaches changed the title Skip repeating the output again when an sh command fails [core] Skip repeating the output again when an sh command fails Jun 27, 2026
@iBotPeaches iBotPeaches dismissed joshdholtz’s stale review June 27, 2026 11:49

AFK for a bit. Resolving

@iBotPeaches iBotPeaches merged commit cf390a4 into fastlane:master Jun 27, 2026
12 checks passed

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @tutipeti 👋

Thank you for your contribution to fastlane and congrats on getting this pull request merged 🎉
The code change now lives in the master branch, however it wasn't released to RubyGems yet.
We usually ship about once a month, and your PR will be included in the next one.

Please let us know if this change requires an immediate release by adding a comment here 👍
We'll notify you once we shipped a new release with your changes 🚀"

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Congratulations! 🎉 This was released as part of fastlane 2.237.0 🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

sh spamming our logs upon errors by getting the output printed 3 times sh has strange, repeating error output and unclear stacktrace at the end

6 participants