Set up release pipeline

[cornelius]

Set up pipeline to continuously create release artifacts (e.g. nightly) so that issues are detected early, the turnaround time on all kind of releases is short, and there is no fragility or bottlenecks introduced by manual steps.

We should start with a simple release pipeline and add other things such as signing, reproducible builds, more hardware platforms when this is running. We also need to decide on what is mandatory to have for a first release and what can be added with subsequent releases.

[scravy]

Related: #32

Duplicating my comment from over there here:

---

• the extended tests are run daily (there's a travis CRON defined for that)
• two of these extended tests are excluded even from running daily though, and we should find a way to run them regularly or maybe even on PRs or at least merge commits or something like that
  • feature_pruning
  • feature_dbcrash
• PRs do not build release executables. This is a pitty, bitcoin for instance shipped 0.17 and the macos disk image was actually damaged as there was no automation checking that.
• In bitcoin they have a "need gitian build" and then I am not sure how it works. Various contributors actually have added tooling that performs regular gitian builds, such as @jonasschnelli – https://bitcoin.jonasschnelli.ch/
• I have a PR pending on bitcoin to run the functional tests on osx (travis: WIP - build and run tests on os: osx bitcoin/bitcoin#13816), and as soon as I get around to applying it to unit-e we should have this run by default as part of the CI
• Travis recently announced support for Windows, we should include such a build too (bitcoin uses appveyor for this - ci: Add Appveyor CI bitcoin/bitcoin#13964)
• Code Coverage is not checked/enforced/reported (I believe there is some tool by some core contributor on some website somewhere)

[cornelius]

There is a project to track the details: https://github.com/dtr-org/unit-e/projects/2

[cornelius]

This issue covers several high-level areas:

Building releases. We won't do that with a classical release pipeline but with a distributed approach using reproducible builds in a similar way as upstream Bitcoin Core is doing it. The base for that is the gitian build system. That is working with unit-e now (dtr-org/unit-e#466). It needs still to be tested with a real release. Fine-grained tasks are on the Build & CI board.

CI and testing releases. There needs to be automated testing to make sure we don't accidentally break releases during development. This overlaps with the regular CI for the project. Fine-grained tasks are on the Build & CI board.

Release process. The release process needs to be defined and tested in detail so that we have a repeatable procedure to do releases without too much hassle. This will naturally come when we start doing releases. The first release will need some extra testing and setup work (see dtr-org/unit-e#735).

Content of releases. Deciding about scope of releases and what goes in which release is handled via GitHub milestones. This allows fine-grained planning and makes it transparent what is expected from which release.

Most of the work needed to set up a release pipeline is done and the remaining work is well-covered by more specific issues and boards. So I think this issue has served its purpose and I'm closing it now.