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

added suspending update renderer for task #136

Open
wants to merge 13 commits into
base: master
Choose a base branch
from

Conversation

bunysae
Copy link

@bunysae bunysae commented Sep 3, 2019

In order to fix issue np issue 79, these changes add an optional suspend-flag for every task.
The suspend-flag is later used, to suspend the listr-update-renderer.

lib/task.js Outdated Show resolved Hide resolved
lib/task.js Outdated
}

get subtasks() {
return this._subtasks;
}

shouldSuspendUpdateRenderer() {
try {

Choose a reason for hiding this comment

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

Why are you try/catching a boolean?

Copy link
Author

@bunysae bunysae Sep 14, 2019

Choose a reason for hiding this comment

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

I catching it, because task.options can be undefined. Without catching it, it throws TypeError, if you don't supply any option.

@@ -43,12 +43,22 @@ class Task extends Subject {
this.title = task.title;
this.skip = task.skip || defaultSkipFn;
this.task = task.task;
this.taskOptions = task.options;

Choose a reason for hiding this comment

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

This is moot. You can already access it as this.task.options.

Copy link
Author

@bunysae bunysae Sep 14, 2019

Choose a reason for hiding this comment

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

Sorry, but this.task can be just a function. task.options refers to input-variable task given in the constructor and not to this.task. We will need here a separate variable to store the options.

@sindresorhus
Copy link

The new option should be documented and tested.

@bunysae
Copy link
Author

bunysae commented Sep 14, 2019

@sindresorhus:
Unit-tests are finished for the new feature.
Travis throw this error, because pull-request in listr-update-renderer isn't merged yet.

The diffs in the other files are coming from the command npx xo --fix.
It changed the position of Listr in the import-commands.

@codecov-io
Copy link

codecov-io commented Sep 18, 2019

Codecov Report

Merging #136 into master will decrease coverage by 17.96%.
The diff coverage is 25%.

Impacted file tree graph

@@             Coverage Diff             @@
##           master     #136       +/-   ##
===========================================
- Coverage   96.31%   78.35%   -17.97%     
===========================================
  Files           7        7               
  Lines         190      194        +4     
===========================================
- Hits          183      152       -31     
- Misses          7       42       +35
Impacted Files Coverage Δ
lib/task.js 82.95% <25%> (-17.05%) ⬇️
lib/listr-error.js 33.33% <0%> (-66.67%) ⬇️
lib/task-wrapper.js 40% <0%> (-50%) ⬇️
lib/state.js 33.33% <0%> (-44.45%) ⬇️
index.js 92.72% <0%> (-7.28%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update fe40ce5...0327ff7. Read the comment docs.

@bunysae
Copy link
Author

bunysae commented Oct 5, 2019

@sindresorhus:
In an second pull-request i repaired the failing tests.
Between the last successful build and now ava changed. and therefore a lot of the current tests are failing in the travis build.
I hope after merging the new pull-request, we can continue with merging this request.

@bunysae
Copy link
Author

bunysae commented Oct 8, 2019

Anyone interested to review this pull-request and the affiliated pull-request 137?

lib/task.js Outdated Show resolved Hide resolved
readme.md Outdated Show resolved Hide resolved
readme.md Outdated Show resolved Hide resolved
@@ -1,8 +1,8 @@
import {serial as test} from 'ava';
import delay from 'delay';
import Listr from '..';

Choose a reason for hiding this comment

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

Why did you edit these files? They're out of the scope of this PR anyways, and the imports were fine the way they were.

Copy link
Author

Choose a reason for hiding this comment

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

The changes come from xo --fix command. I remove them in my next commit.

test/suspend.js Outdated
console.log(text);
}
};
logUpdateApi.main.clear = function () {

Choose a reason for hiding this comment

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

You should create a noop function (e.g. const noop = () => {};) and use it here and below.

Copy link
Author

Choose a reason for hiding this comment

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

I imported the log-update-module directly. This section now should be refactored.

test/suspend.js Outdated
mockery.enable({useCleanCache: true, warnOnUnregistered: false});
});

test('should suspend second task', async t => {

Choose a reason for hiding this comment

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

This doesn't test use-cases where suspendUpdateRenderer is actually needed. There should be a test(s) for that as well.

Choose a reason for hiding this comment

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

Copy link
Author

Choose a reason for hiding this comment

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

My intention was to create two task. The first task without the option suspendUpdateRenderer. So the update renderer should display status "task 1 pending" exactly one time. The second task with the option suspendUpdateRenderer. So the update renderer shouldn't display status "task 2 pending", because it is suspended. If the suspend-function doesn't work as expected, the update renderer displays "task 2 pending" more than once, because we have a timeout of 4s.
You could simply try it, when cloning my fork listr locally. With the current version of listr-update-renderer, the tests fail. With linking my fork of listr-update-renderer the tests pass.

What tests you thought of? Integration-tests, which ask for user input or tests, which mock listr-update-renderer?

Copy link

@itaisteinherz itaisteinherz Feb 18, 2020

Choose a reason for hiding this comment

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

What I thought of is a test case in which the suspension is actually required, meaning that the test won't pass if the task isn't suspended (and only passes if it is).
(Even if the mock isn't called, that doesn't really mean much. We want the test to verify correct behavior, not logic.)

Copy link
Author

Choose a reason for hiding this comment

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

I added now a custom renderer mock, which output is excatly verified. It only passes, if suspension is activated.
When the mock isn't called with the correct args, the test fails.

Choose a reason for hiding this comment

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

I'm sorry to keep bothering you, but this is still not what I meant in my comments above.
As I recall, the reason we need this in np is since one of the commands we call waits for the user to enter a password, which we need to receive before moving on to the next task.
This test, again, only verifies we correctly pass on the suspendUpdateRenderer option from here to the Listr renderer (let me know if I'm mistaken, though).
I think that the simplest way to test this would be to actually run a command that waits for user input, then verify we do receive it when suspendUpdateRenderer is set to true (and don't when it's set to false, as the task isn't suspended).

Copy link
Author

@bunysae bunysae Mar 6, 2020

Choose a reason for hiding this comment

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

The problem isn't, that the task can't receive the user-input from stdin. The task actually receives the input from stdin independently of suspendUpdateRenderer. The problem is, that listr-update-renderer erases password-prompts on stdout. For the user it looks like the prompt never appears and the task is running infinite.
What we need to check is, that the task-output is not erased by the log-update-module, when a task with suspended renderer is running. I have done that in my actual version.

Copy link
Author

Choose a reason for hiding this comment

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

@itaisteinherz
Btw i added the testclass task-with-input, which proves, that the input from stdin is available for every task, no just for the tasks with suspended renderer.

readme.md Outdated Show resolved Hide resolved
1. Refactoring test-classes and readme
2. play back import order
@bunysae
Copy link
Author

bunysae commented Apr 30, 2020

@itaisteinherz or @LitoMore
Now the lint errors are fixed. Can you review it again?

@LitoMore
Copy link
Collaborator

LitoMore commented May 25, 2020

@bunysae Thank you so much! I will review your PR in few days.

@sindresorhus
Copy link

@LitoMore @SamVerschueren Bump :)

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

Successfully merging this pull request may close these issues.

5 participants