`waitForSelector` returns immediately if the selector is already
present (which is documented). This means that the waitForSelector
after the second follow isn’t doing anything since we already waited
for after the first follow. `waitForFunction` seemed like the simplest
solution and doesn’t require patching the HTML which is a bit finnicky
in the compat tests.
changelog_begin
changelog_end
* Upgrade puppeteer
We’ve seen a couple of issues in the compatibility tests of the form
```
Error: Protocol error (Runtime.callFunctionOn): Target closed.
```
Looking at the issue tracker in puppeteer this might be fixed in newer
versions and I don’t see why we should stick to a fairly old version
anyway.
changelog_begin
changelog_end
* Upgrade nodejs
changelog_begin
changelog_end
* temporary add a step to kill node_modules
changelog_begin
changelog_end
* Kill live server and try to fix Windows
changelog_begin
changelog_end
* Undo rm
changelog_begin
changelog_end
* Include puppeteer tests in compat tests
This PR adds the puppeteer based tests to the compatibility
tests. This also means that they are now actually compatibility
tests. Before, we only tested the SDK side.
Apart from process management being a nightmare on Windows as usually,
there are two things that might stick out here:
1. I’ve replaced the `sh_binary` wrapper by a `cc_binary`. There is a
lengthy comment explaining why. I think at the moment, we could
actually get rid of the wraper completely and add JAVA to path in
the tests that need it but at least for now, I’d like to keep it
until we are sure that we don’t need to add more to it (and then
it’s also in the git history if we do need to resurrect it).
2. These tests are duplicated now similar to the `daml ledger *`
tests. The reasoning here is different. They depend on the SDK
tarball either way so performance wise there is no reason to keep
them. However, we reference the other file in the docs which means
we cannot change it freely. What we could do is to make this
sufficiently flexible to handle both the `daml start` case and
separate `daml sandbox`/`daml json-api` processes and then we can
reference it in the docs. There is still added complexity for
Windows but that’s necessary for users as well that want to run
this on Windows so that seems unavoidable. (I should probably also
remove my snarky comments 😇) I’d like to kee it duplicated
for this PR and then we can clean it up afterwards.
changelog_begin
changelog_end
* Bump timeouts
changelog_begin
changelog_end
Previously we changed to running the sandbox and JSON API separately to
have more control over port allocation. Now the same behaviour is
possible using `daml start`, which is preferable because it's what we
suggest users of the Getting Started Guide should use. This change
returns to using `daml start` in the end-to-end test. We use the default ports
for the sandbox and JSON API as we do in the guide.
changelog_begin
changelog_end
changelog_begin
changelog_end
* Be a bit more generous with the login/logout test timeout
* Use fsPromises.stat and remove port files before starting to be safe
This PR gets yarn test running the Puppeteer end-to-end tests in the GSG integration test.
The first step of the test is adding the extra dependencies (Jest, Puppeteer and more). The GSG recommends a yarn add command, but this does not work against HEAD. This is because yarn add does not use resolutions in the parent package.json, and then complains about unknown versions 0.0.0 of the daml TS libaries. The solution here is to hack in the extra dependencies into the ui/package.json and then yarn install. This works, but it hard codes version numbers which we would need to maintain. I would like to be able to say version "latest", which is what yarn add would install.
The next step of the test is to copy the index.test.ts file and run yarn test in CI mode.
I've moved the GSG test to a new create-daml-app-tests target. It's marked "exclusive" in Bazel until we figure out how to avoid hardcoding port numbers. This is a bit tricky since the HTTP port is hardcoded in a couple of places in ui/package.json.
Finally, this PR gets the GSG testing docs to reference the code in the new templates/create-daml-app-test-resources folder.
changelog_begin
changelog_end
