This PR drops two things:
1. The check that the benchmark hasn’t been modified. This hasn’t ever
been useful and it keeps being annoying.
2. It stops the comparison against the old version and instead just
benchmarks the current version. We really only care about the day to
day changes. Comparing against an arbitrary year old version has lost
all meaning at this point.
changelog_begin
changelog_end
Now that we skip the scala_2_12 job this dep results in us never
running the release job which is clearly not intentional.
changelog_begin
changelog_end
* maybe fix deleted release tags
Hard to know for sure until the next broken release.
CHANGELOG_BEGIN
CHANGELOG_END
* Update azure-pipelines.yml
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Ubuntu 16.04 nodes are about to go away and there dosen’t seem to be a
compelling reason to use the hosted nodes here anyway.
This is obviously hard/impossible to test without a release but I did
do some basic sanity checks: The release build seems to rely on the
following tools (+ things like rm which are clearly there)
1. git
2. gpg
3. sha256sum
4. gcloud
5. curl
All of those are installed on our own nodes. If this doesn’t work we
could also run (parts of) this in dev-env but for now this should do
the job.
changelog_begin
changelog_end
.
changelog_begin
changelog_end
.
changelog_begin
changelog_end
Three issues here:
1. The release job runs on an Azure-hosted agent, so it doesn't have the
`reset_caches.sh` script (and doesn't need it).
2. The `bash-lib` step should not run if the current job has already
failed.
3. The `skip-github` jobs should also not run if the job has failed.
CHANGELOG_BEGIN
CHANGELOG_END
The revamped release process relies on publish.sh coming from the
release tag. However without the checkout that doesn’t work. This
resulted in us trying to push the EE tarball for a branch that does
not have it yet.
changelog_begin
changelog_end
* Move artifact publishing out of yaml files
The current publishing process pretty much hardcodes the set of
artifacts we publish in the yaml config. This is a problem because we
always release from `main` so the yaml files are always
identical. However, we will add new artifacts over time and this
starts falling apart. This PR changes this such that the process
described in the yaml files is very generic and just uploads and
downloads everything in a directory whereas the details are handled in
bash scripts that will come from the respective release branch and are
therefore version-dependent.
As usual for these type of changes, I don’t have a great way to test
this. I did do some due diligence to test that at least the artifacts
are published correctly and I can download them but I can’t test the
actual publishing.
changelog_begin
changelog_end
* Update ci/copy-unix-release-artifacts.sh
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* Update ci/copy-windows-release-artifacts.sh
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* Update ci/publish-artifactory.sh
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
The people who care about these alerts monitor the channel closely
enough anyway, and having frequent automated @here bells ringing makes
it harder for individuals to highlight important messages.
CHANGELOG_BEGIN
CHANGELOG_END
My goal here is to investigate the new warning Azure has been showing
for the past few days:
> ##[warning]%25 detected in ##vso command. In March 2021, the agent command parser will be updated to unescape this to %. To opt out of this behavior, set a job level variable DECODE_PERCENTS to false. Setting to true will force this behavior immediately. More information can be found at https://github.com/microsoft/azure-pipelines-agent/blob/master/docs/design/percentEncoding.md
As far as I'm aware we are not deliberately passing in any `%25` in any
of our `vso` commands, so I was a bit surprised by this.
CHANGELOG_BEGIN
CHANGELOG_END
CHANGELOG_BEGIN
- Our Linux binaries are now built on Ubuntu 20.04 instead of 16.04. We
do not expect any user-level impact, but please reach out if you
do notice any issue that might be caused by this.
CHANGELOG_END
* 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>
Apparently it's been silently broken since introduction all the way back
in #7196.
Huge thanks to @SamirTalwar-DA for reporting.
CHANGELOG_BEGIN
CHANGELOG_END
For a couple weeks now there has been a warning on the Azure Pipelines
web UI that says `ubuntu-latest` is in the process of switching from
18.04 to 20.04. I am not aware of any specific issue this would cause
for our particular workflows, but I don't like my dependencies changing
from under me.
CHANGELOG_BEGIN
CHANGELOG_END
This is another take on #8276, with the same underlying motivation.
However, this approach is mostly duplication-free, which seems better,
especially given the already-pretty-sorry state of our CI config.
Like #8276, this is done in 2 commits for ease of review. The first
commit is wholly unintresting and just copies `azure-pipelines.yml` to
both `ci/prs.yml` and `ci/build.yml`; the second commit removes from
each part what it shouldn't have. The intention is for `ci/build.yml` to
have all of the common parts.
CHANGELOG_BEGIN
CHANGELOG_END
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
* Port //daml-lf/data to Scala 2.13
changelog_begin
changelog_end
* factor common ImmArraySeq code to version-agnostic file
- ImmArraySeq itself is agnostic; the 2.12 and 2.13 versions contain
implementation mixins/superclasses for parts that must be specific. The 2.13
version will collapse into the agnostic version when 2.12 support is no longer
desired
* factor common InsertOrdMap code to version-agnostic file
- InsertOrdMap itself is agnostic; the 2.12 and 2.13 versions contain
implementation mixins/superclasses for parts that must be specific. The 2.13
version will collapse into the agnostic version when 2.12 support is no longer
desired
* factor common InsertOrdSet code to version-agnostic file
- InsertOrdSet itself is agnostic; the 2.12 and 2.13 versions contain
implementation mixins/superclasses for parts that must be specific. The 2.13
version will collapse into the agnostic version when 2.12 support is no longer
desired
* factor Map removal
* Move ImmArraySeq back into ImmArray
changelog_begin
changelog_end
* Type assertion instead of symbol
changelog_begin
changelog_end
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Do not checkout release commit in scala 2.13
At least for now, this fails because older commits don’t have the
necessary infrastructure so far. At some point we probably do want to
run this on release commits but that can wait a bit and this unblocks
release PRs for bugfix releases.
changelog_begin
changelog_end
* Update azure-pipelines.yml
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
Co-authored-by: Gary Verhaegen <gary.verhaegen@digitalasset.com>
* Build //libs-scala/... on 2.13
One test is unfortunately disabled at the moment since I utterly
failed to figure out why I get a ClassNotFoundException on 2.13.
changelog_begin
changelog_end
* Copyright headers
changelog_begin
changelog_end
* I can’t bazel today
changelog_begin
changelog_end
* Apply suggestions from code review
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* Update libs-scala/resources/src/main/2.13/com/daml/resources/UnitCanBuildFrom.scala
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* No split on view
changelog_begin
changelog_end
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
Co-authored-by: Stephen Compall <stephen.compall@daml.com>
* Add a Scala 2.13 build pipeline
This adds initial support for multiple Scala versions controlled via
the DAML_SCALA_VERSION env var and a CI job to make sure we don’t
regress. For now we only test //libs-scala/ports/... which seemed like
the easiest starting point I could find. We can incrementally expand
that over time.
changelog_begin
changelog_end
* Document pinning
changelog_begin
changelog_end
* Address review comments
changelog_begin
changelog_end
The current implementation of the notify_user job sometimes reports
success while the build has actually failed. Azure does not provide a
way to query the overall state of the current build, so a general
solution to this problem does not seem possible (see #6796 for an
example of a failed attempt). However, all reported cases were
specifically about the `check_changelog_entry` job, which we can easily
query for, so this PR does that.
Note: originally pushed without a changelog entry to test new
notification mechanism.
CHANGELOG_BEGIN
CHANGELOG_END
This is the macOS part of #5912, which I have separated because our
macOS nodes have a different deployment process so it seemed easier to
track the deployment of the change separately.
CHANGELOG_BEGIN
CHANGELOG_END
Azure used to report the status of the entire build to GitHub, which we
use as the "required check" for PRs to be merged. Ir doesn't do that
anymore which means we can't merge anything. It's unclear whether or not
that is a deliberate change.
This attempts to work around that by creating an extra job that depends
on all the other, which GitHub could depend on.
CHANGELOG_BEGIN
CHANGELOG_END
The message is built from the current commit message. Since this checks
out master, the Slack message ends up being a bit confusing.
CHANGELOG_BEGIN
CHANGELOG_END
PR #7732 illustrated a bug in our current changelog check: it only worked
if the PR was up-to-date with `master` at the time of pushing. This was
not the intention. Fortunately, the fix is fairly easy: check out the PR
commit before running the check, rather than run it from the merge
commit (as Azure does by default).
CHANGELOG_BEGIN
CHANGELOG_END
This PR extends the existing `save_gcp_data` function to handle any
`gsutil` command. This is done to support existence checking using
`gsutil ls` for private artifacts in release checking (`ci/cron`).
CHANGELOG_BEGIN
CHANGELOG_END
