mirror of
https://github.com/digital-asset/daml.git
synced 2024-09-17 15:57:21 +03:00
The Daml smart contract language
bazeldamldistributed-ledgerdltprivacy-by-designsdksmart-contractstarred-digital-asset-repostarred-repoworkflow-automation
7c83265ef9
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. |
||
|---|---|---|
| .github | ||
| ci | ||
| sdk | ||
| .gitattributes | ||
| .gitignore | ||
| azure-cron.yml | ||
| azure-pipelines.yml | ||
| CODE_OF_CONDUCT.md | ||
| CODEOWNERS | ||
| CONTRIBUTING.md | ||
| SECURITY.md | ||