mirror of
https://github.com/digital-asset/daml.git
synced 2024-11-12 13:05:08 +03:00
dd4c6ba9ad
When we build a release, it is always a "past" commit - typically, one that has already been tested twice: once when the corresponding PR was run, and then again as a "main"-branch commit. Release branches don't run, but their protection rules enforce linear merges. Either way, we know we're building a _good_ commit, and, assuming our builds and tests are hermetic, testing that commit again when we make a release is a pure waste of time and CPU resources. The other case, where we make an ad-hoc release from a branch that has not been merged, has a similar issue: we do not necessarily want to run the full test suite, because part of the reason we need that commit may be that it doesn't succeed as is. Based on that observation, I wondered what might be the minimal set of things we actually need to build when making a release. This PR is an experiment in trying to find that out. |
||
|---|---|---|
| .. | ||
| cron | ||
| docker | ||
| assembly-split-release-artifacts.sh | ||
| bash-lib.yml | ||
| blackduck.yml | ||
| BUILD | ||
| build-unix.yml | ||
| build-windows.yml | ||
| build.yml | ||
| check-for-release-job.yml | ||
| clean-up.yml | ||
| clear-shared-segments-macos.yml | ||
| compatibility_ts_libs.yml | ||
| compatibility-windows.yml | ||
| compatibility.yml | ||
| configure-bazel.sh | ||
| copy-canton.sh | ||
| copy-unix-release-artifacts.sh | ||
| copy-windows-release-artifacts.sh | ||
| daily-snapshot.yml | ||
| dev-env-install.sh | ||
| job-variables.yml | ||
| macOS.yml | ||
| pgp_pubkey | ||
| prs.yml | ||
| publish-artifactory.sh | ||
| publish-platform-independence-dar.yml | ||
| refresh-canton.sh | ||
| refresh-get-daml-com.yml | ||
| report-end.yml | ||
| report-start.yml | ||
| slack_user_ids | ||
| split-release-job.yml | ||
| tell-slack-failed.yml | ||
| upload-bazel-metrics.yml | ||
| windows-diagnostics.ps1 | ||