* Factor out tar/gzip reproducibility flags
* use mktgz in package-app
* Bazel managed tar/gzip
* Remove quiet = True
As stated in the comment this is no longer required with Bazel >= 3.0.
* Build package-app as a sh_binary
This way Bazel will manage the runtime dependencies tar, gzip, mktgz,
and patchelf.
package-app.sh changes directory so it needs to make sure that all paths
are absolute and that the runfiles tree/manifest location is forwarded
to programs called by package-app.sh.
* Avoid file path too long errors
* Fix readlink -f on MacOS
* Document abspath
changelog_begin
changelog_end
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Respect project name in create-daml-app
Now `daml new foobar create-daml-app` creates a project called
`foobar` replacing the name everywhere. The tests now run twice once
with the original project name since that’s what we use in the GSG and
once with a modified one. I guess you could argue that only running
the second should be enough so I’m open to removing the first one.
fixes#6681
changelog_begin
- [DAML Assistant] `daml new foobar create-daml-app` now properly
respects the project name and creates a project called `foobar`
instead of hardcoding the name fo `create-daml-app`.
changelog_end
* .
changelog_begin
changelog_end
* Remove debugging output
changelog_begin
changelog_end
The intention was to pull in the source for the GSG but it turns out
that the templates tarball doesn’t just bundle up files, it also
includes generated scala code for the scala quickstart which depends
on damlc. This PR splits the GSG sources including the patching into a
separate rule which does not depend on damlc and only copies that in
live-preview.
changelog_begin
changelog_end
Buildifier now comes with a handy attachment to catch single `\`
characters inside strings and replace them with `\\` if the escape
sequence is invalid. Skylark/Python will do this at runtime anyway; this
just makes it clearer what the actual behavior is.
I needed to change `\` characters at the end of lines to `\\` manually
in order to stop Buildifier from simply concatenating the lines
together. Everything else was automatic.
CHANGELOG_BEGIN
CHANGELOG_END
* Remove the copyright header from the skelton
It doesn't make sense to annoy our users with our copyright for on a
template. And the over abundance of empty lines has annoyed me so many
times.
* Add NO_AUTO_COPYRIGHT file
CHANGELOG_BEGIN
CHANGELOG_END
This adds an empty template for the daml assistant. This is very helpful
for writing katacoda's, because otherwise you have to delete contained
source files in the `skeleton` project everytime as a first step. The
README in the `daml` directory is mainly there to get the daml directory
in the template.
CHANGELOG_BEGIN
CHANGELOG_END
The `da` tool has not existed for a while now and it's unlikely any new
user will need to know about the upgrade path. I think starting from
1.2.0 it makes sense not to have that documenation around anymore.
Note that we do have references to the upgrade page in the release
notes, so leaving them as is would break building the documentation. My
preference would have been to turn those references into "external"
links to the relevant version, but unfortunately, these are versions
(`0.12.15` and `0.12.18`) that, for various reasons, we cannot build
anymore and do not have in pre-built form. I have therefore decided to
change the links in the release notes to link to the latest existing
version of that page (which is pretty much what it already did), i.e.
specifically link to `1.1.1`.
CHANGELOG_BEGIN
CHANGELOG_END
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
* 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)
We avoided infix syntax here for `elem` but still used it for
`notElem` which doesn’t make much sense. Also we lost the config to
disable the lint when integrating the example in this repo. This
resulted in our own code producing a lint which is obviously a bad
idea.
side note: I think this lint does make sense once you
are familiar with the syntax and I feel slightly bad about disabling
more and more lints so for now I’m keeping it in the config.
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
* Deprecate ledger initialization with scenarios
CHANGELOG_BEGIN
[Sandbox] Initializing the sandbox with scenarios is now deprecated in
favor of using DAML Script. The scenario parameter will be removed in
the near future. A warning is logged on startup.
The DAML SDK templates and quickstart guide are using DAML Script.
See the DAML Script migration guide for more information:
https://docs.daml.com/daml-script/index.html#using-daml-script-for-ledger-initialization
CHANGELOG_END
* Remove damlc migrate
``damlc migrate`` hasn’t worked for quite a while and we emitted a
warning for months so given that we don’t have plans to make it work
again in the near future, I think it does more harm than good to keep
it around.
changelog_begin
- [DAML Compiler] After being deprecated for a while the ``damlc
migrate`` command has now been removed. See
https://docs.daml.com/upgrade/ for up to date documentation
on model upgrades.
changelog_end
fixes#3704 (by removing the tests 😇)
* yeah the windows cache is once again broken \o/
* Revert "yeah the windows cache is once again broken \o/"
This reverts commit 38d7877aa4.
* 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>
* language: feature: initial implementation of a 'migrate' command
We add a 'migrate' command to daml assistant that generates a project
that allows to migrate contract instances from package1 to package2.
This first version reads both package1 and package2 from source. As a
next step we read only the dalfs from package1, because it might have
been created with a different compiler.
* Add quickstart-scala template to DAML Assistant , #614
Removing the rule to create a quickstart-scala.tar.gz, it is not needed
* Return non-zero error code if failures detected, #614
* Reading project name from `daml.yaml`, #614
Removing Versions.scala.template
