Currently, the Source for an Enterprise Dapp is written once on Dapp creation and never again. We need a mechanism to run builds with new versions of Dappsmith and push them to users.
We won't be able to push to master because they may have made changes that can't auto-merge. We'll need to push to another branch and let them merge it in. It's an open question whether we want a single branch with HEAD at the latest version (e.g. dappsmith-updates), or a branch per release (e.g. dappsmith@v1.0)
Some things we need to deal with:
Some users may pull our permissions. Ideally we can still get them missed updates later if they give it back to us.
If we make the source pipelines ephemeral (#35) we run the risk that pushing updates out to everyone at the same time puts us over our pipeline limit. (Maybe use an SQS queue and a message per update to push)
The lambda that does the commit will need to be aware of whether it is an initial source deploy or not. Initial builds commit to master, future builds commit to an update branch
Currently, the Source for an Enterprise Dapp is written once on Dapp creation and never again. We need a mechanism to run builds with new versions of Dappsmith and push them to users.
We won't be able to push to
masterbecause they may have made changes that can't auto-merge. We'll need to push to another branch and let them merge it in. It's an open question whether we want a single branch with HEAD at the latest version (e.g.dappsmith-updates), or a branch per release (e.g.dappsmith@v1.0)Some things we need to deal with:
master, future builds commit to anupdatebranch