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
test(structure): consolidated all verification under the test
script while also enabling isolated execution
#2964
Conversation
d43bfcb
to
cdd67be
Compare
"mockserver-client": "5.15.0", | ||
"nock": "13.3.3", | ||
"npm-run-all2": "6.0.6", |
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.
i've used npm-run-all for a long time with success, but the original version has grown stale. npm-run-all2 is a community maintenance fork. see https://github.com/bcomnes/npm-run-all2?tab=readme-ov-file#npm-run-all2-why for more detail
"semantic-release": "./bin/semantic-release.js", | ||
"test": "c8 ava --verbose", | ||
"test:ci": "c8 ava --verbose" | ||
"test": "npm-run-all --print-label --parallel lint:* --parallel test:*", |
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.
this more intentionally makes the test
script execute all verification scripts. each of the referenced scripts are still available for isolated execution, but this makes them roll up automatically, even if new scripts are added later.
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.
worth noting that the :*
glob only matches scripts at a single level, so scripts like lint:js:fix
are not matched, but lint:js
, lint:lockfile
, and lint:engines
are.
"test:unit": "c8 ava --verbose", | ||
"test:integration": "ava --verbose test/integration.test.js" |
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.
i normally find value in being able to execute unit and integration tests separately and have found ava being configured to always run all tests together a bit awkward. this way they can be run separately, but both suites still get run as part of the overall test
script.
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.
i think this is especially valuable since we've had some instability with the integration tests. i think that instability is somewhat to be expected with the broad scope covered by the integration tests. however, being able to run the unit tests without that complexity makes the feedback loop there quicker and more stable
"test:unit": "c8 ava --verbose", | ||
"test:integration": "ava --verbose test/integration.test.js" |
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.
i removed c8
from the integration run since i figure our coverage goal is likely more limited to unit tests and including the integration tests ends up skewing those results
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.
i also suspect that c8 may be introducing some of the instability in the already complicated integration tests
@@ -6,7 +6,8 @@ | |||
"author": "Stephan Bönnemann <stephan@boennemann.me> (http://boennemann.me)", | |||
"ava": { | |||
"files": [ | |||
"test/**/*.test.js" | |||
"test/**/*.test.js", | |||
"!test/integration.test.js" |
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.
this is what excludes the integration tests from the unit test suite. note that this file is run directly for the script that defines the integration suite. i still am not super strong with this level of detail with ava, so open to feedback if there are better ways to define test suites like the unit and integration that i'm targeting with this change
.github/workflows/test.yml
Outdated
# verify against the node version defined for development in the .nvmrc | ||
test_dev: | ||
runs-on: ubuntu-latest | ||
timeout-minutes: 5 | ||
|
||
steps: | ||
- uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4 | ||
- run: git config --global user.name github-actions | ||
- run: git config --global user.email github-actions@github.com | ||
- name: Use Node.js from .nvmrc | ||
uses: actions/setup-node@5e21ff4d9bc1a8cf6de233a3057d20ec6b3fb69d # v3 | ||
with: | ||
node-version-file: .nvmrc | ||
cache: npm | ||
- run: npm clean-install | ||
- run: npm audit signatures | ||
- run: npm test |
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.
this is a duplicate job with the matrix job, but has a separate goal. the matrix suite would be to ensure verification passes for versions defined as supported in engines.node
. this job is specific to the version defined in the recently added .nvmrc
file, which is intended to define our development node version.
one benefit to this that might not be obvious is that this would prevent a renovate PR to update the node version in the .nvmrc
file from being merged if it upgrades to a version where our verification fails
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.
i would totally be open to just adding to the existing matrix list rather than having a separate job, but i've never investigated far enough to find a clean way to read the value from the .nvmrc file and include it in the matrix definition
@@ -25,7 +26,7 @@ jobs: | |||
- 20 | |||
|
|||
runs-on: ubuntu-latest | |||
timeout-minutes: 10 | |||
timeout-minutes: 5 |
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.
this isnt specific to the restructuring, but noticed it while going through the details.
ava is currently configured to timeout after 2 minutes, so 10 minutes just results in unnecessary waiting
42c2954
to
12fe1d9
Compare
"lint:prettier:fix": "prettier --write \"*.{js,json,md}\" \".github/**/*.{md,yml}\" \"docs/**/*.md\" \"{bin,lib,test}/**/*.js\"", | ||
"lint:lockfile": "lockfile-lint", | ||
"lint:engines": "ls-engines", | ||
"lint:publish": "publint --strict", |
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.
publint is helpful to ensure we get the details right for compatibility with consumers. for example, it would have highlighted that we forgot to define exports
before the most recent major version
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.
Cool, TIL!
.github/workflows/test.yml
Outdated
- uses: actions/checkout@3df4ab11eba7bda6032a0b82a6bb43b11571feac # v4 | ||
- uses: actions/setup-node@5e21ff4d9bc1a8cf6de233a3057d20ec6b3fb69d # v3 | ||
- run: git config --global user.name github-actions | ||
- run: git config --global user.email github-actions@github.com | ||
- name: Use Node.js from .nvmrc | ||
uses: actions/setup-node@5e21ff4d9bc1a8cf6de233a3057d20ec6b3fb69d # v3 | ||
with: | ||
node-version: lts/* | ||
node-version-file: .nvmrc | ||
cache: npm | ||
- run: npm clean-install | ||
- run: npm audit signatures | ||
- run: npm run lint |
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.
since this job is now specifically about summarizing the verification results from the test_dev
and test_matrix
jobs, it doesnt need to checkout, setup node, or run additional verification
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.
looks all good to me so far 👍🏼
@fgreinacher, @seebeen i'm interested in your thoughts and especially if you have any concerns with this approach. if we do continue down this path, we would probably try to apply a similar approach across at least the core plugins and eventually further. leaving in draft for now since i still want to update the contributing guide related to these adjustments |
This comment has been minimized.
This comment has been minimized.
I like it 💯 |
and used npm-run-all2 to define verification script groups that can be parallelized while also enabling scripts to be run independantly for semantic-release/.github#19
…deps from malicious registries i thought we'd already taken the step of adding this protection, but it looks like i failed to follow up with getting applied across all repos
…he combined test process
…ased on conversation result
… intended for development to help ensure all verification passes before deciding to update the development version (partly to help automate this process with renovate)
…ckout and setup since the purpose of this job is specifically to summarize the verification results
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.
great work @travi ❗
while also enabling isolated execution. similar to semantic-release/semantic-release#2964 for semantic-release/.github#19
🎉 This PR is included in version 22.0.6 🎉 The release is available on: Your semantic-release bot 📦🚀 |
as a follow up to #2963, we need to adjust the
test
job, which i think means moving the lint script back into thetest_matrix
jobs at minimum. i think that gives us a good opportunity to rethink how we structure the jobs, so putting this together for discussion.this is very close to the structure i normally use outside of semantic-release, but does introduce a few things that we'd agreed to avoid previously. i'm still open to avoiding those things if we decide to, but wanted to start the conversation here so that the alternative approach is more clear by having a functional example to tinker with.
for semantic-release/.github#19