With the current setup, we always push whatever version GitHub considers
as the latest, which is defined by date. This means that at the moment a
patch release could overwrite a less recent but higher-version release,
essentially downgrading the SDK to a previous, presumably less good user
experience.
This patches the upload process to choose the highest-numbered release
instead of the most recent one by date.
CHANGELOG_BEGIN
CHANGELOG_END
* Publish docker images for snapshot releases as well
We got a couple of requests for this and given the current release
process this seems very reasonable. Snapshot releases are clearly
marked as such so I think there this is fine.
We could think about differentiating between a stable release version
marked as a prerelease and not publish the docker image for that but
given our current release process where the stable version is based on
an already existing snapshot and therefore testing is very unlikely to
fail when we mark it as stable, that doesn’t seem worth the complexity
here.
changelog_begin
changelog_end
* Update azure-cron.yml
Co-Authored-By: Samir Talwar <samir.talwar@digitalasset.com>
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
One of the outputs of our brainstorming about how to make CI better was
that it is annoying to have to "babysit" pull requests. This PR attempts
to introduce a notification mechanism by which Azure will notify people
on Slack when a build finishes, so they know they need to go and rerun
or merge the corresponding PR.
This commit also changes the existing $Slack.URL variable to
$Slack.team-daml, to make more explicit where the Slack message is being
sent to (Slack works with one token per destination channel). Both
$Slack.URL and $Slack.team-daml are currently defined as the same token
in Azure.
CHANGELOG_BEGIN
CHANGELOG_END
Currently, when cron jobs fail, this is completely silent. After #4178,
in which we realized the VSCode extension had not been updated for about
a month, I believe it may be a good idea to get error messages sent to
Slack when a cron job fails.
We'll need to monitor for verbosity, but hopefully they will work most
of the time.
CHANGELOG_BEGIN
CHANGELOG_END
This has changed in 0a26591849 which
broke the build. We only build the latest release so changing this
should be safe and not break older releases.
changelog_begin
changelog_end
changelog_begin
- [DAML SDK] Docker images for this release and releases in the future
are built using the Dockerfile of the corresponding git tag and are
therefore stable. Previously, they were updated whenever the
Dockerfile changed.
changelog_end
This commit aims at mitigating two issues we have noticed with the
0.13.41 release:
1. The initial cron run for that release got interrupted at the 50
minutes mark, which happened to be right in the middle of the s3 upload.
This means it had already changed the versions.json file, but had not
finished updating the actual html files. Right now, the docs.daml.com
website shows version 0.13.41 in the drop-down, but actually displays
the content for 0.13.40. Additionally, trying to explicitly visit the
website for 0.13.41 (https://docs.daml.com/0.13.41) yields a 404. Note
that this also means the cron job did not reach the "tell HubSpot"
point, so 0.13.41 did not get announced.
2. As the script also did not reach the "clear cache" step, subsequent
runs have been rebuilding the documentation for no reason as the
sequence of steps was: check versions.json through HTTP, get cached one,
see it's not up-to-date, build docs, check versions.json through s3 API,
bypassing the cache, see it's up-to-date, stop.
To address those issues, this PR changes the cron to:
1. Increase the timeout to 2h instead of 50 minutes.
2. Always check the versions.json file through s3, rather than go
through the HTTP cache first.
These are not complete solutions but I'm not sure how to do better given
that s3 does not have atomic operations.
* webide: build webide image when sdk releases
* add scripts which check the latest version of sdk. If webide docker
image version does not exist or is older than the sdk version, it will
kick off a build of the webide docker image
* add job to azure cron
* webide: minor response to review
There is no simple way to configure GCS to serve the desired security
headers, so instead the script will keep updating the existing s3
bucket.
Consequent changes:
- Add aws cli tool to dev-env
- Remove docs bucket from Terraform
- Set reasonable timeout. We want this to run once per hour, so it
should never run for longer than that.
- Fix gcp deploy command to target the right directory. That somehow got
lost in the manual changes between the PR and what I was manually
running on CI.
- Keep the not-found page intact, so as to not break 404 responses.
- Retry up to ten times to install nix packages, for each version. Nix
package download can be a bit flaky, especially when we download large
collections of packages (e.g. texlive), and Bazel is very unforgiving
towards flaky nix downloads so instead we now preload all the packages
before invokin Bazel.
