It looks like, at least on some machnes, recent Node versions will not
resove localhost to 127.0.0.1 anymore.
There wasn't really a good reason for us going through DNS resolution
for these anyway, so here's a simple fix. Hopefully.
This is very much a "just make it work" type of patch. The main issues
were:
- A bunch of type errors in the `index.test.ts` file when opened in VS
Code. I'm not sure how it happened, but it's possible I'm just using a
more recent TS compiler than whoever edited this last.
- `localhost`, on my machine at least, resolves to `::1`, and therefore
the connections were just not established. I've opted for replacing
`localhost` with explicit `127.0.0.1`.
- `npm-cli.js` was not an executable in my `PATH`, and won't be for
most users, but `npm` is not on our testing infrastructure's `PATH`.
Those tests are obviously not tested by CI, so please review carefully /
test this on your own machine before approving.
CHANGELOG_BEGIN
CHANGELOG_END
* Create alias contracts in frontend in create-daml-app
Creating them in the setup script is nice but it makes it much harder
to port this to Daml hub where we cannot rely on this.
This also requires figuring out the public party in the frontend.
I’ve chosen to infer it from the user rights which seems broadly
sensible.
For the backwards compat mode, I just hardcoded it because there isn’t
a great way to figure it out.
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* Bump Canton and reenable tests
fixes#12808
changelog_begin
changelog_end
* display names are no longer defaulted
changelog_begin
changelog_end
* topology-change-delay is redundant
changelog_begin
changelog_end
* Switch away from grpcurl
changelog_begin
changelog_end
* try to fix canton conformance tests
changelog_begin
changelog_end
* that’s not how you scala
changelog_begin
changelog_end
changelog_begin
Ledger API Specification: CreateUser and GetUser endpoints of UserManagementService now return the CreateUserResponse or GetUserResponse messages, whereas previously they were returning the User message).
changelog_end
CHANGELOG_BEGIN
Ledger API Specification: Maximum number of user rights per user is now limited to 1000 and is added to UserManagementFeature in VersionService. getLedgerApiVersion endpoint.
CHANGELOG_END
* create-daml-app: Use alias templates for display names
We introduce Alias contracts to the create-daml-app Daml model and use
them to display aliases in the UI instead of party identifier strings.
CHANGELOG_BEGIN
CHANGELOG_END
* fix tests
* addressing review
* Add comments to Setup.daml
* factor out alias to option conversion
CHANGELOG_BEGIN
CHANGELOG_END
* small fix in setup.daml
* replace user dropdown with input in login screen
* fix compatibility tests
* fix alias loading flick in mainscreen
* remove canton incompatible sandbox options from daml.yaml
* fix gsg-trigger.patc
`alert` isn’t exactly great error handling but matches what we do in
other places of create-daml-app and I’m not all that keen on reworking
that everywhere for 2.0
fixes#12275
changelog_begin
changelog_end
* Rename daml sandbox to daml sandbox-kv
Also drop the default sandbox on `daml start`
Part of #11831
changelog_begin
changelog_end
* update release test instructions
* try to fix a couple compat tests
* dont need special 0.0.0 logic
* buildifier-fixx
Somewhat error-prone, so please review carefully.
Reasons we need this:
- Some file types are not properly handled by the script.
- The only exclusion mechanism we currently have (`NO_AUTO_COPYRIGHT`)
is overly coarse.
CHANGELOG_BEGIN
CHANGELOG_END
* Initial work-in-progress
changelog_begin
[TS bindings] When using daml-react and daml-ledger, all streaming request to the query endpoint will be multiplexed through a single web socket.
changelog_end
* Minor touches, renaming
* Handle offsets received from the JSON API
* Create state array once per downstream consumer
* Handle reconnections as streamSubmit does
* Don't share mutable state between events
* Fix compilation errors
* Remove language-support/ts/package-lock.json
* Remove --downlevelIteration option, materialize iterators, fix one test
* I will refrain from commenting on the meaning of `this` in JavaScript
* WebSocket does not have a removeAllListeners method
* Remove unnecessary docstring from `handleQueriesChange`
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670441680
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670427941
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670448474
* Address https://github.com/digital-asset/daml/pull/10221#discussion_r670473307
* Fix some failing tests and linting fixes
* fix reconnect on server close test
* fix failing tests in test.ts and create-daml-app tests
* Update language-support/ts/daml-ledger/index.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.test.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update language-support/ts/daml-ledger/index.test.ts
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* changes based on code review comments
Co-authored-by: Akshay <akshay.shirahatti@digitalasset.com>
Co-authored-by: akshayshirahatti-da <86774832+akshayshirahatti-da@users.noreply.github.com>
We’ve seen this timeout a few times on CI. The version in the compat
tests already has a 60s timeout and that seems to work better so
here’s to hoping this helps.
I’ve also added some logs to see where it stops if it times out
again (jest hides console.log by default which is why this uses
console.debug by default).
changelog_begin
changelog_end
As I was adding support to a sample app for the third time, I decided I
might as well clean it up a bit and add support for everyone.
This is completely optional, activated by (build-time) environment
variables, and should be trivial to remove for users who don't care
about it. In an ideal world we'd have options to `daml new` and this
would be one, but I think adding it out-of-the-box is a better
alternative than letting people figure this out on their own.
CHANGELOG_BEGIN
- The `create-daml-app` template now includes support for a third
authentication scheme (in addition to the existing "dev mode" and Daml
Hub support): Auth0.
CHANGELOG_END
* Replace many occurrences of DAML with Daml
* Update docs logo
* A few more CLI occurrences
CHANGELOG_BEGIN
- Change DAML capitalization and docs logo
CHANGELOG_END
* Fix some over-eager replacements
* A few mor occurrences in md files
* Address comments in *.proto files
* Change case in comments and strings in .ts files
* Revert changes to frozen proto files
* Also revert LF 1.11
* Update get-daml.sh
* Update windows installer
* Include .py files
* Include comments in .daml files
* More instances in the assistant CLI
* some more help texts
This executes the code generations specified in the daml.yaml
configuration file on every invocation of `daml start`
and hence frees the user of doing it manually.
CHANGELOG_BEGIN
- [DAML Assistant] The `daml start` now runs all the code generators
specified in the `daml.yaml` project configuration file under the
`codegen` stanza. This frees the user of doing so manually on every
change to the DAML model.
CHANGELOG_END
The issue is described in a comment (since I want to preserve it) but
here’s the brief summary:
Calling `follow` twice can result in contention if we do not wait in
between. That is shown in the log of the JSON API. For some reason
that ends up propagating to a misleading Target closed error from
puppeteer.
This PR addresses the problem by waiting for the list of followers to
be updated which definitely implies that the ledger has seen the
command.
changelog_begin
changelog_end
`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
* 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
