mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-20 01:07:18 +03:00
df0086d26f
It does not seem like CI machines recover from a failed clean-up. This is not the most elegant solution possible, but it's a cheap one that should work. Not: shutting down the machine in the middle of the build will not provide an error message to Slack for main branch builds (because the `tell_slack_failed` step would need to run on the same machine) but will correctly report failure for PRs (that was the original purpose of the `collect_build_data` step). An alternative here would be to give a delay to the shutdown command, and try to calibrate it so that it's long enough for this job to correctly report its failure to both Azure and Slack, while making it short enough that no other job gets assigned to the machine. I'm not clear enough on how often Azure assigns jobs to try and bet on that. CHANGELOG_BEGIN CHANGELOG_END |
||
|---|---|---|
| .. | ||
| cron | ||
| da-ghc-lib | ||
| docker | ||
| patch_bazel_windows | ||
| bash-lib.yml | ||
| build-unix.yml | ||
| build-windows.yml | ||
| build.yml | ||
| check-changelog.sh | ||
| clean-up.yml | ||
| clear-shared-segments-macos.yml | ||
| compatibility_ts_libs.yml | ||
| compatibility-windows.yml | ||
| compatibility.yml | ||
| configure-bazel.sh | ||
| daily_tell_slack.yml | ||
| dev-env-install.sh | ||
| dev-env-push.py | ||
| postgresql.conf | ||
| prs.yml | ||
| report-end.yml | ||
| report-start.yml | ||
| slack_user_ids | ||
| tell-slack-failed.yml | ||
| windows-diagnostics.ps1 | ||