@SamirTalwar-DA is taking care of 1.17.0-snapshot.20210824.7647.0.640fb683 (#10659), so they get pushed back to the end of the line.
Please do not merge this before #10659.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* Upgrade to a newer canton version (post 0.27.0 snapshot version)
with canton-community configuration that supports higher throughput.
changelog_begin
changelog_end
* Disable flaky reject DeeplyNestedValueIT:Reject tests that time out half the time
* participant-integration-api: Construct completions in one place.
* sandbox-classic: Inline `CompletionFromTransaction#apply`.
It's only used here; there's no reason to keep it in the
_participant-integration-api_.
* participant-integration-api: Store a status gRPC protobuf.
Instead of storing the status code and message, we store a serialized
`google.rpc.Status` protocol buffers message. This allows us to pass
through any additional information reported by the driver `ReadService`.
The migration is only done for the append-only database, and preserves
old data in the existing columns. New data will only be written to the
new column.
CHANGELOG_BEGIN
CHANGELOG_END
* participant-integration-api: Improve comments in migrations.
Co-authored-by: Fabio Tudone <fabio.tudone@digitalasset.com>
* participant-integration-api: Further improvements to migrations.
* participant-integration-api: Store the rejection status as 3 columns.
Serializing the details but keeping the code and message columns
populated.
* participant-integration-api: Publish the indexer protobuf to Maven.
Co-authored-by: Fabio Tudone <fabio.tudone@digitalasset.com>
@nickchapman-da is taking care of 1.17.0-snapshot.20210817.7604.0.0c187853 (#10605), so they get pushed back to the end of the line.
Please do not merge this before #10605.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@realvictorprm is taking care of 1.17.0-snapshot.20210811.7560.0.4f9de4ba (#10544), so they get pushed back to the end of the line.
Please do not merge this before #10544.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@remyhaemmerle-da is taking care of 1.16.0-snapshot.20210727.7476.0.b5e9d861 (#10428), so they get pushed back to the end of the line.
Please do not merge this before #10428.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@robin-da is taking care of 1.16.0-snapshot.20210720.7404.0.b7cf42d1 (#10345), so they get pushed back to the end of the line.
Please do not merge this before #10345.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* ledger-offset: Move `Offset` to a new package.
CHANGELOG_BEGIN
- [Integration Kit] The ``Offset`` type has been moved to a new Maven
package, ``ledger-offset``, from the ``participant-state`` package.
The Java package has been renamed to ``com.daml.ledger.offset``. If
you are using this type, you will need to update your dependencies and
imports.
CHANGELOG_END
* Avoid rewrapping offsets for no reason.
Co-authored-by: Miklos <57664299+miklos-da@users.noreply.github.com>
* participant-integration-api: Sort some imports.
* participant-integration-api: Fix dependencies for the Oracle tests.
I didn't add `ledger-offset`.
Co-authored-by: Miklos <57664299+miklos-da@users.noreply.github.com>
* ledger-configuration: Extract configuration from participant-state.
The configuration is often used without the state, and doesn't need to
be versioned in the same way.
CHANGELOG_BEGIN
- [Integration Kit] The ledger configuration classes, ``Configuration``,
``LedgerInitialConditions``, and ``TimeModel``, have been moved from
*participant-state* to a separate package named
*ledger-configuration*, in the Java package
``com.daml.ledger.configuration``. You will need to update your
dependencies and imports.
CHANGELOG_END
* participant-state: Remove the `LedgerId` aliases.
* ledger-configuration: Rename `TimeModel` to `LedgerTimeModel`.
This avoids confusion with the protobuf-generated `TimeModel` classes.
CHANGELOG_BEGIN
- [Integration Kit] ``TimeModel`` has been renamed to
``LedgerTimeModel``. If you are using the ledger configuration classes
directly, you may need to update your code.
CHANGELOG_END
* ledger-configuration: Remove colons in LedgerInitialConditions' docs.
* kvutils: Restore a missing compat import.
* participant-integration-api: Add ledger-configuration to Oracle tests.
* sandbox-common: Fix `--max-ledger-time-skew` docs.
Co-authored-by: Miklos <57664299+miklos-da@users.noreply.github.com>
Co-authored-by: Miklos <57664299+miklos-da@users.noreply.github.com>
@akshayshirahatti-da is taking care of 1.15.0-snapshot.20210713.7343.0.1f35db17 (#10267), so they get pushed back to the end of the line.
Please do not merge this before #10267.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@sofiafaro-da is taking care of 1.15.0-snapshot.20210630.7261.0.84e1f3a7 (#10146), so they get pushed back to the end of the line.
Please do not merge this before #10146.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* logging-entries: Split from contextualized-logging.
This allows us to introduce it to Daml-LF without bringing in the
Logback, Logstash, and gRPC dependencies.
CHANGELOG_BEGIN
CHANGELOG_END
* logging-entries: Fix dependencies for 2.12.
* logging-entries: Missed one more Scala 2.12 dependency.
* release: Publish logging-entries.
Currently it is impossible to test new features until they land in the
default LF version. This is clearly not great. This PR releases one
Ledger API test tool per LF version (with the LF version being in the
name) to make it easier for Canton and others to test new features.
Note that at least the way things are setup now we won’t go back in
time. We will only publish stable, preview & dev but not older
versions. If needed, we could expand that in the future.
changelog_begin
changelog_end
@S11001001 is taking care of 1.15.0-snapshot.20210622.7213.0.d867d904 (#10085), so they get pushed back to the end of the line.
Please do not merge this before #10085.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@stefanobaghino-da is taking care of 1.14.0-snapshot.20210615.7169.0.adeba206 (#10018), so they get pushed back to the end of the line.
Please do not merge this before #10018.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@garyverhaegen-da is taking care of 1.14.0-snapshot.20210608.7123.0.3cb8d5c2 (#9932), so they get pushed back to the end of the line.
Please do not merge this before #9932.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@cocreature is taking care of 1.14.0-snapshot.20210601.7081.0.7d716e6d (#9877), so they get pushed back to the end of the line.
Please do not merge this before #9877.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@aherrmann-da is taking care of 1.14.0-snapshot.20210525.7017.0.2710fad0 (#9794), so they get pushed back to the end of the line.
Please do not merge this before #9794.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@SamirTalwar-DA is taking care of 1.14.0-snapshot.20210518.6953.0.a6c7b86a (#9737), so they get pushed back to the end of the line.
Please do not merge this before #9737.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
Currently we have the following dependency chain:
1. The compiler depends on the scenario service for daml test
2. The scenario service depends on Daml Script
3. Daml Script depends on the Sandbox code only for daml test-script
The last one can easily be split. The scenario service does not care
about this code.
This means that now if we change ledger code, at least not all
compiler tests are going to rerun.
Verified that this actually breaks the dependency fully via
```
bazel query 'somepath(//compiler/damlc/tests:packaging, //ledger/participant-integration-api/...)'
```
changelog_begin
changelog_end
@victormueller-da is taking care of 1.13.0-snapshot.20210511.6892.0.ca9e89b3 (#9647), so they get pushed back to the end of the line.
Please do not merge this before #9647.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
This PR speeds up the Maven installation by doing 4 things:
1. Disable TS builds. This doesn’t make sense since we never install
them.
2. Add a --skip-sdk option that skips the SDK installation.
3. Add a --skip-jar-docs option that skips javadoc and more
importantly scaladoc.
4. Add a --scala-version=$VERSION option to only build against the
given version.
Unfortunately there are no tests and the CLI is a bit messy (you need
--scala-version=$VERSION and not --scala-version $VERSION).
Both are not great but this is a development only tool and it is bash
so my motivation for fixing it is rather low.
Given that this is growing in complexity a fair bit, I think we might
be better off as a long-term solution to move this towards at least
python or maybe even Haskell or Scala. But definitely nothing for this
PR.
changelog_begin
changelog_end
@nickchapman-da is taking care of 1.13.0-snapshot.20210428.6782.0.e1e878a5 (#9518), so they get pushed back to the end of the line.
Please do not merge this before #9518.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* rename "dump" to "export"
* Add Daml export command to assistant
* Make daml export script a subcommand of daml export
* daml-assistant IT for daml export script
* Expose export as daml ledger command (hidden for now)
Add Haskell side parser for ledger export flags
changelog_begin
* [Daml export] New feature: Use ``daml ledger export script`` to
generate a Daml script that will reconstruct a given ledger state.
This is an early access feature.
changelog_end
* Update integration test
* Remove daml export - it's daml ledger export now
* integration-test set ledger port
The integration tests don't configure the port in the project config,
but on the command-line, and they don't use the default value.
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Fixes#9196.
This adds a new command `daml package list` which fetches all
available packages from the ledger and prints package name/versions to
stdout.
CHANGELOG_BEGIN
[daml packages] A new `daml packages list` command has been added to
list packages deployed on a remote Daml ledger.
CHANGELOG_END
* Upgrade Scala 2.12 to v2.12.13.
This is being pulled in anyway because of Maven/Gradle/etc's fun
"favor the most recent" resolution mechanism. The version of Akka we
depend upon transitively depends on Scala 2.12.13, so any downstream
consumers will see that as the Scala version required.
Bringing the Daml repo in line means no more confusion.
CHANGELOG_BEGIN
- [Scala Bindings] If you are using Daml on Scala 2.12, it now depends
on Scala v2.12.13 (from v2.12.12).
CHANGELOG_END
* Scala 2.12.13 is the default version in our pinned version of nixpkgs.
* Upgrade Scala 2.13's Wartremover version.
* Rename `scala_version_rule` to `scala_version_configure`.
* Add a test case to ensure the Scala versions are the same everywhere.
* Add tests for the Scala JAR versions in maven_install_*.json
* gatling-utils: Change the sort order of the expected CSV in tests.
I don't know why this changed, but it seems to be stable.
* compatibility: `scala_version` -> `scala_version_configure`.
* Bazel: Disable the Scala version tests on Windows.
* compatibility: Upgrade Wartremover to Scala 2.12.13.
@robin-da is taking care of 1.12.0-snapshot.20210323.6567.0.90c5ce70 (#9221), so they get pushed back to the end of the line.
Please do not merge this before #9221.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
Content:
-adds ReadWriteServiceBridge
-adds BridgeLedgerFactory with extra configuration
-conformance test suits
Limitations:
-no conflict checking, just replaying all submissions
-no bootstrapping from indexer persistence
-no multiple/subsequent subscription support
-conformance tests, which rely on correctness features were excluded
-ClosedWorldIT: test should fail referencing unallocated party
-CommandDeduplicationIT:CDStopOnCompletionFailure: creates error conditions based on racing key updates (rest is green)
-ContractKeysIT:CKFetchOrLookup, CKNoFetchUndisclosed: these are failing due to lack of validation/conflict checking in the bridge
-SemanticConcurrentDoubleSpend:SemanticConcurrentDoubleSpend: this is failing due to lack of validation/conflict checking in the bridge
CHANGELOG_BEGIN
[Sandbox] Proof-of-concept implementation of Sandbox-on-X
CHANGELOG_END
* Expose libraries for integration testing purposes
The motivation of these changes is to eliminate manual work and reduce duplication between the SDK and oem-integration-kit repos by reusing the same test fixture for integration testing participant state implementations. Also, the DARs required for running these tests won't need to be manually updated.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix a concurrency issue in integration tests
* Fix Bazel error
* Fix conflict resolution
* Move inline daml-lf to separate dar files
* Add a comment
* Add a missing artifact
* Extract method
* Remove maven tags
* Add a macro for Scala libraries with dar resources
* Improve the macro
* Add missing artifact
* Simplify the tests
* Format signature
* Fix the maven tag
* Add missing copyright headers
* Format bazel files
* Make //ledger/test-common lf version dependent (to avoid jar hell)
* Move da_scala_dar_resources_library to a separate bzl file
* Add missing artifacts
Co-authored-by: Hubert Slojewski <hubert.slojewski@tesco.com>
@sofiafaro-da is taking care of 1.12.0-snapshot.20210316.6523.0.b382fc45 (#9160), so they get pushed back to the end of the line.
Please do not merge this before #9160.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
The order of the list elements was swapped. I don’t trust myself to
not get this wrong in the future so rather than relying on list order,
I added a proper datatype.
changelog_begin
changelog_end
@S11001001 is taking care of 1.11.0-snapshot.20210309.6463.0.f7abca91 (#9061), so they get pushed back to the end of the line.
Please do not merge this before #9061.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* Fix compat job
changelog_begin
changelog_end
* Cleanup head_sdk
changelog_begin
changelog_end
* turns out removing everything also removes files that shouldn’t be removed
changelog_begin
changelog_end
* gnah
changelog_begin
changelog_end
* maybe this was a bad idea
changelog_begin
changelog_end
* trynottocry
changelog_begin
changelog_end
* Release EE SDK tarballs and installer
As before, no way of testing this. I’ll do a snapshot afterwards.
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* Rename EE artifacts
changelog_begin
changelog_end
* Move Daml Profiler to EE version of sandbox/sandbox-classic
This splits Sandbox targets into EE/CE targets and exposes the option
in the EE version. The option still exists in the CE option for now
until we have released EE artifacts to not break users that might know
about it without an alternative.
There is also a small test that makes sure that this actually works
since classpaths are dumb and it didn’t work at first.
changelog_begin
changelog_end
* Fix publish target
changelog_begin
changelog_end
* Publish transitive dep
changelog_begin
changelog_end
* I hate bash
changelog_begin
changelog_end
* Build SDK EE tarball
This sets up the infrastructure to build an SDK EE tarball and allows
for swapping out all files included in the tarball depending on the
edition. As an example, this includes the JSON API with (partial)
Oracle support in the EE tarball.
This PR does not yet address publishing this artifact to Artifactory.
I’ll tackle that in a separate PR.
changelog_begin
changelog_end
* Build in temp dir because Windows is stupid
changelog_begin
changelog_end
* directories are bad
changelog_begin
changelog_end
* Navigator resources are actually needed
changelog_begin
changelog_end
@stefanobaghino-da is taking care of 1.11.0-snapshot.20210302.6414.0.72870630 (#8991), so they get pushed back to the end of the line.
Please do not merge this before #8991.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* Fix daml-sdk-head Maven install
There were two issues:
1. The generated pom.xml used to install everything in one step
referenced the source files in the bazel directory rather than the
released artifacts. This luckily worked so far but falls apart now
since the 2.13 build overwrites the 2.12 build. Same issues that also
blew up the actual release on Thursday.
2. Two artifacts are published as shaded jars. We treated those like
Scala artifacts while they should be treated more like fat
jars. They’re not quite like those since the file paths are different
so I gave them a new release type.
changelog_begin
changelog_end
* shut up hlint
changelog_begin
changelog_end
* Fix broken comment for jarjar
changelog_begin
changelog_end
1. Correct link for the releases page
2. Move Windows up because I thought I was done with Windows after the
create-daml-app test and I killed my machine.
CHANGELOG_BEGIN
CHANGELOG_END
Turns out, attempt 1 at fixing the release process didn’t go as
planned. We only released Scala 2.13 artifacts but called some of them
2.12. Now you can argue that’s a feature but unfortunately some people
disagree so this PR fixes the issue:
While we took care to read the poms while the env var is still set we
had a single copying step at the end where the files were already
overwritten. This PR changes that by copying after each call to `bazel
build` to make sure that things are not overwritten.
This does slightly change the semantics, if you have an error (e.g.,
invalid group id, missing dep, …) we will now copy parts to the
release dir whereas before we copied all or nothing. I don’t see any
issues arising from it so I don’t think copying to a temp dir or
something like that to avoid this is worth the complexity.
changelog_begin
changelog_end
@garyverhaegen-da is taking care of 1.11.0-snapshot.20210224.6385.0.dba114a2 (#8945), so they get pushed back to the end of the line.
Please do not merge this before #8924.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* Merge Maven uploads for different Scala versions
It turns out Maven will abort an existing staging operation if you
create a new one. This means our jobs race against each other. We
could try to fix that by either sequencing the jobs in a clever
way (annoying and can break things like rerunning if only parts
failed), or by creating more profiles (unclear if you can even have
two profiles for the same group id, even if you do, it’s annoying to
merge).
So in this PR I (grudgingly) merged both uploads into the Haskell
script. This isn’t all bad:
1. It moves some logic from bash embedded in yaml string literals into
Haskell code.
2. It duplicates some versions but it removes duplication in other
places so overall not too much worse.
3. It does however, make things slower. We don’t run this stuff in
parallel. That said, the release step is relatively small (< 5min) and
it only runs on Linux.
We could add CLI arguments to make the Scala versions configurable for
local development. Given that this is blocking releases, I wanted to
get something in that works first and then see what we need in that regard.
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
@SamirTalwar-DA is taking care of 1.10.0-snapshot.20210209.6276.0.6ba86850 (#8799), so they get pushed back to the end of the line.
Please do not merge this before #8799.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@hurryabit is taking care of 1.10.0-snapshot.20210202.6218.0.c0573678 (#8724), so they get pushed back to the end of the line.
Please do not merge this before #8724.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
The jdkLogHandler provided by Doobie exists purely as an example and the library
itself does not recommend using it in production.
Note that this slightly changes the runtime behavior, logging successful queries
at debug level rather then info. The message itself is preserved from the original
MIT-licensed example.
This uses Slf4j as most of our components, instead of java.util.logging.
changelog_begin
[HTTP JSON API] The server now logs successful queries at debug level
instead of info
[Trigger Service] The server now logs successful queries at debug level
instead of info
changelog_end
CHANGELOG_BEGIN
* LF: preview of LF 1.11. Preview versions can be changed only to
include bug fixes. Changes of LF 1.12 include:
- reduce transaction size by erasing type information in user-defined
type.
CHANGELOG_END
@aherrmann-da is taking care of 1.10.0-snapshot.20210126.6155.0.a3f3ec1d (#8640), so they get pushed back to the end of the line.
Please do not merge this before #8640.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* include oauth2 logback config in release tarball
overlooked in https://github.com/digital-asset/daml/pull/8611
* Release trigger-service and oauth2-middleware JARs
changelog_begin
changelog_end
* drop from artifacts.yaml
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* add livez endpoint to auth middleware
* Add OAuth 2.0 middleware to Daml SDK
* unhide trigger service auth flags
changelog_begin
- [Triggers] The trigger service now supports authorization through an
auth middleware. The feature is enabled using the `--auth` and
`--auth-callback` command-line flags. Please refer to the
Authorization chapter of the trigger service documentation for further
instructions.
- [OAuth 2.0 middleware] Daml Connect now includes an implementation of
the auth middleware API that supports OAuth 2.0 Authorization Code
Grant. Please refer to the Auth Middleware and OAuth 2.0 Auth
Middleware chapters of the documentation.
changelog_end
* drop early access flag on triggers
Daml triggers, the trigger service, and the auth middleware are no
longer marked as early access features.
changelog_begin
- [Triggers] Daml Triggers and the Trigger Service are no longer in
early access status.
changelog_end
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
@nickchapman-da is taking care of 1.9.0-snapshot.20210119.6103.0.cdcf090b (#8567), so they get pushed back to the end of the line.
Please do not merge this before #8567.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* Bump Maven timeouts and retries
Chosen fairly arbitrarily, I don’t have a good idea what sensible
values are but given that we keep running into issues the current ones
are apparently too low.
changelog_begin
changelog_end
* sync up comment with code
changelog_begin
changelog_end
* s/f/0/
changelog_begin
changelog_end
@remyhaemmerle-da is taking care of 1.9.0-snapshot.20210112.6048.0.e6312fa5 (#8484), so they get pushed back to the end of the line.
Please do not merge this before #8484.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* 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
@robin-da is taking care of 1.9.0-snapshot.20210105.5984.0.c68ba110 (#8403), so they get pushed back to the end of the line.
Please do not merge this before #8403.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
As we strive for more inclusiveness, we are becoming less comfortable
with historically-charged terms being used in our everyday work.
This is targeted for merge on Dec 26, _after_ the necessary
corresponding changes at both the GitHub and Azure Pipelines levels.
CHANGELOG_BEGIN
- DAML Connect development is now conducted from the `main` branch,
rather than the `master` one. If you had any dependency on the
digital-asset/daml repository, you will need to update this parameter.
CHANGELOG_END
@sofiafaro-da is taking care of 1.8.0-snapshot.20201215.5907.0.a6ed34c5 (#8306), so they get pushed back to the end of the line.
Please do not merge this before #8306.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@S11001001 is taking care of 1.8.0-snapshot.20201209.5848.0.e27026ee (#8209), so they get pushed back to the end of the line.
Please do not merge this before #8209.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
Previously, each Protobuf source JAR was considered independent, and did
not require dependencies. This meant that the kvutils Protobuf sources
were published without the associated DAML-LF sources, making them
useless.
This change adds the source JARs as runtime dependencies to ensure that
when publishing a Protobuf source JAR, the release process will fail if
the dependencies are not also published.
CHANGELOG_BEGIN
- [Ledger API] We now publish Protobuf sources in JARs for DAML-LF
types to Maven Central, with the group "com.daml". The artifact names
follow the format "<name>_proto_jar".
CHANGELOG_END
@stefanobaghino-da is taking care of 1.8.0-snapshot.20201201.5776.0.4b91f2a6 (#8126), so they get pushed back to the end of the line.
Please do not merge this before #8126.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
NPM specialcases the latest tag which is used by default and defaults
to that in things like `npm add`. Given that we don’t want people to
rely on snapshots, tagging them as next (common convention on npm)
seems like a good idea.
I have no idea how to test this reasonably so the next snapshot will
have to tell if it works or not.
changelog_begin
changelog_end
CHANGELOG_BEGIN
- [Integration Kit] The kvutils Protobuf definition is now published to
Maven Central in a JAR, under the group "com.daml", with the artifact
name "participant-state-kvutils-proto".
CHANGELOG_END
We don't use them, and they are broken anyway, because Maven demands
Javadoc JARs and our "plain" jars don't provide them.
CHANGELOG_BEGIN
CHANGELOG_END
* ledger-api: Use `proto_jars`.
CHANGELOG_BEGIN
- [Ledger API] The Scala JARs containing the gRPC definitions no longer
contain the *.proto files used to generate the ScalaPB-based classes.
CHANGELOG_END
* Create a source JAR for *.proto files in `proto_jars`.
* ledger-api: Publish the protobuf sources as "ledger-api-proto".
CHANGELOG_BEGIN
- [Ledger API] The *.proto files containing the gRPC definitions are now
provided by a new Maven Central artifact, with the group "com.daml"
and the artifact name "ledger-api-proto".
CHANGELOG_END
* release: We don't need the "main-jar" option.
* Bazel: Proto JARs will always have a Maven artifact suffix.
* Bazel: Simplify Protobuf source file TAR and JAR targets.
* Bazel: Extract out Protobuf functions.
* kvutils: Use ScalaPB to generate a Scala JAR for daml_kvutils.proto.
* Bazel: Delete the unused `da_java_binary` rule, and inline `_wrap_rule`.
* Bazel: Factor out Java/Scala protobuf class generation into a helper.
CHANGELOG_BEGIN
CHANGELOG_END
* daml-lf/archive: Use `proto_jars`.
* Bazel: Remove the visibility modifier from `proto_jars`.
It's too confusing. Just make everything public.
* daml-lf/archive: Push protobuf source tarballs into `proto_jars`.
* Bazel: Add comments to the various parts of `proto_jars`.
* daml-assistant: Do unpleasant things with `location` in Bazel.
@cocreature is taking care of 1.8.0-snapshot.20201124.5709.0.dabd55d0 (#8055), so they get pushed back to the end of the line.
Please do not merge this before #8055.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@garyverhaegen-da is taking care of 1.8.0-snapshot.20201117.5661.0.76fae40c (#7994), so they get pushed back to the end of the line.
Please do not merge this before #7994.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@SamirTalwar-DA is taking care of 1.7.0-snapshot.20201110.5615.0.b35c9fcb (#7937), so they get pushed back to the end of the line.
Please do not merge this before #7937.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* Document new integrity checker options
* Remove v2 from the bazel target in README
* Refactor integrity checker into published "tools" lib + binary
CHANGELOG_BEGIN
CHANGELOG_END
* Refine split
* Release tools lib
* Generalize IntegrityChecker.run
* Use glob for test source definition
* Widen glob for tools-tests to all (future) tool tests, not just integritycheck
* Simplify test source globs
* Simplify tools lib source glob
* Fix build
Although I _really like_ making releases, particularly the testing on Windows, I think it's only fair if I don't have all of them for myself but share them with the team.
CHANGELOG_BEGIN
CHANGELOG_END
@aherrmann-da is taking care of 1.7.0-snapshot.20201027.5530.0.bdbf8977 (#7822), so they get pushed back to the end of the line.
Please do not merge this before #7822.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@nickchapman-da is taking care of 1.7.0-snapshot.20201020.5481.0.03a03957 (#7754), so they get pushed back to the end of the line.
Please do not merge this before #7754.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* resources: Move builders into //ledger/ledger-resources.
Keep the actual constructors in a trait, but instantiate it when working
with ledger code.
This allows us to later introduce an extra "context" type parameter to
ResourceOwner.
* resources-akka: Move the builders in to //ledger/ledger-resources.
* resources: Introduce an abstract `Context` parameter for owners.
This replaces the concrete `ExecutionContext`. While it _can_ be an
execution context, it really doesn't matter as long as we can get at one
somehow.
This is being introduced so we can wrap the context in a container,
either for type tagging or to include extra information.
Because our current context _is_ `ExecutionContext`, and an implicit is
provided to extract it, we can end up with two ways to get the same
value. We use shadowing to prevent this. This problem should go away in
the near future when a new context type is added.
CHANGELOG_BEGIN
- [Integration Kit] The `ResourceOwner` type is now parameterized by a
`Context`, which is filled in by the corresponding `Context` class in
the _ledger-resources_ dependency. This allows us to pass extra
information through resource acquisition.
CHANGELOG_END
* ledger-resources: Move `ResourceOwner` here from `resources`.
* ledger-resources: Remove dependencies from outside //ledger.
* ledger-resource: Wrap the acquisition execution context in `Context`.
So we can add a logging context to it.
* resources: Pass the Context, not the ExecutionContext, to Resource.
* Avoid importing `HasExecutionContext`.
* ledger-resources: Publish to Maven Central.
* resources: Make the small changes suggested by @stefanobaghino-da.
Co-Authored-By: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* ledger-resources: Pull out a trait for test resource contexts.
Saves a few lines of code.
* Restore some imports that were accidentally wildcarded.
* resources: Replace an `implicit def` with a couple of imports.
* participant-integration-api: Simplify the JdbcLedgerDaoBackend tests.
Try and use the right execution context where possible.
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
@robin-da is taking care of 1.7.0-snapshot.20201013.5418.0.bda13392 (#7676), so they get pushed back to the end of the line.
Please do not merge this before #7676.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* Update release instructions to follow newest GSG
We've lately integrated the codegens into `daml start`, which made the GSG significantly shorter in turn. Reflect these changes in the release instructions. Also reword some parts where I found the instructions ambiguous on first reading.
CHANGELOG_BEGIN
CHANGELOG_END
* Apply suggestions
CHANGELOG_BEGIN
CHANGELOG_END
@hurryabit is taking care of 1.6.0-snapshot.20201006.5358.0.0c1cadcf (#7588), so they get pushed back to the end of the line.
Please do not merge this before #7588.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* conservatively move daml-script, trigger SValue interpreters to common library
* introduce expect and JavaList pattern for converters
* clean up trigger Converter Command interpretation
* add Church Free monad
* add an action language for trigger updates
* add expectE to remove some of the joins
* convert more of the converters to expect
* tool for unrolling Free/Roll
* split handleStepResult up and clean up its pattern
* handleStepFreeResult to interpret TriggerF
* replace Free Church with Pure/Roll free from Script
* newtype for ActionTrigger
* replace update in low-level Trigger with Free TriggerF
* submit one Commands at a time
* boolean blindness strikes again
* log missed TriggerF steps
* comment actual Submit contents
* match #7501 fromPureSExpr sig change in 00b80b8ea3
* avoid using forwardPort in runTrigger
* push State back into DAML, so it can be excluded from the action list
* push Message back into DAML, unifying the action language for initialState and update
* bringing TriggerF into initial state
* really add TriggerF into initial state, with all ports, tested
* add ActionTrigger class, express initialState in its terms
* add all TriggerF actions to existing TriggerA
* Trigger.rule will no longer have Time argument
* rename getS, setS to get, put, matching C.M.T.State from transformers
* make high-level Rule evaluate to the underlying TriggerF sequence
* Assert's testRule doesn't have a transform yet
* move DamlTuple2 to common converter library
- suggested by @cocreature; thanks
* combine the two Frees, provide from Script
* remove time argument from integration tests
CHANGELOG_BEGIN
- [Triggers] The ``Time`` argument was removed from the trigger rule function; instead, it
can be fetched within the ``TriggerA`` ``do`` block by ``getTime``, as with ``Update``
and ``Scenario``. The ``LowLevel`` trigger interface has been redesigned; such triggers
need to be rewritten or ported to high-level triggers.
See `issue #7456 <https://github.com/digital-asset/daml/pull/7456>`_.
CHANGELOG_END
* add trigger rule simulator to support Assert module
* missed new Free module
- left in script per @cocreature
* remove retract as we ended up using foldFree for that purpose instead
- suggested by @cocreature; thanks
* throw ConverterException instead of RuntimeException
- suggested by @cocreature; thanks
* remove Time argument from coin-upgrade-trigger
* port trigger service tests
* port trigger scenario test
* put TriggerSetup and TriggerRule into LowLevel.Trigger instead of unboxed Free
- suggested by @cocreature; thanks
* remove Time argument from trigger compatibility test
* submit commands as soon as each `emitCommands` is sequenced
- we still collect a list, but only for tracking commandsInFlight
* filter out compatibility tests for triggers before now
* remove commented imports, libraries from new shared converter
* make the TriggerF interpreter tail-recursive
* remove unused compatibility trait
* add back new state logging
* remove refactoring comment
* rewrite some LowLevel initialStates in do
* hide Daml.Script.Free from docs
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* remove forwardPortInitialState
- suggested by @cocreature; thanks
* manually port low-level updates
- suggested by @cocreature; thanks
* remove forwardPort
- suggested by @cocreature; thanks
* fail faster on unrecognized TriggerF
- suggested by @cocreature; thanks
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
@sofiafaro-da is taking care of 1.6.0-snapshot.20200929.5303.0.f1e58206 (#7522), so they get pushed back to the end of the line.
Please do not merge this before #7522.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* concurrent: Tag DirectExecutionContext.
1. Tag `DirectExecutionContext` as `ExecutionContext[Nothing]`, thereby
stating that it works for any tagged `Future`.
2. Move `DirectExecutionContext` to the _libs-scala/concurrent_
library, as it requires it and it's tiny.
CHANGELOG_BEGIN
CHANGELOG_END
* concurrent: Fix the privacy of `DirectExecutionContextInternal`.
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
With the introduction of the standalone JAR, we cannot rely on the
assistant anymore to pass the default logback config. Users can still
override the logback config with `-Dlogback.configurationFile` if they
need something else but this provides a more sensible default logging
config than seeing a ton of debug logs from netty.
changelog_begin
changelog_end
- Followup to #7338, adjusting release test instructions for changes to the Java
quickstart, mismatches found testing #7462. Compare to
docs/source/app-dev/bindings-java/quickstart/template-root/daml/Main.daml for line #
references.
CHANGELOG_BEGIN
CHANGELOG_END
@S11001001 is taking care of 1.6.0-snapshot.20200922.5258.0.cd4a06db (#7462), so they get pushed back to the end of the line.
Please do not merge this before #7462.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* add phantom-tagged ExecutionContext and Future to scala-utils concurrent package
* many new operations for Futures
* Future, ExecutionContext combinators from porting ledger-on-sql
- picked from 546b84ab9cdf4de2d93ec5682bdee6cfd6b385f8
* move Future, ExecutionContext companions into normal package
* lots of new docs
* many new Future utilities
* working zipWith
* tests for ExecutionContext resolution, showing what will be picked under different scenarios
* even more tests for ExecutionContext resolution
* tests showing some well-typed and ill-typed Future combinator usage
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* missed scalafmt
* one more doc note
* split concurrent package to concurrent library
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* Improve release instructions
- Add more notes on Remmina and how to use ad-hoc machines
- Fix Windows quickstart testing after change to template
changelog_begin
changelog_end
* Fix typo
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
@stefanobaghino-da is taking care of 1.6.0-snapshot.20200915.5208.0.09014dc6 (#7410), so they get pushed back to the end of the line.
Please do not merge this before #7410.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
Please indulge my OCD.
And apologies to whoever was counting on these for their steganographed
[Whitespace] program.
[Whitespace]: https://esolangs.org/wiki/Whitespace
CHANGELOG_BEGIN
CHANGELOG_END
We reach the timeout on pretty much every release lately and we need to
retry to entire release process two or three times to get through. This
is us giving up on Maven, not Maven itself crashing, so I4d like to try
giving it more time.
CHANGELOG_BEGIN
CHANGELOG_END
@cocreature is taking care of 1.5.0-snapshot.20200908.5166.0.1623baec (#7348), so they get pushed back to the end of the line.
Please do not merge this before #7348.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
NPM doesn’t actually need this (at least it didn’t for me locally and
hopefully CI agrees) to pick up changes and it emits a very
scary-looking warning if you do pass it.
changelog_begin
changelog_end
@rohanjr is taking care of 1.5.0-snapshot.20200901.5116.0.4460cb5e (#7296), so they get pushed back to the end of the line.
Please do not merge this before #7296.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@leo-da is taking care of 1.5.0-snapshot.20200825.5071.0.d33e130f (#7233), so they get pushed back to the end of the line.
Please do not merge this before #7233.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
@garyverhaegen-da is taking care of 1.5.0-snapshot.20200818.5027.0.1b33d374 (#7173), so they get pushed back to the end of the line.
Please do not merge this before #7173.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
This PR attempts to add some automation around assigning release
management. The PR adds a file `release/rotation`; each week, the
updated CI cron job will:
- Open a PR for the new release [as current].
- Assign the first user in the file to that PR.
- Add the Standard-Change label to the PR.
- Start the build for that PR [as current].
- Open a new PR that rotates the `release/rotate` file, i.e. pushes back
the first line to the end of the file.
This PR also adds mentions of the "release handler" (the first line of
`release/rotation`) to the various messages we send to Slack along the
release process.
The initial state of the `release/rotation` file has been created by
listing all the volunteers (Language team, Application Runtime team, as
well as @SamirTalwar-DA and @stefanobaghino-da) and piping the file
through `shuf`. (Then I put myself at the top so I can hopefully iron
out the issues with the first attempt.)
CHANGELOG_BEGIN
CHANGELOG_END
* 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>
* Moving `Statements.discard` from //ledger-server/http-json into //libs-scala/scala-utils
changelog_begin
changelog_end
* Add new module to the published artifacts
* `com.daml.scalautil` instead of `com.daml.scala.util`
@S11001001: That's because if this is in classpath and you import com.daml._,
you have a different scala in scope than the one you expect.
* Extend `daml new` to accept template as an option
The two positional arguments keep confusing users so this PR changes
things to allow the template to be passed via `--template`. Using a
positional argument still works so this is not breaking.
I’ve updated all docs to use the less confusing syntax.
changelog_begin
- [DAML Assistant] You can now use ``daml new project-name
--template=template-name`` instead of ``daml new project-name
template-name``. The old CLI syntax continues to be supported.
changelog_end
* Update docs/source/getting-started/index.rst
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Move public code into daml-integration-api
CHANGELOG_BEGIN
[DAML Integration Kit]: Removed sandbox specific code from the API intended to be used by ledger integrations. Use the maven coordinates ``com.daml:participant-integration-api:VERSION`` instead of ``com.daml:ledger-api-server`` or ``com.daml:sandbox``.
CHANGELOG_END
This was never intentional, nobody even knew that this was possible
and we have an alternative, documented way of getting this via github
releases.
To avoid introducing this issue again, I’ve removed non-jar artifact
types from the Maven upload script.
fixes#448
changelog_begin
changelog_end
* Add `platform-version` field to `daml.yaml`
This PR adds the `platform-version` field to `daml.yaml`. Based on the
approach agreed upon in #6558, the logic for this all sits in
`daml-helper` and there are no changes to the assistant.
The details of how the logic work are in a comment so I’m not going to
repeat them here but the commands that are affected are:
- `daml sandbox`
- `daml sandbox-classic`
- `daml json-api`
- `daml start` (but only for sandbox and the JSON API, not for
Navigator or anything else)
For tests, I’ve added a test to the compat workspace that installs two
SDKs simultaneously and tries out various combinations and verifies
that we get the correct version. Open to other ideas for testing this
but that seemed like the most sensible option that actually tests what
we run.
changelog_begin
- [DAML Assistant] You can now specify the version of Sandbox and the
JSON API independently of your SDK version by setting
``platform-version`` in your ``daml.yaml``. This is useful if you
are deploying to a ledger that is running components from a
different SDK version. See
https://docs.daml.com/tools/assistant.html#project-config-file-daml-yaml
for details.
changelog_end
* Run platform-version tests
changelog_begin
changelog_end
* Fix tag globbing
changelog_begin
changelog_end
* fmt
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* Try to fix env vars
changelog_begin
changelog_end
* Remove hardcoded references to 1.2.0
changelog_begin
changelog_end
* Rephrase doc comment
changelog_begin
changelog_end
* get things to compile
changelog_begin
changelog_end
* maybe fix things for realz
changelog_begin
changelog_end
* Remove debugging output
changelog_begin
changelog_end
* Get angry at windows
changelog_begin
changelog_end
* why is windows
changelog_begin
changelog_end
* .
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
* Address https://github.com/digital-asset/daml/pull/6507#discussion_r446113575
* drop blindinginfo.proto
changelog_begin
changelog_end
* drop BlindingCoder
* Remove blindinginfo Protobuf definition JAR
changelog_begin
[DAML-LF] The blindinginfo Protobuf definition JAR, which was previously unused, has been pulled from the artifacts released on Maven
changelog_end
Co-authored-by: Remy Haemmerle <Remy.Haemmerle@daml.com>
* LF: rename library transaction-scalacheck to transaction-test-lib
CHANGELOG_BEGIN
CHANGELOG_END
* move files in com/daml
* missing change in release/artifacts.yaml
* remove 'com/dam' from the path
* Add release checklist to release instructions
This includes a couple of checks that internal projects have been
tested on the release candidate.
changelog_begin
changelog_end
* Update release/RELEASE.md
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* release: Compute missing deps by using one Bazel query, not many.
* release: Publish all JARs to the local Maven repository at once.
This is way, way faster than running `mvn install:install-file` in a
loop.
It works by creating a POM that instructs the `install:install-file`
plugin command to install the JARs in roughly the same way as before,
and then running `mvn initialize` once.
CHANGELOG_BEGIN
CHANGELOG_END
* release: Make the `Maven` file easier to read with less nesting.
And also more nesting.
* release: Always validate the Maven artifacts, as before.
* release: Explain `maybeMissingDeps` a little better.
* release: Delete the comment on excluding scenario and script services.
* release: Use `withCreateProcess` when calling `mvn initialize`.
* release: Build the TypeScript packages in one `bazel` call.
* release: Remove an unncessary `liftIO`.
This small PR makes a few QoL improvements to the release.sh script:
1. The snapshot command will now work for any commit. Previously, it
would refuse to print the snapshot suffix for commits that were not
ancestors of the `master` branch. The new version will print a
warning if the commit does not seem to be part of a release branch,
but will still print the result.
2. On checking the LATEST file, the script will now print a slightly
more useful error message if the file format is not valid.
3. The snapshot command will now print the entire line to be added into
the LATEST file, rather than just the version suffix.
CHANGELOG_BEGIN
CHANGELOG_END
The `gawk`-based method currently referenced does not work in a
multi-line `LATEST` world. I don't want to scare people with the command
that would work here.
CHANGELOG_BEGIN
CHANGELOG_END
* equalz Scalatest matcher in new daml-lf/scalatest-tools library
* equalz typing tests
* a 'should' replacing design
* a 'MatcherFactory1' design
- this fails because the TC parameter should be a type member to avoid
scala/bug#5075 but it is not
* MatcherFactory1 with chained Lub+Equal typeclass
- requires partial-unification at point of use, which is not great
* LubEqual's extra tparam is probably unneeded
* better LtEqual
* demonstrate that HK LubEqual's resolve with DMT should + MatcherFactory
* remove unneeded 3rd param from LubEqual, again
* update dependency specs and license headers
* allow use with should, shouldNot in some cases, preserving the shouldx/shouldNotx alternatives
* move Equalz to libs-scala/scalatest-utils
* rename bzl targets and place in com.daml.scalatest package
* add scalatest-utils to release
* move *SpecCheckLaws, Unnatural to scalatest-utils
* missed scalacheck dep in scalatest-utils
* downstreams of *SpecCheckLaws now get them from scalatest-utils
* test equal-types case as well
* update LF documentation
CHANGELOG_BEGIN
CHANGELOG_END
* whitespace error
trigger all releases from master
The 1.1.0 release went wrong and we had to trash it and release 1.1.1
instead. This is an attempt at identifying and correcting the root
cause behind that incident.
To understand the situation, we need to know how releases worked before
1.0. We had a one-line file called `LATEST` that specifies the git SHA and
version tag for the latest release. A change to that file triggered a
release with the specified release tag, built from the source tree of
the specified commit. The `LATEST` file looked something like:
```
f050da78c9 1.0.0-snapshot.20200411.3905.0.f050da78
```
To mark a release as stable, we would change it to look like this:
```
f050da78c9 1.0.0
```
i.e. simply drop the `-snapshot...` suffix. Even though the commit (and
thus the entire source tree we build from) is the same, we would need to
rebuild almost all of our release artifacts, as they embed the version
tag in various places and ways. That worked well as long as we could
assume we were doing trunk-based development, i.e. all releases would
always come from the same (`master`) branch.
When we released 1.0, and started work on 1.1, we had a few bug reports
for 1.0 that we decided should be resolved in a point release. We
decided that the best way to handle that would be to have a branch
starting on the release commit for 1.0, and then backport patches from
`master` to that branch. We adapted our build process to also watch the
`release/1.0.x` branch and, in particular, trigger a new release build if
the `LATEST` file in that branch changed. That worked well.
The plan going forward was to keep doing regular snapshot releases from
the `master` branch, and create support, point releases ("patch" releases
in semver) from dedicated branches.
On April 30, we made a snapshot release as an RC for 1.1.0, by changing
the `LATEST` file in the `master` branch. That release was built on commit
681c862d. On May 6, we decided to take a new snapshot as the RC for
1.1.0; we changed `LATEST` in `master` to designate 7e448d81 as the new
latest release.
On May 11, we noticed an issue that broke our builds. Without going into
details, an external artifact we depend on had changed in incompatible
ways. After fixing that on `master`, we reasoned that this would also
break the build of the final 1.1.0 release if we just tried to build
7e448d81 again. But as the target release date was May 13, we did not
want to take a new snapshot after that fix, as that would have included
one more week of work in the release, and given us no time to test it.
So we did what we did for the 1.0 branch, as it had worked well: we
created a branch that forked from `master` at commit 7e448d81 and called
it `release/1.1.x`, then cherry-picked the one fix to our build process to
work around the broken download. When the time came to make the final
1.1.0 build on May 13, we naturally picked the `LATEST` file from the
`release/1.1.x` branch and dropped the `-snapshot...` suffix. Importantly,
we did not need to update the target commit to include the "broken
download" fix as, in the meantime, the internet had fixed itself, and we
thus reasoned we should go for the exact code of the RC rather than
include an unnecessary, albeit seemingly harmless, change.
Everything went well with the release process. Tests went well too. Then
we got a report that an application that worked against the latest RC
broke with the final 1.1.0. The issue was that we had built the wrong
commit: by branching off at the point of the _target_ commit for the
latest snapshot, we did not have the change to the `LATEST` file that
designated that commit as the target. So the `LATEST` file in
`release/1.1.x` was still pointing to 681c862d.
I believe the root cause for this issue is the fact that we have
scattered our release process over multiple branches, meaning there is
no linear history of what was released and we are relying on people
being able to mentally manage multiple timelines. Therefore, I propose
to fix our release process so this should not happen again by
linearizing the release process, i.e. getting back to a situation where
all releases are made from a single branch, `master`.
Because we do want to be able to release _for_ multiple release branches
(to provide backports and bugfixes), we still need some way to
accommodate that. Having a single `LATEST` file in the same format as
before would not really work well: keeping track of interleaved release
streams on a single file would not really be easier than keeping track
of multiple branches.
My proposed solution is to instead have a multiline LATEST file, so that
all the release branch "tips" can be observed at the same time, and, as
long as we take care to only advance one release branch at a time, we
can easily keep track of each of them. This is what this PR does.
This required a few changes to our release process. Most notably:
- Obviously, as this is the main point of this PR, the build process has
once again been restricted to only trigger new releases from the
`master` branch.
- As our CI machinery cannot easily be made to produce multiple releases
from a single build, the `check_for_release` step will only recognize
a commit as a release trigger if it changes a single line in the
`LATEST` file. This restriction comes in addition to the existing one
that a release commit is only allowed to change either just the
`LATEST` file or both the `LATEST` and
`docs/source/support/release-notes.rst` files.
- The docs publication process has been changed to update _all_
published versions to display the _latest_ release notes page. This
means that the release notes page will always show you all published
versions, regardless of which version of the documentation you're
looking at. This also means that interleaving release notes correctly on
that page is a manual exercise.
- As per the intention of the new process, the `LATEST` file has been
updated to contained all existing post-1.0 stable releases. It should
also include all existing snapshot releases should we have more than one
at a time (say, should we discover an issue with 1.1.1 that required us
to work on a 1.1.2).
- The `release.sh` script has been dramatically simplified as I felt it
was trying to do too much and porting its existing functionality to a
multi-line `LATEST` file would be too hard.
CHANGELOG_BEGIN
CHANGELOG_END
* Extract caching from participant-state as a library
This will be used to keep a cache of values to cut on LF translation cost when serving transactions.
changelog_begin
changelog_end
* Add dependency where missing
Currently, there are quite a few releases that are lacking the
Standard-Change label, even though they did publish artifacts. This
makes our SOC2-compliance tracking a bit harder. For the past two
months, I have manually added the label after-the-fact while preparing
the monthly compliance report, but that doesn't seem like a great
solution.
This PR changes the release process to be more optimistic: assume the
release is going to succeed by putting in the label immediately, and
then (optionally) removing it if the release fails.
Note that the label should only be removed in the rare case where the
release was merged into master but somehow did not produce any artifact.
This can only happen if the Linux build fails quite early, which as far
as I know only happened once over the past two months when we had the
release notes race condition.
CHANGELOG_BEGIN
CHANGELOG_END
* factor TlsConfiguration parser from extractor
* move TlsConfigurationParser to new library
* link extractor to ledger-service/cli-opts properly
* use TlsConfigurationCli in http-json, pass SslContext to ledger-client
* test TLS options as used in http-json
- the TLS config code is shared with extractor, where it is more fully
tested; we just do a sanity check here
* doc TLS options for http-json
CHANGELOG_BEGIN
- [JSON API] New ``--pem``, ``--crt``, ``--cacrt``, and ``--tls`` options
for securing the connection between JSON API server and ledger.
See `issue #2540 <https://github.com/digital-asset/daml/issues/2540>`__.
CHANGELOG_END
* TLS off in daml-script JSON API test
This PR updates two points in the release process:
1. The process for getting release notes for a stable release based on
my experience of doing that for the past 2 releases.
1. It adds testing for the getting started guide. I did not remove the
testing of `quickstart-java`. I do want to test scenarios and
navigator and a bit of VSCode so the only potentially redundant
point there is the `mvn compile` step but that verifies that Maven
artifacts have been published successfully so I think it is still
useful.
changelog_begin
changelog_end
* ledger/metrics: Move metric helpers to their own Bazel package.
CHANGELOG_BEGIN
CHANGELOG_END
* sandbox: Use ledger/metrics.
* metrics: Rename `Metrics` to `Timed` and drop the `timed` prefix.
Importing methods is harder than importing objects.
* metrics: Publish to Maven Central.
* 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
CHANGELOG_BEGIN
- Move daml2ts, bindings-ts and JSON API out of experimental section in docs
- Rename Experimental to Early Access in docs and assistant
- Reorganise the docs a little bit to de-emphasise the Ledger API
CHANGELOG_END
This PR removes the code for publishing to Bintray and updates the
documentation to point to github releases or Maven central.
I had to slightly change the docs formatting since trying to use
markup in code blocks results in a horrible layout and I don’t want to
fix that atm.
I’ve removed all artifacts that were only published to Bintray.
changelog_begin
changelog_end
* 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
* Make SDK release tarball reproducible
Without these changes multiple factors contribute to a different SDK
release tarball on each rebuild:
* Without `--sort=name` the order of files in the archive is determined
by the OS and essentially random.
* Without the `--owner/group/mtime` flags the archive contains metadata
that depends on the environment.
* Without `-n` `gzip` would write a timestamp into the produced
artifact.
CHANGELOG_BEGIN
CHANGELOG_END
* sdk-release-tarball: zip is unused
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* release: Reformat Markdown to fit 80 characters, and adding punctuation.
CHANGELOG_BEGIN
CHANGELOG_END
* release: Formatting, an extra test step, and a bit of clarification.
* 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>
* participant-state{,-index}: Move Timed*Service classes from Sandbox.
CHANGELOG_BEGIN
- [Ledger Integration Kit] Metrics for the various read, write, and index
services.
CHANGELOG_END
* kvutils/app: Add timing metrics for read/write/index services.
* participant-state: Move metrics-related code to another Bazel package.
* participant-state-metrics: Add to artifacts.yml.
* participant-state-metrics: Move TimedIndexService back into Sandbox.
Cuts down on dependencies like nobody's business.
* 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
* 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>
* 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.
Previously we assumed that the module name was globally unique in the
DAR which is definitely not guaranteed. Now we instead detect the
package id of the trigger library based on the type of the trigger we
are running which doesn’t fall apart if there are multiple versions of
the trigger library.
I’ve also removed the check for the package id of the trigger library
since I’d like the trigger runner to be backwarts compatible from now on (we
didn’t break that in a while).
This is slightly ugly since the Runner class is currently not specific
to a single trigger but only the individual methods are aware of the
specific trigger identifier. I’ll refactor this in a separate PR.
changelog_begin
changelog_end
In the current state of the release instructions, the person in charge
of the release has to figure out how to produce the changelog. This PR
adds more specific (and hopefully simpler) instructions for producing
relevant changelogs.
CHANGELOG_BEGIN
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.
