chore: run website tests against netlify deployment #6212
Conversation
|
Thanks for the PR, @JamesHenry! typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community. The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately. Thanks again! 🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. |
✅ Deploy Preview for typescript-eslint ready!
To edit notification comments on pull requests, go to your Netlify site settings. |
JamesHenry
force-pushed
the
run-website-tests-against-netlify-deployment
branch
from
898afe4
to
f57d58f
Compare
JamesHenry
force-pushed
the
run-website-tests-against-netlify-deployment
branch
from
f57d58f
to
db1ef3d
Compare
JamesHenry
force-pushed
the
run-website-tests-against-netlify-deployment
branch
from
db1ef3d
to
b0b3d63
Compare
| @@ -15,8 +15,6 @@ test.describe('Website', () => { | |||
| } | |||
| }); | |||
| await page.goto('/'); | |||
| expect(errorMessages).toStrictEqual([ | |||
| "[error] Warning: ReactDOM.render is no longer supported in React 18. Use createRoot instead. Until you switch to the new API, your app will behave as if it's running React 17. Learn more: https://reactjs.org/link/switch-to-createroot", | |||
There was a problem hiding this comment.
This error message was only applicable to the local dev-server and is not shown to our users on production builds. A nice extra benefit of this approach is that our testing is more representative of our end UX
|
The remaining website test failure is consistent with the same failure on the latest main run, so it is not related to the changes. UPDATE: confirms the failure happens locally too |
| @@ -179,26 +179,38 @@ jobs: | |||
| contents: read # to fetch code (actions/checkout) | |||
|
|
|||
| name: Website tests | |||
| # We technically do not need to wait for build within the pipeline any more because the build we care about is happening within Netlify, however, | |||
| # it is highly likely that if the CI one fails, the Netlify one will as well, so in order to not waste unncessary Github Actions minutes/resources, | |||
| # we do still keep this requirement here. | |||
Rather than running an extra dev-server on localhost within the Github agent, which has proven to be flaky, this runs the website tests against the actual Netlify deployment which we are doing anyway as part of our workflow.
In my initial implementation I had a very convoluted way of achieving it via Netlify build hooks and a webhook handler which triggered an additional workflow.
It has proven to be much simpler by leveraging the Netlify API instead (which was already done by an existing Github Action from the community)