test: add tests for fsPromises.truncate and FileHandle.truncate

[shisama]

To increase test coverage, added tests for fsPromises.truncate
and FileHandle.truncate.

Checklist

• make -j4 test (UNIX), or vcbuild test (Windows) passes
• commit message follows commit guidelines

[BridgeAR]

CI https://ci.nodejs.org/job/node-test-pull-request/14942/

[jasnell]

Appears this failed CI entirely.

[Trott]

test-fs-promises.js fails

[Trott]

You checked the box for running make -j4 test or vcbuild test. Can you paste the last few lines of output?

[shisama]

@Trott I made mistake. uncheked the box. I'll fix it and test it on linux and macOS.

[shisama]

Fixed it and test passed on macOS and ubuntu.

[Trott]

CI: https://ci.nodejs.org/job/node-test-pull-request/15135/ ✔️

Feel free to dismiss my review if CI results are good.

Dismissed as suggested.

[BridgeAR]

Landed in e5a3579 🎉

[Trott]

Dismissed as suggested.

@BridgeAR For the record, and this is on me for not being clear, when I say "CI looks good", I don't mean "it's red but hey, we know it's OK". I think we should re-run the red CI until we get green or yellow.

I'll try to remember to explicitly write "CI is yellow or green" next time.

I'd like us to stop landing code with red CIs altogether. The Collaborator Guide comes close to saying that, but has a final sentence with enough wiggle room to land with red unfortunately:

Do not land any Pull Requests without passing (green or yellow) CI runs. If you believe any failed (red or grey) CI sub-tasks are unrelated to the change in the Pull Request, you may re-run the sub-task to try to see if it passes (just open the failed sub-task page and press the "Rebuild" button; be sure you are still logged in for this action). If re-runs of all failed sub-tasks pass (do not forget to provide the links for successfully rerun sub-tasks), it is permissible to land the Pull Request but only if the initial failures are believed in good faith to be unrelated to the changes in the Pull Request. Otherwise, reasonable steps must be taken to confirm that the changes are not resulting in an unreliable test.

[BridgeAR]

@Trott I do not think that this is currently feasible / a good idea. I have not seen our CI green since a very long time and we run into new issues all the time (both test wise and infrastructure wise). Most of our PRs clearly do not touch a lot of spots and it should be good to land almost any PR if the person who does that feels safe that the failures are a) unrelated or b) if the infrastructures failed should not bring any further confidence about the patch because it is already tested properly by the other passed ones.

Right now we get 94 PRs each week and it is a huge overhead to rerun each small task over and over. I would love if we have a automation to rerun a task at least once if there is a infrastructure failure but we can not even automate landing because the CI has to many failures. As soon as we do have a green CI, we can talk about these things again.

[addaleax]

Note to backporters: This depends on #20559, so please don’t request a backport.