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
Somewhat error-prone, so please review carefully.
Reasons we need this:
- Some file types are not properly handled by the script.
- The only exclusion mechanism we currently have (`NO_AUTO_COPYRIGHT`)
is overly coarse.
CHANGELOG_BEGIN
CHANGELOG_END
New year, new copyright, new expected unknown issues with various files
that won't be covered by the script and/or will be but shouldn't change.
I'll do the details on Jan 1, but would appreciate this being
preapproved so I can actually get it merged by then.
CHANGELOG_BEGIN
CHANGELOG_END
* Split up docs postprocessing & release in split-release
Follow up to #12172
The buld in the separate assembly should now only have to run the
sphinx-build step and then merge it with the non sphinx sources and
run lualatex on the pdf sources with the pdf fonts which is hopefully
simple enough that we can easily replicate it.
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
* .
changelog_begin
changelog_end
They migrated our account so hopefully this should work without any
other changes and fix our publishing issues.
I’m keeping the long timeout for now since I don’t know what an
appropriate timeout is.
changelog_begin
changelog_end
* revert to use synopsys detect 7.1.0 run-full-compat: true
CHANGELOG_BEGIN
CHANGELOG_END
* run on branch run full compat
run-full-compat: true
* run on branch run full compat
run-full-compat: true
* revert changes to run branch
