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

Enhancement: Supporting deep comparison of tasks with reference value in custom properties #9647

Conversation

magician-margatroid
Copy link
Contributor

@magician-margatroid magician-margatroid commented Jun 28, 2021

What it does

Fixes: #9646

Issue link: in short, tasks with same content but different reference value as custom properties are treated as different tasks, e.g., [], {prop: 'value'}. This can lead to duplicate execution of same task.

This PR includes 2 commits:

  1. Add several unit test cases for task-definition-registry.ts to ensure the logic of distinguishing.
  2. Change shallow comparison into deep comparison of properties in compareTasks method.

How to test

  • Unit test:

    • I've added some cases in the 1st commit.
    • Before the changes in 2nd commit, tests for @theia/task will ends up with 33 passing and 2 failing.
    • After the changes in 2nd commit, tests for @theia/task will ends up with 35 passing and 0 failing.
  • Manually integration test:

    • Just follow the exact steps in the issue linked above.
    • Before changes, the task can be run for several time no need former execution ends.
    • After changes, "Task is already running" will be prompted for user if former execution doesn't end. (Which is also in consistency with VSCode.)

Review checklist

Reminder for reviewers

These cases includes the conditions when tasks with reference value as custom properties.
In tests with @thiea/task, 33 passing and 2 failing is expected.

Signed-off-by: Victor Li <[email protected]>
…operties deeply.

All the unit-test cases for @thiea/task is expected to pass. (35 passing, 0 failing)

Signed-off-by: Victor Li <[email protected]>
@@ -15,6 +15,7 @@
********************************************************************************/

import { expect } from 'chai';
import { foobarTaskFixture } from '../node/test/test-helper';
Copy link
Member

Choose a reason for hiding this comment

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

@magician-margatroid browser (frontend) should not import anything from node (backend), even if it is simply for test purposes: code organization. Given that the foobarTaskFixture is simply for test purposes, you can include the contents directly in the task-definition-registry.spec.ts file.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you very much @vince-fugnitto . Excuse me and I'll improve it.

@vince-fugnitto vince-fugnitto added the tasks issues related to the task system label Jun 28, 2021
* Moving foobarTaskFixture into task-definition-registry.spec.ts.

Signed-off-by: Victor Li <[email protected]>
@magician-margatroid
Copy link
Contributor Author

Hi @vince-fugnitto , when you have the time, could you pls help to have a look at the build check result?

As it indicates, it seems the Build / ubuntu-18.04, Node.js v12.x (pull_request) failed after 14m — ubuntu-18.04, Node.js v12.x.

I found root ERROR [nsfw-watcher: 9379] NSFW service error on "/home/runner/work/theia/theia/examples/browser": [Error: Service shutdown unexpectedly] and several other errors in the log, but still not very sure about the root cause.

Personally I think this new commit doesn't have side effects, and also executed unit-tests locally with all-green.

@magician-margatroid
Copy link
Contributor Author

Hi @vince-fugnitto , when you have the time, could you pls help to have a look at the build check result?

As it indicates, it seems the Build / ubuntu-18.04, Node.js v12.x (pull_request) failed after 14m — ubuntu-18.04, Node.js v12.x.

I found root ERROR [nsfw-watcher: 9379] NSFW service error on "/home/runner/work/theia/theia/examples/browser": [Error: Service shutdown unexpectedly] and several other errors in the log, but still not very sure about the root cause.

Personally I think this new commit doesn't have side effects, and also executed unit-tests locally with all-green.

Thanks. This time all that succeeded.

reveal: RevealKind.Always,
showReuseMessage: true,
};
const foobarTaskFixture = {
Copy link
Member

Choose a reason for hiding this comment

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

minor: what does a fixture represent, it is the first time I heard of this terminology for tasks.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice point. Well, frankly I didn't aim to use it exclusively for tasks, but I mean to use "test fixtures" here. In my understanding fixture can be something stable across runs of tasks. E.g., a file loaded with sample data or a script setting up stable env for task.

Perhaps here I need to change it into mock or fake.

foobarTaskFixture.conf('id_1', 'type_1'),
foobarTaskFixture.conf('id_2', 'type_2'),
);
expect(res).to.be.not.ok;
Copy link
Member

Choose a reason for hiding this comment

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

minor: rather than okayness, we can simply do truthy checks.

expect(res).to.be.true;

or

expect(res).equal(true);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Good suggestion. I'll change it in this way.

});

it('should return true if given 2 same task configurations with empty arrays (different by reference) as custom property', () => {
const res = registry.compareTasks(
Copy link
Member

Choose a reason for hiding this comment

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

I see the use of res a lot in the tests, what does it represnt? Perhaps a clearer name should be used?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nice suggestion. I agree and I meant "result" here. I'll change them.

* Change okayness into truthy checks.

Signed-off-by: Victor Li <[email protected]>
Copy link
Contributor

@alvsan09 alvsan09 left a comment

Choose a reason for hiding this comment

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

I have tested this change and it works as expected 👍

The code looks good to me as well!
Thanks @magician-margatroid !

@magician-margatroid
Copy link
Contributor Author

I have tested this change and it works as expected

The code looks good to me as well!
Thanks @magician-margatroid !

Ah, good to know it, @alvsan09 thx for your testing. It's my pleasure.

Copy link
Member

@vince-fugnitto vince-fugnitto left a comment

Choose a reason for hiding this comment

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

The changes work well for me, I verified with the described steps in #9646 👍
Thank you for the contribution, and looking forward to many more in the future!

@RomanNikitenko
Copy link
Contributor

RomanNikitenko commented Jul 16, 2021

I tried to test according to the steps to reproduce secion.
It's strange, but I don't see the custombuildscript: 32 watch incremental task
custom_pr

For the master I do see it
custom_master

Also, the order is different.
Could someone confirm that the problem is on my side only...
thanks in advance!

p/s
I installed the extension as vsix
I used multi-root workspace for testing
I'm on macos

@RomanNikitenko
Copy link
Contributor

I found what's the problem...
It looks like I selected Never scan the task output at running the task.
Then the task was converted to configured with another label.

cust_tasks_config.mp4

Copy link
Contributor

@RomanNikitenko RomanNikitenko left a comment

Choose a reason for hiding this comment

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

Tested according to the steps to reproduce section of the issue, it works well for me.
I think it makes sense to squash the changes in 1 or 2 commits before merging.

@vince-fugnitto vince-fugnitto merged commit d5c9fb7 into eclipse-theia:master Jul 16, 2021
@vince-fugnitto
Copy link
Member

I used the new squash and merge option to merge the commit 👍

@magician-margatroid
Copy link
Contributor Author

Hi everyone, thanks a lot for all your work. It's my pleasure and appreciate your help and analysis all the way.

@vince-fugnitto vince-fugnitto added this to the 1.16.0 milestone Jul 29, 2021
dna2github pushed a commit to dna2fork/theia that referenced this pull request Aug 25, 2021
… in custom properties (eclipse-theia#9647)

The commit adds deep comparison of tasks, including tests:
- use `JSONExt.deepEqual` from `@phosphor/coreutils` to compare custom properties deeply.
- add unit-test cases for `compareTasks` in `task-definition-registry.ts`: these cases includes the conditions when tasks with reference value as custom properties.

Signed-off-by: Victor Li <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
tasks issues related to the task system
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Supporting deep comparison of custom properties while distinguishing tasks.
4 participants