* Bump rules_haskell
Still checking if that helps with GHC 8.8 but we should upgrade this
either way.
changelog_begin
changelog_end
* disable grpc patch
* shut up buildifier
* delete unused ghci grpc patch
* Fix Cffi library not found issues
* Update deps.bzl
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
Co-authored-by: Andreas Herrmann <andreash87@gmx.ch>
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Change method of opening DAML files with VSCode
* More explanation of AddFriend choice
changelog_begin
changelog_end
* Contract not contract instance
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Remove 'instance' and explain nonconsuming better
* Fix file navigation and more wording
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* @daml/react: Remove loading indication from useExercise hook
The indicator was a stupid idea of mine in the first place. Sharing the
loading indicator between potentially concurrent calls to the function
returned by the hooks does not make any sense.
`useExerciseByKey` has the same problem and it's fixed here as well.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix doc comments
CHANGELOG_BEGIN
CHANGELOG_END
* Add init-script daml.yaml field
CHANGELOG_BEGIN
[DAML Script -- Experimental] You can now define an ``init-script`` in
the ``daml.yaml`` file. If present, that DAML script will be executed
to initialize the sandbox on ``daml start``. This can be used instead
of the ``scenario`` field.
CHANGELOG_END
* Add integration test for init-script
* Generate JWT token in tests
Addressing review comment
https://github.com/digital-asset/daml/pull/4685#discussion_r383835050
* Remove unnecessary daml calls
Co-authored-by: Andreas Herrmann <andreash87@gmx.ch>
Right now, the `I` type parameter of `CreateEvent` is omitted in all
the hooks and hence set to its default value `string`. This is very
unfortunate in upgrading settings where you end up with multiple
versions of the same template that are basically only distinguishable
by their template id.
CHANGELOG_BEGIN
CHANGELOG_END
* Add overridable indexer, api and auth configuration to `LedgerFactory`
CHANGELOG_BEGIN
CHANGELOG_END
* Add overridable indexer and api metrics creation to `LedgerFactory`
CHANGELOG_BEGIN
CHANGELOG_END
* Add overridable api's `TimeServiceBackend` to `LedgerFactory`
* 🎨 Fix formatting
* Port SDK ledgers based on `Runner` (and the sandbox) to `TimeServiceBackend`
* Revert to `TimeProvider` for committer usage and to `None` default for API server.
Also removed now unused `TimeServiceProvider.wallClock()`.
* Move TimeServiceBackend back to the API server.
* 🎨 Remove unneeded argument passed for parameter w/default
* Restore sandbox ledger time support
* Simplify passing a `TimeProvider` to the sandbox ledger
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
In the current setup, we expose HEAD as the trigger commit, but that is
the merge commit with master. Since making a release takes a long time,
this merge commit is likely to not exist anymore by the time we want to
try a rerun (assuming a flaky build).
Release PRs are by definition (in the new system) independent of what's
going on on master, so we should instead take the branch commit here
when running on a PR.
CHANGELOG_BEGIN
CHANGELOG_END
Context
=======
After multiple discussions about our current release schedule and
process, we've come to the conclusion that we need to be able to make a
distinction between technical snapshots and marketing releases. In other
words, we need to be able to create a bundle for early adopters to test
without making it an officially-supported version, and without
necessarily implying everyone should go through the trouble of
upgrading. The underlying goal is to have less frequent but more stable
"official" releases.
This PR is a proposal for a new release process designed under the
following constraints:
- Reuse as much as possible of the existing infrastructure, to minimize
effort but also chances of disruptions.
- Have the ability to create "snapshot"/"nightly"/... releases that are
not meant for general public consumption, but can still be used by savvy
users without jumping through too many extra hoops (ideally just
swapping in a slightly-weirder version string).
- Have the ability to promote an existing snapshot release to "official"
release status, with as few changes as possible in-between, so we can be
confident that the official release is what we tested as a prerelease.
- Have as much of the release pipeline shared between the two types of
releases, to avoid discovering non-transient problems while trying to
promote a snapshot to an official release.
- Triggerring a release should still be done through a PR, so we can
keep the same approval process for SOC2 auditability.
The gist of this proposal is to replace the current `VERSION` file with
a `LATEST` file, which would have the following format:
```
ef5d32b7438e481de0235c5538aedab419682388 0.13.53-alpha.20200214.3025.ef5d32b7
```
This file would be maintained with a script to reduce manual labor in
producing the version string. Other than that, the process will be
largely the same, with releases triggered by changes to this `LATEST`
and the release notes files.
Version numbers
===============
Because one of the goals is to reduce the velocity of our published
version numbers, we need a different version scheme for our snapshot
releases. Fortunately, most version schemes have some support for that;
unfortunately, the SDK sits at the intersection of three different
version schemes that have made incompatible choices. Without going into
too much detail:
- Semantic versioning (which we chose as the version format for the SDK
version number) allows for "prerelease" version numbers as well as
"metadata"; an example of a complete version string would be
`1.2.3-nightly.201+server12.43`. The "main" part of the version string
always has to have 3 numbers separated by dots; the "prerelease"
(after the `-` but before the `+`) and the "metadata" (after the `+`)
parts are optional and, if present, must consist of one or more segments
separated by dots, where a segment can be either a number or an
alphanumeric string. In terms of ordering, metadata is irrelevant and
any version with a prerelease string is before the corresponding "main"
version string alone. Amongst prereleases, segments are compared in
order with purely numeric ones compared as numbers and mixed ones
compared lexicographically. So 1.2.3 is more recent than 1.2.3-1,
which is itself less recent than 1.2.3-2.
- Maven version strings are any number of segments separated by a `.`, a
`-`, or a transition between a number and a letter. Version strings
are compared element-wise, with numeric segments being compared as
numbers. Alphabetic segments are treated specially if they happen to be
one of a handful of magic words (such as "alpha", "beta" or "snapshot"
for example) which count as "qualifiers"; a version string with a
qualifier is "before" its prefix (`1.2.3` is before `1.2.3-alpha.3`,
which is the same as `1.2.3-alpha3` or `1.2.3-alpha-3`), and there is a
special ordering amongst qualifiers. Other alphabetic segments are
compared alphabetically and count as being "after" their prefix
(`1.2.3-really-final-this-time` counts as being released after `1.2.3`).
- GHC package numbers are comprised of any number of numeric segments
separated by `.`, plus an optional (though deprecated) alphanumeric
"version tag" separated by a `-`. I could not find any official
documentation on ordering for the version tag; numeric segments are
compared as numbers.
- npm uses semantic versioning so that is covered already.
After much more investigation than I'd care to admit, I have come up
with the following compromise as the least-bad solution. First,
obviously, the version string for stable/marketing versions is going to
be "standard" semver, i.e. major.minor.patch, all numbers, which works,
and sorts as expected, for all three schemes. For snapshot releases, we
shall use the following (semver) format:
```
0.13.53-alpha.20200214.3025.ef5d32b7
```
where the components are, respectively:
- `0.13.53`: the expected version string of the next "stable" release.
- `alpha`: a marker that hopefully scares people enough.
- `20200214`: the date of the release commit, which _MUST_ be on
master.
- `3025`: the number of commits in master up to the release commit
(included). Because we have a linear, append-only master branch, this
uniquely identifies the commit.
- `ef5d32b7ù : the first 8 characters of the release commit sha. This is
not strictly speaking necessary, but makes it a lot more convenient to
identify the commit.
The main downsides of this format are:
1. It is not a valid format for GHC packages. We do not publish GHC
packages from the SDK (so far we have instead opted to release our
Haskell code as separate packages entirely), so this should not be an
issue. However, our SDK version currently leaks to `ghc-pkg` as the
version string for the stdlib (and prim) packages. This PR addresses
that by tweaking the compiler to remove the offending bits, so `ghc-pkg`
would see the above version number as `0.13.53.20200214.3025`, which
should be enough to uniquely identify it. Note that, as far as I could
find out, this number would never be exposed to users.
2. It is rather long, which I think is good from a human perspective as
it makes it more scary. However, I have been told that this may be
long enough to cause issues on Windows by pushing us past the max path
size limitation of that "OS". I suggest we try it and see what
happens.
The upsides are:
- It clearly indicates it is an unstable release (`alpha`).
- It clearly indicates how old it is, by including the date.
- To humans, it is immediately obvious which version is "later" even if
they have the same date, allowing us to release same-day patches if
needed. (Note: that is, commits that were made on the same day; the
release date itself is irrelevant here.)
- It contains the git sha so the commit built for that release is
immediately obvious.
- It sorts correctly under all schemes (modulo the modification for
GHC).
Alternatives I considered:
- Pander to GHC: 0.13.53-alpha-20200214-3025-ef5d32b7. This format would
be accepted by all schemes, but will not sort as expected under semantic
versioning (though Maven will be fine). I have no idea how it will sort
under GHC.
- Not having any non-numeric component, e.g. `0.13.53.20200214.3025`.
This is not valid semantic versioning and is therefore rejected by
npm.
- Not having detailed info: just go with `0.13.53-snapshot`. This is
what is generally done in the Java world, but we then lose track of what
version is actually in use and I'm concerned about bug reports. This
would also not let us publish to the main Maven repo (at least not more
than once), as artifacts there are supposed to be immutable.
- No having a qualifier: `0.13.53-3025` would be acceptable to all three
version formats. However, it would not clearly indicate to humans that
it is not meant as a stable version, and would sort differently under
semantic versioning (which counts it as a prerelease, i.e. before
`0.13.53`) than under maven (which counts it as a patch, so after
`0.13.53`).
- Just counting releases: `0.13.53-alpha.1`, where we just count the
number of prereleases in-between `0.13.52` and the next. This is
currently the fallback plan if Windows path length causes issues. It
would be less convenient to map releases to commits, but it could still
be done via querying the history of the `LATEST` file.
Release notes
=============
> Note: We have decided not to have release notes for snapshot releases.
Release notes are a bit tricky. Because we want the ability to make
snapshot releases, then later on promote them to stable releases, it
follows that we want to build commits from the past. However, if we
decide post-hoc that a commit is actually a good candidate for a
release, there is no way that commit can have the appropriate release
notes: it cannot know what version number it's getting, and, moreover,
we now track changes in commit messages. And I do not think anyone wants
to go back to the release notes file being a merge bottleneck.
But release notes need to be published to the releases blog upon
releasing a stable version, and the docs website needs to be updated and
include them.
The only sensible solution here is to pick up the release notes as of
the commit that triggers the release. As the docs cron runs
asynchronously, this means walking down the git history to find the
relevant commit.
> Note: We could probably do away with the asynchronicity at this point.
> It was originally included to cover for the possibility of a release
> failing. If we are releasing commits from the past after they have been
> tested, this should not be an issue anymore. If the docs generation were
> part of the synchronous release step, it would have direct access to the
> correct release notes without having to walk down the git history.
>
> However, I think it is more prudent to keep this change as a future step,
> after we're confident the new release scheme does indeed produce much more
> reliable "stable" releases.
New release process
===================
Just like releases are currently controlled mostly by detecting
changes to the `VERSION` file, the new process will be controlled by
detecting changes to the `LATEST` file. The format of that file will
include both the version string and the corresponding SHA.
Upon detecting a change to the `LATEST` file, CI will run the entire
release process, just like it does now with the VERSION file. The main
differences are:
1. Before running the release step, CI will checkout the commit
specified in the LATEST file. This requires separating the release
step from the build step, which in my opinion is cleaner anyway.
2. The `//:VERSION` Bazel target is replaced by a repository rule
that gets the version to build from an environment variable, with a
default of `0.0.0` to remain consistent with the current `daml-head`
behaviour.
Some of the manual steps will need to be skipped for a snapshot release.
See amended `release/RELEASE.md` in this commit for details.
The main caveat of this approach is that the official release will be a
different binary from the corresponding snapshot. It will have been
built from the same source, but with a different version string. This is
somewhat mitigated by Bazel caching, meaning any build step that does
not depend on the version string should use the cache and produce
identical results. I do not think this can be avoided when our artifact
includes its own version number.
I must note, though, that while going through the changes required after
removing the `VERSION` file, I have been quite surprised at the sheer number of
things that actually depend on the SDK version number. I believe we should
look into reducing that over time.
CHANGELOG_BEGIN
CHANGELOG_END
* sandbox: Make ReadOnlySqlLedger provide a ResourceOwner, not a Resource.
* sandbox: Fix two race conditions on shutdown in ReadOnlySqlLedger.
It appears that there are two race conditions regarding the ledger end
update mechanism.
1. The dispatcher can keep firing for a little while even after we shut
down the source, which can cause a spurious connection failure as it
makes a query on a closed database connection.
2. We don't wait for the sink to complete, which means, again, we could
shut down the connection before the last `lookupLedgerEnd` query is
issued.
This also makes sure we actually construct a new source if the updates
fail. Previously we were re-using the same source, which looked like a
crash-loop waiting to happen.
Tested by constructing `ReadOnlySqlLedger` and closing it in a loop, and
watching for errors.
CHANGELOG_BEGIN
- [Ledger API Server] Fix a race condition on shutdown in which polling
for the ledger end could continue even after the database connection
was closed.
CHANGELOG_END
* GSG: Explain Sandbox and JSON API better and improve wording in intro
Also adapt to lack of sign up.
changelog_begin
changelog_end
* Address comments
* daml2ts: Don't fest @daml/types from npmjs.com in tests
We now copy the compiled version of `@daml/types` into the yarn
workspace instead of getting it from npmjs.com.
I verified that it works if I change the `VERSION` file to contain
0.13.55. Thus, we're definitely not going to npmjs.com.
CHANGELOG_BEGIN
CHANGELOG_END
* Disable tests on windows
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Avoid opening a server to the world when finding a free port.
This is very annoying on macOS because we get a focus-stealing popup for
a split second, asking for permission to allow the server through the
firewall. The popup pretty much always disappears before it can even be
read, when the server is closed.
This is almost certainly not an attack vector, because:
- we only do this in tests,
- the server is open for only a few milliseconds,
- nothing is served,
- and finding the port is tricky, because it's effectively random.
Nevertheless, it's very annoying.
CHANGELOG_BEGIN
CHANGELOG_END
* Extract a Bazel package for finding free ports.
We seem to do it in 4 different places, which I think is enough to
remove the duplication.
* Split Ledger API Test Tool output
Makes failure pop up even without text coloring (e.g. on Azure Pipelines)
CHANGELOG_BEGIN
[DAML Ledger Integration Kit] Ledger API Test Tool now prints errors as a separate section
CHANGELOG_END
* Successes on the right, failures on the left :)
* Add missing newline
* Add documentation for DAML repl and advertise it
This PR adds some simple docs for ``daml repl`` and adds it to the
release notes.
changelog_begin
- [DAML Repl - Experimental] A new ``daml repl`` command that allows
you to use the ``DAML Script`` API interactively. Take a look at the
`documentation <https://docs.daml.com/daml-repl/>`_ for more
information.
changelog_end
* Update docs/source/daml-repl/index.rst
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* s/Repl/REPL/
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Rework description of using the app with recent changes
changelog_begin
changelog_end
* Formatting
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Wording
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Address more comments
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Use package metadata instead of file names to infer unit ids
This PR adds a function that abstracts over whether we get metadata
from a filename (< 1.dev) or directly from the LF metadata.
There is more work to be done here, in particular, I want to clean up
the hacks around daml-prim/daml-stdlib but I’ll leave that for a
separate PR.
changelog_begin
changelog_end
* Update compiler/daml-lf-ast/src/DA/Daml/LF/Ast/Util.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Refactor getUnitId
Co-authored-by: associahedron <231829+associahedron@users.noreply.github.com>
* Graceful error handling in `daml repl`
This PR changes `daml repl` to handle errors (parse errors, type
errors, unsupported statement errors, script errors) gracefully
and just emit an error message instead of tearing down the whole
process.
This gets the repl into a state where I think it’s sufficiently
user-friendly to be released (obviously there are tons of potential
improvements). The only thing missing before I’m comfortable
mentioning this in release notes and uninternalizing it are docs.
If you think there is something crucial that needs to be addressed
before, let me know.
changelog_begin
changelog_end
* why is windows
* sandbox: Fix a bug in the ResetServiceIT `timedReset` function.
It was computing the start and end times almost simultaneously.
CHANGELOG_BEGIN
CHANGELOG_END
* sandbox: Better error messages in ResetServiceIT if resets are slow.
Let the matchers do their magic.
Add a test for `useQuery` that ensure that we don't call the JSON API
if the component calling the hook changes without changing the query.
CHANGELOG_BEGIN
CHANGELOG_END
As mentioned in the title, this is still very experimental and needs
more work before we want to advertise it. However, the code is in a
somewhat reasonable shape, there are tests and I think even in the
current state it is already useful. Also this PR is already getting
very large so I don’t want to hold off much longer before merging this.
It is included in the SDK but hidden from `damlc --help` and `daml
--help` until the most pressing issues are addressed (primarily around
making sure that it doesn’t just shut down if you have a type error
and better error messages in general).
changelog_begin
changelog_end
CHANGELOG_BEGIN
- [Extractor (experimental)]: Contracts visible to a party without being a stakeholder are not stored anymore.
- [Extractor (experimental)]: Along with the previous change, the column ``contract.witness_parties`` has been renamed to ``contract.stakeholders``.
CHANGELOG_END
Contributes to #3498.
* Step (1) Add error detection for different names/same package
changelog_begin
changelog_end
* Step (2) : Generate TS for a package once and only once.
This PR adds the necessary infrastructure to produce package metadata
in `damlc`.
For `damlc build` this works exactly as expected. There are a few edge
cases where we don’t have names and/or versions (namely scenarios,
damlc compile and damlc package). We don’t really care about the
metadata for those anyway, so I’ve just set it some default value.
changelog_begin
changelog_end
This moves IndexerIT into its own package, and swaps the dependency from
reference-v2 to ledger-on-memory.
This test should ideally live in the sandbox code, but because it
depends on ledger-on-memory, it's easier to keep it separate.
Also rewrites a lot of the code because the API is different. The tests
should now be clearer too.
I've also marked the test as flaky, because, well, it is.
CHANGELOG_BEGIN
CHANGELOG_END
Unfortunately, we need to work around some bazel issues which lead to
confliciting versions of react in our tests. This workaround cannot be
used the tests are invoked via `yarn test`. Thus, we only use it when
we the tests from bazel. We use the existence of the environment
variable `TEST_WORKSPACE` as a proxy for whether we run from bazel.
CHANGELOG_BEGIN
CHANGELOG_END
