-
Notifications
You must be signed in to change notification settings - Fork 36
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
feat: support for dry-run mode #88
Conversation
Includes a test for dry-run mode
Hi @mdelapenya, it's great to see you here 😃 Thanks for the PR - @sledigabel and I will try to review soon! |
Indeed, my pleasure! I'm evaluating this project to sync common files in multiple repositories. We have a home-baked shell script that does what it's expected, but looking for a more robust solution. And I wanted to give turbolift a try using dry-run mode 😄 Please ask anything you need during the review 🙏 |
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.
A few minor comments and suggestions but I like it!
Hi @rnorth sorry for the radio silence, I went on parental leave on Dec 10th, and I was back a few weeks ago. Returning activity on contributions at a slow pace :) |
From #38:
Sorry that we've had this change of heart, but think that #94 would be simpler, as well as easier to integrate. Thanks for your attempt to contribute though, @mdelapenya - I really appreciate your effort. |
What does this PR do?
It does a few things to achieve dry-run to work properly:
Infof
function to the logger, which uses a newInfo
color. This color will display the background in Cyan and the foreground in White.DryRun
flag, attached to the root command. This flag will be available to all subcommands.PreRun
stage. This function will check if theDryRun
flag is enabled, and print a message built with the previous blocks.DryRun
flag at all the implementations of the executors, so that the first thing that happens in there is checking ifDryRun
is true. If so, it will just print the command, arguments and workDir, returning without error. For the case of theExecuteAndCapture
function, it will return the very same string than the above implementation.Why is it important?
It will support testing locally changes before submitting real pull requests.
Other considerations
I probably missed some other places where the dry-run mode should be applied. Please point them out to me so that I can update the code.
Related issues