Skip to content
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

fix(exit in bash): Fix handling exit everywhere #11650

Open
wants to merge 1 commit into
base: dev
Choose a base branch
from

Conversation

kiblik
Copy link
Contributor

@kiblik kiblik commented Jan 25, 2025

Reopen #10493

The original exit (e.g. from #9002) worked correctly in sh.
However, by adding shellcheck, #9147 changed sh to bash which handles these situations differently.
Linter introduced an error that nobody noticed.
Issue discovered during investigation of #10490

  • Why || true with grep?
    EXIT STATUS
         The grep utility exits with one of the following values:
    
         0     One or more lines were selected.
         1     No lines were selected.
         >1    An error occurred.
    Source: grep's man page:
    So if there was not admin before, the checker would stop the whole process. Now there is not difference in output (if admin exists) and if there is no admin, the initializer just continues.
  • Why || true with ls? Same answer.
  • Why --set initializer.keepSeconds="x"? For easier troubleshooting (to keep the job in the stack when it is finished - do not remove it).

@kiblik kiblik force-pushed the init_bash_exit branch 3 times, most recently from 087756d to 5b5601e Compare January 26, 2025 12:12
@kiblik kiblik marked this pull request as ready for review January 26, 2025 12:29
@kiblik kiblik marked this pull request as draft January 26, 2025 14:01
@kiblik kiblik changed the title fix(exit in bash): Fix handling exit in initializer fix(exit in bash): Fix handling exit everywhere Jan 26, 2025
@kiblik kiblik marked this pull request as ready for review January 26, 2025 22:25
@Maffooch
Copy link
Contributor

@kiblik this one appears to be covered in #11651. If so, can you please close this PR?

@kiblik
Copy link
Contributor Author

kiblik commented Jan 30, 2025

@kiblik this one appears to be covered in #11651. If so, can you please close this PR?

Yes, @Maffooch, #11651 covers also changes in this PR. However, implemented changes also make sense without other lines of code in #11651. As I wasn't sure if there would be any doubts or requests for changes in #11651, I decided to open this PR as well. If both of them will be accepted at the same time. This might be closed, and #11651 might be merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants