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