# Holochain Launcher CI/CD integration
###### tags: `launcher`, `release`

## Goals

* Launcher binary is attached to holochain releases on github
* ideally: release of launcher happens automatically

## Challenges

* launcher package includes multiple holochain versions
* launcher depends on the [rust holochain client](https://github.com/holochain/holochain-client-rust), which also needs to be upgraded to a new holochain version
* We should automate its releases as well

* launcher will soon integrate the devhub happ.
* devhub is spread across 5 repos
* devhub, being a happ, may break due to hdk changes in the new holochain release

* Updating to holochain versions when DNA/HDK remains the same: When can we move a set of hApps from one version of holochain to another, i.e. ones that only have bug-fixes and no breaking changes at the data layer, and maybe have breaking changes at the network level (when HDK is the same and DNA hash is the same)?
* We have to support some level of this, otherwise there are too many conductor instances?
* Turning off old conductor versions.

## idea

### loose coupling of launcher and devhub
* on startup, launcher discovers an appropriate version of the devhub webhapp
* appropriate here means a version that is compatible with one of the supported (integrated) holochain versions

* the build of the new launcher release would succeed. however failure could still happen at runtime if there's not compatible devhub version with any of the included holochain versions

#### questions
* do we want to fail the relase in case of no compatible devhub release available at release time?

---

## Taxonomy of updating:
- DNA hash changed
- Integrity-crate changes (Host/Guest interface, or actual feature)
- DNA hash not changed = Same HDK
- Non-integrity crate changes
- Fully automatable by new launcher version:
- bug fix, folder automatically renamable with no effect
- Requires manual intervention to update:
- bug fix, folder renamble manually with unknown connection effect, but no data problem
- data change but folder data contents migratable by some holochain core process (i.e. sql table format change, etc.)

## Re-Taxonomy w/ respect to app continuity
- **No change:** Apps running in prior release can run in this release unchanged
- [ ] hdi change
- [ ] hdk change (or host/guest interface change)
- [ ] holochain core structure changes
- [ ] holochain network changes
- **Must run system update:** Prior apps require no change, but an update script must be run for running apps (e.g. to databases or config format).
- [ ] hdi change
- [ ] hdk change (or host/guest interface change)
- [x] holochain core structure changes
- [ ] holochain network changes
- **Re-compile only:** Apps running in prior release must be recompiled but no changes to app code is required. (e.g. guest/host interface has changed)
- [ ] hdi change
- [x] hdk change (or host/guest interface change)
- [ ] holochain core structure changes
- [ ] holochain network changes
- **Re-compile & sys update:**
- [ ] hdi change **minor** change
- [x] hdk change (or host/guest interface change)
- [x] holochain core structure changes
- [ ] holochain network changes
- **Code-Modification:** You will need to change code in your app because of a breaking change to IDK
- [x] hdi change **major** change
- [ ] ? hdk change (or host/guest interface change)
- [ ] holochain core structure changes
- [ ] holochain network changes
-

---

The launcher should present a switchboard with the map:
HolochainVersion -> folder -> InstalledApps -> InstalledCells

## scratchpad

Launcher 0.4.0
- Holochain v0.0.132
- Devhub 0.0.1 compiled with hdk 0.0.127
- All the apps for hdk v0.0.127
- All the apps for hdk v0.0.128
- Holochain v0.0.133

Launcher -> Holochain
* admin websocket API
* holochain types crate

Launcher -> lair-keystore
* launches keystore directly

Launcher -> DevHub (soon)
* gets the devhub web-happ and installs it via the holochain admin API

DevHub -> Holochain
* Holochain HDK