| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
Sorry, something went wrong.
|
@komawar thanks! Could you add a "negative control"? a test that fails if hasFipsCrypto, in test/parallel something like: const common = require('../common');
if (common.hasFipsCrypto) process.exit(1);
Then add an exception in parallel.status. That would serve as documentation as well. |
Sorry, something went wrong.
|
@refack Thanks for your review! Surely, let me look into it / wrap my head around this. |
Sorry, something went wrong.
|
Just wanted to leave a comment (ease the load on reviewers) on a sample test run which I conducted, here's the commit that details the run and marked tests as flaky (for testing purposes): |
Sorry, something went wrong.
|
Sure. Take a look at the current status file: node/test/parallel/parallel.status Lines 1 to 22 in c3ae57f |
Sorry, something went wrong.
|
@refack Oh I get it now! (I misread what you were saying there). Surely, I was hoping to get a pointer on how to best test this and here it is! perfect, I will add this. |
Sorry, something went wrong.
|
Maybe a most verbose way to "fail" the test is to use assert: if (common.hasFipsCrypto)
assert.fail(`expected to fail with FIPS enabled`) |
Sorry, something went wrong.
There was a problem hiding this comment.
Couple of thoughts
Sorry, something went wrong.
| // NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, | ||
| // DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR | ||
| // OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE | ||
| // USE OR OTHER DEALINGS IN THE SOFTWARE. |
There was a problem hiding this comment.
Copyright is not needed in new files AIUI (cc/ @jasnell for confirmation).
Sorry, something went wrong.
There was a problem hiding this comment.
This file has been removed as per @Trott 's suggestion.
Sorry, something went wrong.
| endif | ||
|
|
||
| test-on-fips: | ||
| $(PYTHON) tools/test.py --type=fips |
There was a problem hiding this comment.
I don't think a separate command is needed here, we have way too many commands as it is. Also we'd really need to provide a fips option for every make target that includes tools/test.py. I think what would be helpful is a way to pass arguments to tools/test.py calls using an environment variable, simillar to CONFIG_FLAGS. That should be done separately, so I'll raise a separate issue.
Sorry, something went wrong.
There was a problem hiding this comment.
ok. do you want me to wait until that's been discussed or should we go with something short term here?
Sorry, something went wrong.
There was a problem hiding this comment.
Thanks for that insight. The latest PR excludes these changes.
Sorry, something went wrong.
| help='Send SIGABRT instead of SIGTERM to kill processes that time out', | ||
| default=False, action="store_true", dest="abort_on_timeout") | ||
| result.add_option("--type", | ||
| help="Specifies the environment type the tests will run on, for example 'fips'", |
There was a problem hiding this comment.
So currently this only supports fips right? I think we should give an exhaustive list of the possible options, so maybe something like:
Specifies the type of build. Options: fips"
That way we can easily expand the list when we add more options (like shared).
Otherwise the for example is misleading.
Sorry, something went wrong.
There was a problem hiding this comment.
done. ty
Sorry, something went wrong.
| // This test will fail on fips. The corresponding line in | ||
| // parallel.status file makes sure this is marked as flaky and passes. | ||
| 'use strict'; | ||
| const common = require('../common'); |
There was a problem hiding this comment.
Can you order these as per the writing tests guide? Basically use strict, require common, comment.
Sorry, something went wrong.
There was a problem hiding this comment.
sure. thanks for pointing that out.
Sorry, something went wrong.
There was a problem hiding this comment.
ditto
Sorry, something went wrong.
|
Thanks for your reviews. I will wait until more comments, confirmations and direction has been discussed to update this. |
Sorry, something went wrong.
| At this point you are ready to make code changes and re-run the tests! | ||
| Optionally, continue below. | ||
|
|
||
| If you wish to run tests on specific systems, say ``fips``: |
There was a problem hiding this comment.
Nit: FIPS is not a system. (Is it more correct to call it a "configuration"?)
Sorry, something went wrong.
There was a problem hiding this comment.
This file has been removed as per your suggestion.
Sorry, something went wrong.
| ``` | ||
|
|
||
| This particular command will mark the tests specified in the \*.status files as | ||
| flaky. |
There was a problem hiding this comment.
This is confusing. Running make test-on-fips will not mark tests as flaky.
Sorry, something went wrong.
There was a problem hiding this comment.
ditto
Sorry, something went wrong.
| # Sample test (test-negative-on-fips) has been added to check the | ||
| # skip-on-fips feature (issue 14746) | ||
| [$type==fips] | ||
| test-negative-on-fips: PASS,FLAKY |
There was a problem hiding this comment.
I don't think this should be part of the PR nor the associated test. We don't have permanent entries in the *.status files. If something is in there, it's because the test is having a problem that needs to be addressed.
I don't believe we generally test the test.py code directly like this. That may not be a great practice, but trying to introduce it in this PR is probably not the way to go.
Sorry, something went wrong.
There was a problem hiding this comment.
This file has been removed as per your suggestion.
Sorry, something went wrong.
|
This is great and thanks for doing it! I think we only need the changes in test.py here. The changes to Makefile, parallel.status, the new test, and the documentation seem extraneous, which seems weird to say. "Hey, nice PR, but can you remove the tests and the documentation?" Yeah, that suggests a problem with our process. :-D You were probably just following the checklist so apologies for having our documentation make you do work that maybe wasn't necessary. :-( All that said, I would be excited to have a working skip-FIPS feature in test.py!!!!!! Let's do this thing! |
Sorry, something went wrong.
|
@Trott @refack @gibfahn thanks for your reviews. I was hoping that we sort of have a convergence of opinion for this conversation (given the views of three of your differed on the reviews) but in the interest of time, I have avoided the extra commits and the latest PR has just the test.py changes as per @Trott 's suggestion. Hopefully, that is okay with everyone referenced in the review process (and any following reviews)! I will create a different PR indicating that changes to test.py do not need (for most cases) the related changes as in this earlier PR. cheers |
Sorry, something went wrong.
There was a problem hiding this comment.
Nit (non-blocking): Can we format this more like existing options?
For example, using this as a model:
"The style of progress indicator (verbose, dots, color, mono, tap)"
...this would be:
"Type of build (default, fips)"
...or don't list the options at all if they're not enumerated by this file (which I don't see where they are).
Sorry, something went wrong.
There was a problem hiding this comment.
The options are default or fips AFAIK.
Sorry, something went wrong.
There was a problem hiding this comment.
Yeah, the options are default or fips.
You don't see the enumeration as there are no more choices and the existing code parses the type = fips to give you PASS, FAIL, SKIP functionality. It took me some time to figure this out, code is crazy old, pretty complicated to read and I do intend to follow up with a blog entry on this soon(ish), for knowledge sharing.
Sorry, something went wrong.
There was a problem hiding this comment.
... also this will have to change a bit for shared case when we might see some enumertaion
Sorry, something went wrong.
There was a problem hiding this comment.
@Trott (formatting has been done in latest)
Sorry, something went wrong.
|
There isn't any pre-existing functionality to already skip a test if an entry for type of fips if I include something like this in a .status file, is there? [$type==fips]
test-foo-bar: SKIP,FLAKY |
Sorry, something went wrong.
Yes, it should work out-of-the-box for:- [$type==fips] test-foo-bar: SKIP,FLAKY Please see an example test I've created here komawar@4a957ca , (had referenced this before but is hard to find so that's okay). This is one of the reasons I had added the negative sample test here komawar@5bf0d6a as suggested by @refack , itself acts as a bit documentation. But I do agree that we prolly shouldn't change the structure/type of tests in the repo like you mentioned earlier. Maybe we can have a "mock" test for such things but I don't see where it exists for tools/test.py -- ideas appreciated. May be something for future? |
Sorry, something went wrong.
|
So actually I think what would be really useful is if tools/test.py could auto-detect that you're running a fips build, and set the type accordingly. So instead of having to run tools/test.py --type=fips, you'd just run tools/test.py, and it would work out that node was a fips-enabled one. You can check that by doing node -p process.versions.openssl and checking that it contains the string fips. @komawar if you'd be up for implementing that that would be amazing. Let me know if you get stuck anywhere, I did something similar in this file recently, so could help out with it if needed. |
Sorry, something went wrong.
@gibfahn no issues, this looks like a good idea. gonna go at it.. However, I still think we need the --type, may be for future purposes or if you wanted to enforce default (or any other) behavior on specific systems. Thoughts? |
Sorry, something went wrong.
I think you're right, having the --type override the guessed version makes sense. And yes, we'll definitely want more types going forward. |
Sorry, something went wrong.
This has been done. |
Sorry, something went wrong.
Adds a way to mark a specified test as 'flaky' on fips compliant systems. Earlier, the ``tools/test.py`` script supported only 'mode', 'system' and 'arch' for test environment specification. This limits the ability to specify the behavior of tests and setting pre-determined behavior of the same on other types of systems. As an example, the feature request below indicates the need to specify certain tests as 'flaky' on fips compliant systems. It hints at future possibility of a shared library, which in turn may need a specifier for running tests. This commit introduces a new item in the ``env`` dict, called ``type`` which defaults to ``simple`` type. It also adds an optional command line argument ``--type``, which inputs strings. Current functionality extends to setting ``simple`` or ``fips`` for this ``type`` variable. However, extending it to further uses is rather simple by adding "if" conditions at appropriate places in the ``tools/test.py`` script. Fixes: issue 14746
Sorry, something went wrong.
Adds a way to mark a specified test as 'flaky' on fips compliant systems. Earlier, the ``tools/test.py`` script supported only 'mode', 'system' and 'arch' for test environment specification. This limits the ability to specify the behavior of tests and setting pre-determined behavior of the same on other types of systems. As an example, the feature request below indicates the need to specify certain tests as 'flaky' on fips compliant systems. It hints at future possibility of a shared library, which in turn may need a specifier for running tests. This commit introduces a new item in the ``env`` dict, called ``type`` which defaults to ``simple`` type. It also adds an optional command line argument ``--type``, which inputs strings. Current functionality extends to setting ``simple`` or ``fips`` for this ``type`` variable. However, extending it to further uses is rather simple by adding "if" conditions at appropriate places in the ``tools/test.py`` script. PR-URL: #16329 Fixes: #14746 Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
|
FYI: This change uses subprocess.check_output which is a python 2.7 only feature For the time being I've updated the workers to use python2.7 and opened #17381 to improve this change. /CC @nodejs/build |
Sorry, something went wrong.
|
Thanks for fixing @refack , wonder why it didn't fail pre-land CI. |
Sorry, something went wrong.
It did - node-test-commit-linux/14398 was part or the above mentioned node-test-pull-request/11661 |
Sorry, something went wrong.
|
So apparently it's not simple to upgrade CentOS6 to python2.7, so I'd rather fast-track #17381 then fiddle around with the system config. |
Sorry, something went wrong.
Adds a way to mark a specified test as 'flaky' on fips compliant systems. Earlier, the ``tools/test.py`` script supported only 'mode', 'system' and 'arch' for test environment specification. This limits the ability to specify the behavior of tests and setting pre-determined behavior of the same on other types of systems. As an example, the feature request below indicates the need to specify certain tests as 'flaky' on fips compliant systems. It hints at future possibility of a shared library, which in turn may need a specifier for running tests. This commit introduces a new item in the ``env`` dict, called ``type`` which defaults to ``simple`` type. It also adds an optional command line argument ``--type``, which inputs strings. Current functionality extends to setting ``simple`` or ``fips`` for this ``type`` variable. However, extending it to further uses is rather simple by adding "if" conditions at appropriate places in the ``tools/test.py`` script. PR-URL: #16329 Fixes: #14746 Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Adds a way to mark a specified test as 'flaky' on fips compliant systems. Earlier, the ``tools/test.py`` script supported only 'mode', 'system' and 'arch' for test environment specification. This limits the ability to specify the behavior of tests and setting pre-determined behavior of the same on other types of systems. As an example, the feature request below indicates the need to specify certain tests as 'flaky' on fips compliant systems. It hints at future possibility of a shared library, which in turn may need a specifier for running tests. This commit introduces a new item in the ``env`` dict, called ``type`` which defaults to ``simple`` type. It also adds an optional command line argument ``--type``, which inputs strings. Current functionality extends to setting ``simple`` or ``fips`` for this ``type`` variable. However, extending it to further uses is rather simple by adding "if" conditions at appropriate places in the ``tools/test.py`` script. PR-URL: #16329 Fixes: #14746 Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Adds a way to mark a specified test as 'flaky' on fips compliant systems. Earlier, the ``tools/test.py`` script supported only 'mode', 'system' and 'arch' for test environment specification. This limits the ability to specify the behavior of tests and setting pre-determined behavior of the same on other types of systems. As an example, the feature request below indicates the need to specify certain tests as 'flaky' on fips compliant systems. It hints at future possibility of a shared library, which in turn may need a specifier for running tests. This commit introduces a new item in the ``env`` dict, called ``type`` which defaults to ``simple`` type. It also adds an optional command line argument ``--type``, which inputs strings. Current functionality extends to setting ``simple`` or ``fips`` for this ``type`` variable. However, extending it to further uses is rather simple by adding "if" conditions at appropriate places in the ``tools/test.py`` script. PR-URL: #16329 Fixes: #14746 Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
Adds a way to mark a specified test as 'flaky' on fips compliant systems. Earlier, the ``tools/test.py`` script supported only 'mode', 'system' and 'arch' for test environment specification. This limits the ability to specify the behavior of tests and setting pre-determined behavior of the same on other types of systems. As an example, the feature request below indicates the need to specify certain tests as 'flaky' on fips compliant systems. It hints at future possibility of a shared library, which in turn may need a specifier for running tests. This commit introduces a new item in the ``env`` dict, called ``type`` which defaults to ``simple`` type. It also adds an optional command line argument ``--type``, which inputs strings. Current functionality extends to setting ``simple`` or ``fips`` for this ``type`` variable. However, extending it to further uses is rather simple by adding "if" conditions at appropriate places in the ``tools/test.py`` script. PR-URL: #16329 Fixes: #14746 Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
|
This would be good to have on v6.x-staging? Could someone backport this with #17381? Guide is here. |
Sorry, something went wrong.
Adds a way to mark a specified test as 'flaky' on fips compliant systems. Earlier, the ``tools/test.py`` script supported only 'mode', 'system' and 'arch' for test environment specification. This limits the ability to specify the behavior of tests and setting pre-determined behavior of the same on other types of systems. As an example, the feature request below indicates the need to specify certain tests as 'flaky' on fips compliant systems. It hints at future possibility of a shared library, which in turn may need a specifier for running tests. This commit introduces a new item in the ``env`` dict, called ``type`` which defaults to ``simple`` type. It also adds an optional command line argument ``--type``, which inputs strings. Current functionality extends to setting ``simple`` or ``fips`` for this ``type`` variable. However, extending it to further uses is rather simple by adding "if" conditions at appropriate places in the ``tools/test.py`` script. PR-URL: #16329 Fixes: #14746 Reviewed-By: Gibson Fahnestock <gibfahn@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Ruben Bridgewater <ruben@bridgewater.de>
| Back | FazBrowse Home | New Git URL |
Adds a way to mark a specified test as 'flaky' on fips compliant
systems.
Earlier, the tools/test.py script supported only 'mode',
'system' and 'arch' for test environment specification. This limits the
ability to specify the behavior of tests and setting pre-determined
behavior of the same on other types of systems. As an example, the
feature request below indicates the need to specify certain tests as
'flaky' on fips compliant systems. It hints at future possibility of a
shared library, which in turn may need a specifier for running tests.
This commit introduces a new item in the env dict, called type
which defaults to simple type. It also adds an optional command
line argument --type, which inputs strings. Current functionality
extends to setting simple or fips for this type variable.
However, extending it to further uses is rather simple by adding "if"
conditions at appropriate places in the tools/test.py script.
Fixes: #14746
Checklist
Affected core subsystem(s)