WIP: Add Continuous Delivery #145
Conversation
Do not publish when running pack. Seperate build from package.
publish.yml currently builds the package, then packages it on tags, creates a pre-release if the tag contains rc or beta, else creates a release, uploads the deb, AppImage, rpm to the release.
|
The failing CI seems to be unrelated. |
|
This is really cool! Thanks for putting it together! You are right that the CI build on macOS has been causing quite some issues, as a matter of fact I am now going to disable it until we find why it's not working well (see: ooni/probe#1157). I don't know so much about linux app distribution, so maybe @FedericoCeratto or @sarathms can look at that part and see if it makes sense to integrate this. WRT the macOS and windows builds, the challenge with doing CD on those is that we would have to give our code signing keys to github, which I think we should first carefully discuss and evaluate the tradeoffs of that approach. That said, maybe we can just have unsigned developer builds made using this process and keep the "standard" process for signed builds. This PR relevant to: ooni/probe#1091. |
|
I actually raised the concern about the need of signing keys to be uploaded to github in the IRC. On top of that, Github does not have any mechanism for uploading secret files into the build. Github's recommended approach is committing an encrypted version of the key to repo and then adding the password to it as a secret. Source. |
There was a problem hiding this comment.
@Ceda-EI Thanks for working on this (and apologies for the late response)
- One of the important features we wanted to ensure was the ability to update the app with as little friction as possible. The currently supported Mac and Windows apps make use of electron's auto-update to update silently without user intervention.
- For this to work, the release should include the
latest-linux.ymlfile found in the same directory (./dist/) - For Linux, this is auto-update mechanism only works with the
AppImagebuilds. So, when we start supporting Linux, we should start uploading the*.AppImagefile and thelatest-linux.ymlas release assets. - For
debandrpmpackages, we believe Github Releases is not an appropriate distribution channel because it affects upgradability as mentioned earlier. Instead, we intend to maintain repositories on bintray. We could modify theUpload DebandUpload RPMsteps in this workflow to upload to bintray repos (or use other actions). Butelectron-buildernatively supports uploading to bintray (also github and a bunch of others) and maybe we can avoid doing the same thing in the workflow here.
We haven't converged on how we want to handle the codesigning part of the process. We have this topic in the agenda for an upcoming meeting this week in which we should be able to decide how we want to handle this in the long term. Although there are alternative ideas to convert his PR into something that addresses ooni/probe#1091, I think it is best to wait and proceed once we have some more clarity.
| @@ -29,6 +29,7 @@ | |||
| "appId": "org.ooni.probe-desktop", | |||
| "productName": "OONI Probe", | |||
| "asar": true, | |||
| "artifactName": "${productName}.${ext}", | |||
There was a problem hiding this comment.
It is useful to have the version number in filename.
Example builds were run on the test-ci branch of my fork.