Process:
- `git ls-files | xargs sed -i 's/DAML/Daml/g'`
- `git add -p`
To review:
- Check for false positives by carefully reviewing the diff in this PR.
- Check for false negatives with `git grep DAML`.
CHANGELOG_BEGIN
- Removed all traces of DAML. This may affect error messages and debug
outputs.
CHANGELOG_END
In some cases we may end up with the tip of the main branch built as a
split release manually. When Azure then tries to run it, the release
fails (typically on the upload to NPM step).
Normally, Azure is set to run this only once per commit, but that only
applies when the run is successful. So if it breaks in a reproducible
way (e.g. because the version already exists on NPM), Azure will keep
trying every day.
This PR adds a simple guard that makes the nightly build _not_ a release
commit if the reelease already exists, which should short-circuit most
of the jobs in the build and finish successfully.
CHANGELOG_BEGIN
CHANGELOG_END
* Don't error when user tokens are provided for the perf runner
changelog_begin
changelog_end
* Better token parsing error handling & extract user id to allocate the user if so
* make the code prettier
* Fix & simplify token parsing
* fix formatting of bazel file
* Update ledger-service/http-json-perf/src/main/scala/com/daml/http/perf/Main.scala
Co-authored-by: Raymond Roestenburg <98821776+ray-roestenburg-da@users.noreply.github.com>
* correctly handle the response of createUser & don't throw if no LedgerId was found in the token
* Wrap exceptions in Futures
* Refactor Main.scala of the perf runner completely & remove dependency on user provided JWT's
* Minimize diff
* simplify code further
* Update ledger-service/http-json-perf/src/main/scala/com/daml/http/perf/Main.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update ledger-service/http-json-perf/src/main/scala/com/daml/http/perf/Main.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update ledger-service/http-json-perf/src/main/scala/com/daml/http/perf/Main.scala
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Fix build
* Don't pass a jwt to the perf runner anymore everywhere it was used & fix ledger id to be right
* Minimize diff
Co-authored-by: Raymond Roestenburg <98821776+ray-roestenburg-da@users.noreply.github.com>
Co-authored-by: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
* Update 'implements' blocks to use new syntax
* Add InterfaceSyntax test case
* Add InterfaceMultipleMethodDeclsError test case
* Add InterfaceDifferentNumArgsError test case
changelog_begin
changelog_end
* Add test for multiple ensure declarations in interface
* update ghc patch
* Update expected result for daml-doc interface test
changelog_begin
changelog_end
* Add Oracle compatibility tests
changelog_begin
changelog_end
* Clean up
* Remove debug change
* Skip Oracle tests if there is nothing to do
* Add missing line warp
* Use ORACLE_PORT
Co-authored-by: mziolekda <marcin.ziolek@digitalasset.com>
Co-authored-by: mziolekda <marcin.ziolek@digitalasset.com>
I also changed CI config so we run this on every build but only upload
on releases. That should hopefully make sure we catch this immediately
next time. The script is fast enough that this shouldn’t slow this
down meaningfully.
changelog_begin
changelog_end
Since #12645, we added a new pipeline, so we need to add a corresponding
entry.
As for #12645, the content of the files and the directory structure is
taken directly from a live CI node, as printed by the (now-named)
`workdirs` step.
CHANGELOG_BEGIN
CHANGELOG_END
This reverts a small part of 9e1e42d27c
(#12901).
Microsoft seems to have given us our free parallel jobs back, so we can
run the patch_bazel job again.
Fixes#12900.
CHANGELOG_BEGIN
CHANGELOG_END
This should hopefully get CI working again.
There are two changes in here:
1. We can no longer change our patched Bazel. I didn’t switch away
from the current patched version for now (we upload it to gcp bucket
so it still works fine even if we cannot build it) but if we upgrade,
we need to go to an unpatched version for now.
2. We need to get `az` from dev-env. I tested the self service compat
job stuff and it works fine with this but there is a chance other
parts don’t.
changelog_begin
changelog_end
Because there's no reason not to. The only obstacle to automating the
normal release process is that we need an explicit manual validation
step for our audit log when creating a release, but split-releases are
created in the Assemblty repo, so we can have the audit log over there.
The diff is going to be very messy because there's a lot of stuff moving
around. The only thing that is not just moving a job to a separate file
is the `ci/daily-snapshot.yml` file, which is 100% new and is meant as
a new Azure Pipelines entrypoint (which I will create after this gets
approved). I have made a reasonable effort to create individual commits
that simplify reviewing, but I expect it's still going to be kind of a
mess. I'm open to opening separate PRs to ~bump my stats~ move one job
at a time if that makes reviewing (and testing) easier.
CHANGELOG_BEGIN
CHANGELOG_END
* Add new primitives to proto spec
* implement E{Signatory,Observer}Interface in terms of EResolveVirtual{Signatory,Observer}
* define EToTypeRep primitive in terms of EToTypeRep Expr
* Remove experimental primitives TO_TYPE_REP and RESOLVE_VIRTUAL_{SIGNATORY,OBSERVER}
changelog_begin
changelog_end
With this change, Daml exerciseByKey use the LF primitive
ExerciseByKey instead of the combinason of FetchByKey + Exercise.
CHANGELOG_BEGIN
CHANGELOG_END
The mapping from Azure job to local folder is managed by a handful of
JSON files under `$WORKDIR/SourceRootMapping`. Based on the sketchy
[documentation] that screams "don't mess with these definitely internal,
subject-to-change files", it seeems to me that our best bet for pinning
Windows work folders is to mess with these files. Specifically, take a
"version" of these files we like from a live CI machine and add those
specific files to the init script of our Windows nodes.
[documentation]: https://github.com/microsoft/azure-pipelines-agent/blob/master/docs/jobdirectories.md
So the first step is to collect these files, which is what this PR aims
to accomplish.
CHANGELOG_BEGIN
CHANGELOG_END
I'm not quite sure what's going wrong here, but this PR:
- Fixes a small bug in the process for determininng that we're _not_ in
a split release, which worked because the boolean expression crashing
is the same as the boolean expression returning false. But I'd still
prefer if it returned false without crashing.
- Changes the condition for skipping the Windows installer so that in
case of ternary+ logic we default to the harmless behaviour (including
it).
- Makes a change that might have some impact maybe on the way Azure
expands templates which may or may not result in the installer being
excluded when it should be excluded. But this time if it doesn't work
worst case we get an extra unused binary that uses some disk space,
instead of crashing the release.
CHANGELOG_BEGIN
CHANGELOG_END
In the split release process, the executable installer has to be created
later in the pipeline, once we have the Canton parts available.
CHANGELOG_BEGIN
CHANGELOG_END
Most of this is just documentation. The actual idea here is fairly
simple:
- The assembly repo pushes to S3 on each release (not yet implemented).
- The cronjob skips releases that are already there.
- Updating the top-level just piggybacks on what we already have.
changelog_begin
changelog_end
This follows the approach we used for the BazelCache stuff and splits
the 3 different operations in 3 separate modules + one Github utility
module to make it a bit easier to follow.
This is pure reshuffling, no functional change.
changelog_begin
changelog_end
Apologies for doing two things in one PR but they seemed somewhat
entangled.
For artifactory we follow the approach we use for Maven artifacts and
publish there directly.
For the SDK EE tarball, we just throw it in the split-release
directory and then the assembly repo can pick it up.
changelog_begin
changelog_end
