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

Change skip_broken and fail_on_warnings options #218

Open
neomilium opened this issue Apr 23, 2021 · 2 comments
Open

Change skip_broken and fail_on_warnings options #218

neomilium opened this issue Apr 23, 2021 · 2 comments

Comments

@neomilium
Copy link
Contributor

neomilium commented Apr 23, 2021

From my point of view, we should change our approach about two options skip_broken and fail_on_warnings:

  • skip_broken is not relevant option as, for example, an "update" that does not contain modification is consider as broken
  • skip_broken sounds me to be the default so turning option from skip_broken to fail_fast makes me sense to me
  • fail_on_warnings (ie. exit code sets to 1 or higher) could be an option if we choose to introduction a distinguish between real error (e.g. unable to process a template) and a warning (e.g. no files are updated after an update run)
  • finally, we should always fail earlier (with an exit code sets to 1 or higher) if an error occurred, so fail_fast will be relevant in case of warnings
@neomilium
Copy link
Contributor Author

What are the users opinion?

@smortex
Copy link
Member

smortex commented Apr 26, 2021

msync raising an error when a repository is up-to-date with the expectations if highly irritating… Having to pass skip_broken makes me think that I might fail to spot real problems for modules managed after the up-to-date module.

I consider this to be a bug indeed, and fixing this bug basically makes msync behave as make: by default stop on the first error, but by passing extra arguments (--keep-goind / -k)allow to continue. I quite like this behavior, but have no strong opinion about toggling it. In this case, adding a summary of the failures at the end (like rspec does), might be a good thing though.

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

No branches or pull requests

2 participants