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
Right now our artifacts are only stored on GitHub. Should they have any
issue, we're toast, as we can't always rebuild old artifacts. With this
change, we also store our artifacts on a GCS bucket, so we'd need both
GitHub and Google to have simultaneous issues to lose data.
CHANGELOG_BEGIN
CHANGELOG_END
* Remove reference to release-notes.rst
https://github.com/digital-asset/daml/pull/7458 shuffled this
around. While we could update it, it doesn’t really make any sense. We
post our release notes to the blog now and not in the docs so this
whole checkout procedure is redundant. This is also true if we wanted
to make a bugfix release for a release < 1.5 where this file still
existed. The trigger_sha is always on master (following our current
release process) so the file would still not exist.
I did also remove it from the docs cronjob. We never reupload old docs
so this doesn’t make a difference.
changelog_begin
changelog_end
* Stupid whitespace change because windows is pissing me off
changelog_begin
changelog_end
I have created the corresponding user and repositories on Artifactory,
and tested the `curl` command manually. I'll add the corresponding
credentials to Azure once this is approved.
CHANGELOG_BEGIN
CHANGELOG_END
Because the build for the automated release PR is triggered "manually"
by the Azure cron (through the GH API), as far as the build of that PR
is concerned, this is a random commit build, not a PR build, and thus it
doesn't have a PR number.
This works around that by getting the corresponding PR number from the
GH API.
CHANGELOG_BEGIN
CHANGELOG_END
On the last release, the job succeeded despite no being able to create
the compat PR. This fixes:
- The curl call to actually return non-0 on non-2xx HTTP response.
- The way in which we encode the credentials.
This also attempts to create a Bash library, hopefully this time in a
way that doesn't get destroyed by our release process. IIUC pipeline
instructions (YAML files) are all parsed and read before any execution,
so by embedding the Bash library in a template we should get the correct
version (i.e. the one that is running the pipeline) even when checking
out other commits.
CHANGELOG_BEGIN
CHANGELOG_END
At the moment, the release PR notification piggybacks on the existing PR
notifications. Unfortunately, that does not work, because those
explicitly only trigger for "pr" builds, whereas the release PR gets a
"manual" build, as it is opened by Azure and thus does not run
automatically.
CHANGELOG_BEGIN
CHANGELOG_END
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
This is running on Azure’s agents and we just call curl so there is
really no need for dev-env (as evidenced by the fact that the message
got sent despite dev-env failing).
changelog_begin
changelog_end
Based on feedback from @nickchapman-da, this PR aims at making the
release process easier by:
- Automatically opening a release PR on Wednesday morning. The goal here
is that by the time we start working, there is a release already
built, so we save about an hour on waiting for that. This obviously
doesn't help with ad-hoc releases.
- On a release PR build, posting to Slack when the release is ready to
merge.
- On a release master build, posting to Slack when a release is ready to
be tested.
My hope is that this makes the release process less tedious. This is not
trying to address the actual release testing, but hopefully should
reduce the annoyance of having to constantly go and check if the release
is ready.
CHANGELOG_BEGIN
CHANGELOG_END
While closely following the 1.3 release through our pipeline to check
that #6709 worked as expected, I realized that the automatically-created
PR does not start the normal tests either, presumably because it's been
opened by a bot. The bot doe shave write access to the repo (obviously,
as it can create the PR in the first place), but somehow that doesn't
seem to count as a PR with write access for Azure.
So this PR adds the normal test run too, so we don't need to manually
say `/azp run` on the PR.
CHANGELOG_BEGIN
CHANGELOG_END
