daml/templates/copy-trigger/daml.yaml.template

sdk-version: __VERSION__
name: __PROJECT_NAME__
source: src
version: 0.0.1
# trigger-dependencies-begin
dependencies:
  - daml-prim
  - daml-stdlib
  - daml-trigger
# trigger-dependencies-end
sandbox-options:
  - --wall-clock-time
Add a first draft of documentation for DAML triggers (#3181) * Add a first draft of documentation for DAML triggers The API will still change in a bunch of ways but I’d rather get some docs in place now and update them as we change things than not have any docs at all. * Fix path to daml.yaml * s/bot/trigger/ * fix source code markers * Fix tests * Update docs/source/triggers/index.rst Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com> 2019-10-15 17:50:43 +03:00			`sdk-version: __VERSION__`
rewrite trigger docs to follow gsg (#10509) * rewrite trigger docs to follow gsg Per #10419 point 4, I've rewritten the Triggers section to build upon the Getting Started Guide instead of inventing its own example. Compared to #10395, this has a lot more explanations as this page must now serve the dual purpose of being a possible "next step" from the GSG and being the main reference page for triggers. It's also lost the "next steps" section, which I think is a bit of a shame, but it doesn't really make sense here. There's also no easy way for people not interested in the GSG to follow along; should we expose the "completed GSG" as a tempate? CHANGELOG_BEGIN CHANGELOG_END * keep copy-trigger as a template * fix copy-trigger project name * make up gsg-trigger template * remove awkward sentence, fix existing typo * update code to use when{,Some} * add to * swap emitCommands and getCommandsInFlight * typo * insist on state-correction perspective * fix copy-trigger tests * add back copy-trigger to whitelist * add gsg-trigger to whitelist 2021-08-17 16:28:07 +03:00			`name: __PROJECT_NAME__`
Add a first draft of documentation for DAML triggers (#3181) * Add a first draft of documentation for DAML triggers The API will still change in a bunch of ways but I’d rather get some docs in place now and update them as we change things than not have any docs at all. * Fix path to daml.yaml * s/bot/trigger/ * fix source code markers * Fix tests * Update docs/source/triggers/index.rst Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com> 2019-10-15 17:50:43 +03:00			`source: src`
			`version: 0.0.1`
			`# trigger-dependencies-begin`
			`dependencies:`
			`- daml-prim`
			`- daml-stdlib`
			`- daml-trigger`
			`# trigger-dependencies-end`
sandbox: Fail to start if a time mode is not explicitly specified. (#5033) * sandbox: Fail to start if a time mode is not explicitly specified. CHANGELOG_BEGIN - [Sandbox] Sandbox is switching from Static Time mode to Wall Clock Time mode as the default. To ensure that our users know about this, for one version, there will be no default time mode. Instead, users will have to explicitly select their preferred time mode by means of the `--static-time` or `--wall-clock-time` switches. In the next release, Wall Clock Time will become the default, and users who are happy with the defaults will no longer need to specify the time mode. CHANGELOG_END * daml-script\|triggers: Specify time mode when testing against Sandbox. * daml-assistant: Default the Sandbox to wall clock time. CHANGELOG_BEGIN - [DAML Assistant] Initializing a new DAML project adds a switch to ``daml.yaml`` to ensure Sandbox can continue to start with ``daml start``:: sandbox-options: - --wall-clock-time CHANGELOG_END * docs: Update the DAML Script and Triggers docs to use Wall Clock time. It's now what Sandbox will use by default when using `daml init`. * docs: Change the Quickstart to run Sandbox in wall clock time. This explains why the contract IDs may vary. It also updates the manual release testing script to match. 2020-03-18 11:25:03 +03:00			`sandbox-options:`
			`- --wall-clock-time`