* Make Bearer prefix optional in Haskell ledger bindings
This matches the change to the JVM bindings in 1.0.0
changelog_begin
- [DAML Assistant] The ``daml ledger`` commands no longer require the
``Bearer `` prefix in the access token file. This matches the behavior
of DAML Script and other SDK tools.
changelog_end
* Fix tasty crash
changelog_begin
changelog_end
* Update compatibility/bazel_tools/daml_ledger/Main.hs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* new --leak-passwords-firesheep-style option; functions to check forwarded protocol
* enforce https reverse-proxy in all JWT-accepting endpoints
* make HttpService.start take config record
* test that X-Forwarded-Proto or Forwarded is enforced
* use new start signature in daml-script tests
* use insecure http mode for ts codegen tests
* note on regex
* use insecure option in daml assistant integration tests
* log allowNonHttps setting
* add non-https option to more places in daml-assistant tests
* add non-https option to getting started guide
* rename --leak-passwords-firesheep-style to --allow-insecure-tokens
- per suggestion by @garyverhaegen-da, @hurryabit
CHANGELOG_BEGIN
- [JSON API] By default, checks that connections are made through a reverse-proxy
providing HTTPS, ensuring that JWT tokens don't leak. To disable this check,
such as for development, pass ``--allow-insecure-tokens``.
See `issue #5572 <https://github.com/digital-asset/daml/issues/5572>`_.
CHANGELOG_END
* daml start includes --allow-insecure-tokens by default
- as indicated by @cocreature
* Copy daml ledger test to compatibility
Specifically:
- `daml-assistant/daml-helper/test/DA/Daml/Helper/Test/Deployment.hs`
- `libs-haskell/test-utils/DA/Test/Sandbox.hs`
* Adapt daml ledger test for compatibility
Avoid dependencies on the daml repository and make the SDK and platform
components configurable.
* Add test certificates to compatibility
Taken from `@daml//ledger/test-common/test-certificates`.
* Define daml_ledger_test
CHANGELOG_BEGIN
CHANGELOG_END
* Add note on keeping daml ledger tests in sync
* ./fmt.sh
* Strictly require --sdk-version flag
Tasty doesn't allow options without a default value, so we default to
`error` to enforce a value being set.
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Previously that resulted in us telling sandbox,navigator,… to connect
to port 0 which obviously does not work. I’ve changed the types a bit
to avoid accidentally passing on the cli argument to them.
changelog_begin
changelog_end
* Make DAML Triggers and DAML Script default to wall-clock-time
Now that sandbox defaults to wall-clock-time there is no reason why we
should not default in DAML triggers and DAML Script.
changelog_begin
- [DAML Triggers] ``daml trigger`` now defaults to wall clock time if
neither ``--wall-clock-time`` or ``--static-time`` is passed.
- [DAML Script] ``daml script`` now defaults to wall clock time if
neither ``--wall-clock-time`` or ``--static-time`` is passed.
changelog_end
* Make --static-time and --wall-clock-time exclusive
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
This PR adds an --output-file option to DAML Script that writes the
result of a DAML Script to a file and complements the --input-file option.
changelog_begin
- [DAML Script] ``daml script`` now has a `--output-file`` option that
can be used to specify a file the result of the script should be
written to. Similar to ``--input-file`` the result will be output in
the DAML-LF JSON encoding.
changelog_end
* Diff with messaging feature and some noise manually removed
* Bazel target to use patch file in other build targets
* Patch file as data dep for integration tests
* Attempt to patch and test messaging feature in create-daml-app test
changelog_begin
changelog_end
* Use exports_files instead of filegroup
* Remove file existence checks that don't make sense
* Add patch to dev_env and reference it from integration tests
* Include patch on windows for later
* Set up yarn env again after codegen
* Restore file check
* Fix typo in comment on util function
* Add Tasty steps to make process explicit
* Use messaging patch for code snippets in GSG
* Use messaging code from template instead of copy
* Remove copied message code
* Refactor script to copy template code with messaging patch
* No need to retry second yarn install (only local deps should be updated)
* Used `daml codegen java` instead of calling the codegen from maven
This should hopefully fix the issues with mismatched versions of
slf4j.
changelog_begin
changelog_end
* Move config to daml.yaml
* Remove alternative invocation via maven from docs
* Haskell: Add assertFileExists to DA.Test.Util
This PR adds a helper function `assertFileExists` that captures the
`doesFileExist ... >>= assertBool ...` pattern that is very common in
our Haskell test suites. It also adds the inverse
`assertFileDoesNotExist` function. Both functions are now used where
appropriate.
CHANGELOG_BEGIN
CHANGELOG_END
* Add directory dependency to test-util lib
CHANGELOG_BEGIN
CHANGELOG_END
Some of the dependencies of the `create-daml-app` seem to fail to
install without any good reason every now and then. We try to
circumvent this flakiness by running the `yarn install` step for the
UI three times before giving up.
CHANGELOG_BEGIN
CHANGELOG_END
There are multiple tests that setup an environment for yarn to find
our TypeScript libraries. This PR unifies this setup by providing a
single function to set it up.
CHANGELOG_BEGIN
CHANGELOG_END
Packages com.digitalasset.daml and com.daml have been unified under com.daml
Ledger API and DAML-LF DEV protos have also been moved from `com/digitalasset`
to `com/daml` on the file system.
Protos for already released DAML LF versions (1.6, 1.7, 1.8) stay in the
package `com.digitalasset`.
CHANGELOG_BEGIN
[SDK] All Java and Scala packages starting with
``com.digitalasset.daml`` and ``com.digitalasset`` are now consolidated
under ``com.daml``. Simply changing imports should be enough to
migrate your code.
CHANGELOG_END
I've completely removed the possibility to call `daml codegen ts`. I'm
happy to add in back in a followup PR once I've seen that all our tests
pass without it existing.
CHANGELOG_BEGIN
CHANGELOG_END
* Add snapshot version support in daml-assistant.
changelog_begin
- [DAML SDK] ``daml version`` can now list the available snapshot
versions by passing the flag ``--snapshots=yes``.
- [DAML SDK] ``daml install latest`` can now include the latest snapshot version by passing the flag ``--snapshots=yes``.
changelog_end
* Keep backward-compatible --all behavior
* Fix comment
* Delete spurious punctuation
Previously we emitted 3 lines starting with a capslock `WARNING` which
seems to scare some people. Now we emit two lines without the
`WARNING` and point to the release notes since that seems better than
explaining to users how they upgrade without telling them what
changed.
It’s still two lines, I couldn’t come up with anything shorter that
seems reasonable. We might want to reduce the frequency at which this
is displayed as well but for now this should do.
changelog_begin
changelog_end
Change the output directory given to `daml codegen ts` from `daml-ts`
to `daml.js`. This is naming is in line with the fact that `daml2ts`
puts all generated packages into the `@daml.js` scope. A renaming of
`daml2ts` into `daml2js` is immiment.
This PR also changes a few small documentation issues the
search-and-replace has surfaced.
CHANGELOG_BEGIN
CHANGELOG_END
The test calls `daml new ... create-daml-app`, builds the DAR, runs
the TypeScript codegen, lints and builds the React app.
We should also run the tests for the React app but since that's most
likely tricky, I'll leave that for a followup PR so that we can land
at least some sanity checks now.
There's also a bit of cleanup to do around setting up a yarn workspace
to bring our TypeScript libraries into scope. Other test already solve
a similar problem in a way that is not general enough for this test.
I'll unify the setup in a followup PR as well.
CHANGELOG_BEGIN
CHANGELOG_END
- Move deployment tests (deployTest, fetchTest) out of integration-tests.
- Use DA.Test.Sandbox where appropriate.
- Split out code for useful test patterns: i.e. calling commands quietly, getFreePort.
changelog_begin
changelog_end
* Initial commit with create-daml-app master
* Include create-daml-app in build rule
* Make daml.yaml a template in version and project name
* Remove git attributes
* Remove license and azure config
* Remove scripts
* Don't overwrite config files in build rule
* Template version numbers in package.json, to be replaced by the assistant
* Rename to package.json.template
changelog_begin
changelog_end
* Add copyright headers
* Do template substitutions in all .template files
And don't special case daml new create-daml-app (so it treats it as a
regular template).
* Add create-daml-app to integration tests
* Remove WIP warning
* Move towards setup that works on head
* Make local copies of the TS libs in the templates tarball
* Hardcode project name for now
* Use isExtensionOf
* Remove service worker
* remove robots.txt (don't even know what it is)
* Revert "Make local copies of the TS libs in the templates tarball"
This reverts commit 1289581fb4a82af3ab534baf978a2c6ed895d538.
* Retemplatize TS lib versions. For head builds these will be installed using npm
* Remove daml/ledger from resolutions for daml-ts
* Comment about test secret
* Remove special create-daml-app assistant command and test that won't work anymore
* Remove redundant imports and export
* Remove old create-daml-app tests
* Remove yarn.lock
* Clean up integration test (just daml new and build atm)
* Add daml/ledger as a resolution for daml-ts
* Remove top level package.json
* Update daml.js version
* Use new import scheme for generated TS
* Update readme with new codegen and build steps
* Use start-navigator in daml.yaml
* Increase a couple of timeouts in tests (either sandbox or TS lib is a bit slower?)
* Update GSG intro with new build steps
* Remove daml2ts -p flag and --start-navigator flag from GSG instructions
* Don't use start-navigator flag in ui tests
* Temporary readme describing how to manually test the create-daml-app template
* Update code samples in app arch section of GSG
* Update code samples in testing doc
* Remove copied create-daml-app code
* Indent docs markers to be more subtle
* Update visible code in Messages (after) section
This needs to be kept up to date properly somehow.
* Update text to useLedger
* Restore code/ui-before copies until the Bazel magic is figured out
We need to make the template code a dependency in the Bazel rule as
otherwise we can't find the files in the docs build.
* Update create-daml-app/readme and make templates/readme more detailed
* Use jsx comments for docs markers so they don't show up in the app
This cause issues in combination with data-dependencies see #5330 and
we started warning if you don’t expose everything. This resulted in
quickstart-java producing a warning on every `daml build`.
changelog_begin
changelog_end
* Improve handling of exposed-modules with data-dependencies
Previously, we tried to rename all modules of a dependency via
--package. This fails if some of those modules are not exported. This
was trivial to hit as a user since the ``daml-trigger`` library made
use of this.
This PR adds a few things to improve the situation:
1. We only rename modules that are exposed. This fixes the issue if
you don’t actually reference a non-exposed module from your
data-dependency.
2. I’ve removed the exposed-modules from daml-trigger. I don’t think
they are essential here given that the module name has `Internal`
in the name and it’s too easy to have something that actually
references the non-exposed module since the types are reexported.
3. I’ve added documentation that mentions this issue.
4. I’ve added a warning if your exposed-modules are excluding some
modules. Maybe worth turning this into an error in the future.
changelog_begin
changelog_end
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
Co-authored-by: associahedron <231829+associahedron@users.noreply.github.com>
* Use com.daml as groupId for all artifacts
CHANGELOG_BEGIN
[SDK] Changed the groupId for Maven artifacts to ``com.daml``.
CHANGELOG_END
* Add 2 additional maven related checks to the release binary
1. Check that all maven upload artifacts use com.daml as the groupId
2. Check that all maven upload artifacts have a unique artifactId
* Address @cocreature's comments in https://github.com/digital-asset/daml/pull/5272#pullrequestreview-385026181
* Make new sandbox the default.
changelog_begin
- [DAML SDK] The new sandbox is now the default that runs with ``daml sandbox`` and ``daml start``. The command ``daml sandbox-next`` has been removed. The old sandbox can be invoked via ``daml sandbox-classic`` and ``daml start --sandbox-classic=yes``.
changelog_end
* Update descriptions.
* Change it to a switch
* Change switch help
* Recapitalize
* Move 'withEnv', call it from daml2ts tests
changelog_begin
changelog_end
* Fix withEnv call to ensure that TASTY_NUM_THREADs is set
withEnv replaces the whole environment so we need to set everything we
care about.
* withEnv replaces the whole environment so we need to set everything we
care about.
* Apparently applying the same fix has destabilized Windows
* Try even harder to get daml assistant tests passing on Windows again
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
The way we use `withEnv` it is really intended to set a few
environment variables in an already existing environment instead of
clearing everything before. This PR changes it to do only that.
changelog_begin
changelog_end
closes#5280
Those were originally used for `damlc migrate`. However, that command
no longer exists and the only call site of `runNew` sets those
arguments to an empty list.
changelog_begin
changelog_end
* New comamnd: daml ledger fetch-dar
`daml ledger fetch-dar [PID] [PATH]`
Download a `Package` and it's dependencies from a ledger, given a root `packageId`, and re-construct a valid `.dar` file. Addresses issue #5037.
The original package names are not reconstructed.
CHANGELOG_BEGIN
CHANGELOG_END
* address some comments
* fix spello
* attempt: recoverPackageName
* recover main package name & version
* Try to fix integration tests on Windows
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
There was a brief period of time where `daml build` did not work
outside of the assistant. When we fixed that we added it to the
integration tests since there was no other test suite that used damlc
as a binary (as opposed to using it as a library which runs through
different codepaths). However, in the meantime we have tons of tests
all over the place (e.g. the packaging tests) that call `damlc build`
outside of the assistant so these tests serve no purpose.
Also they are somewhat confusing since the point of the integration
tests is to test an installed SDK whereas these tests do not need an
installed SDK (that’s the whole point of those tests).
changelog_begin
changelog_end
This ensures that -l and -p work properly in the integration tests
since they no longer depend on the order.
There is lots of other crap to cleanup in those tests but I’m trying
to keep it to small steps.
changelog_begin
changelog_end
* Depend on LF version specific daml-libs
* daml-script.dar build multiple LF versions
CHANGELOG_BEGIN
[DAML Script] The `daml-script` library is now available in multiple LF
versions, namely 1.7, 1.8, and 1.dev.
CHANGELOG_END
* daml-trigger.dar build multiple LF versions
[DAML Triggers] The `daml-trigger` library is now available in multiple
LF versions, namely 1.7, 1.8, and 1.dev.
* Keep daml-script.dar available for tests
* Keep daml-trigger.dar available for tests
* daml-libs LF versions integration test
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Integrate create-daml-app into the assistant
fixes#4868
changelog_begin
- [DAML Assistant] Add a new ``daml create-daml-app`` command for creating a project based on
`create-daml-app <https://github.com/digital-asset/create-daml-app>`_.
changelog_end
* Try random things hoping to fix windows
* Try random things hoping to fix things on macos
* Allow controlling navigator startup in daml.yaml
While I’m not entirely convinced the default atm is right, making it
configurable seems like an easier solution than bikeshedding the default.
changelog_begin
- [DAML Assistant] You can now disable starting navigator as part of
``daml start`` in your ``daml.yaml`` file by adding ``start-navigator: false``.
changelog_end
* Update docs/source/tools/assistant.rst
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* Use --start-navigator=true in the docs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Bump openssl
The previous one has stopped working for some reason :sadpanda:
changelog_begin
changelog_end
* daml-assistant: Add `--wall-clock-time` to the Sandbox Next test.
Missed this due to doing two things at once.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* daml-assistant: Add `daml sandbox-next`.
CHANGELOG_BEGIN
- [DAML Assistant] You can now run a pre-release version of Sandbox with
``daml sandbox-next`` so you can test it out and verify everything is
working as expected. Running this will launch Sandbox rebuilt on a
more modern architecture. An upcoming release of DAML will switch over
to the new implementation by default.
CHANGELOG_END
* daml-assistant: Explain that sandbox-next is experimental.
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* daml-assistant: Copy-pasta an integration test for `daml sandbox-next`.
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
