Set up continuous deployment

[gavinhenderson]

Ideally we would have a github action that can be triggered and will create a new release on github with an installer. We (Ace Centre) can then sign those installers, although that has to be done manually as we have to use a physical key in the process.

We also want it to be easier for users to update. It doesn't have to be automatic but they should be able to update to the latest version easily.

This maybe already works but it just needs checked

[sjjhsjjh]

Note for later is that some software that could be used is this. https://github.com/dennisvang/tufup

[willwade]

@sjjhsjjh check out the workflow at https://github.com/AceCentre/FaceCommander/blob/main/.github/workflows/windows-build-release.yml - basically it builds the whole thing and installer. I think we should ditch the portable - I didnt really test that and if Im honest I think it will break because of the filepaths that I put it to local for it in your LOCALAPPDATA type dirs.

But its largely there. But yeah - tufup looks good. I looked into that.

[sjjhsjjh]

Thanks Will, Should we decommission the portable piece as part of this work, Issue #7, then?

[willwade]

My gut feeling is to say yes to that. Having effectively two builds - or two build steps is a bit of a hassle.

[sjjhsjjh]

Thanks Will, I looked at the yaml and can see that it builds the executable and installer. It's triggered by pushing a tag with a particular format.
I don't see how to fit in the signed installer piece that @gavinhenderson mentioned.

[willwade]

Ahh you don't

• Basically let GH Build and release (and maybe mark as preview)
• Someone in our office has to then grab the installer exe
• Sign it
• Then reupload (and we manually take off the preview).

Our signing process is a bit of a pain as we have a physical key that needs to sign it.

[sjjhsjjh]

Hi, I had a bit of a think and reckon these are the required pieces.

• For Ace Centre as the app developer.
  • Workflow to create one or more unsigned installers when a tag with a particular format is pushed, which is already done.
• For the end user.
  • Indicator in the app that will highlight the availability of a new release.
    • It could appear as a new menu item for example, only if there is a new release available.
    • Only new signed releases are in scope of the indicator.
  • Option to download the latest signed installer within the app.
  • Option to run a downloaded installer within the app.
  • Facilitate opening the releases page in the browser.
    • Releases page is here https://github.com/AceCentre/FaceCommander/releases It's empty at the moment but see the Grimassist page for an idea of what it looks like with some releases https://github.com/acidcoke/Grimassist/releases

On balance I don't think we need to implement any integrity checking. We can rely on the operating system and signing to do that.
The highlight-download-run pieces represent the most common use case, which is to install a new release of the app. The releases page piece supports less common use cases such as these.

• Beta or early access programme.
• End user wants to install an old version.
• End user wants control of where the files get downloaded.
• End user wants to have multiple versions installed.

What do you think?

[willwade]

Yeah. I was having a good look at tufup. It’s pretty decent but you do look like you have to do a bunch of work on the repo handling / server side. Although I could be wrong. I’ve only skim read this (/ had a go at converting their power shell script for Mac dennisvang/tufup-example#26 (comment) ) see https://github.com/dennisvang/tufup-example/tree/master/src
And this for the init scripts etc.
https://github.com/dennisvang/tufup-example/tree/master

this is where electron is better.

Your idea seems sound to me Jim. The one downside is it won’t force updates - but then
Our users are used to this approach in grid etc . @gavinhenderson ?

[willwade]

One last idea is beeware.. Its pretty decent although not that common. Take a look at https://docs.beeware.org/en/latest/tutorial/tutorial-4.html for autoupdating. Builds on Multiplatform too - not thats our angle right now. It also packages as a MSI which is often more desirable for sysadmins etc..

see also https://briefcase.readthedocs.io/en/stable/how-to/index.html

[sjjhsjjh]

Thanks Will, Having multiple types of installer seems to be quite common. So if MSI will support some use cases that .exe doesn't then I don't see a problem.
I'm unsure about forcing upgrade. It's OK if FaceCommander remains usable while the upgrade is in progress. Otherwise I think users need to control when the upgrade happens.

[gavinhenderson]

@sjjhsjjh

I really like that approach! It moves a lot of the hard work out of the app while keeping the user experience really smooth. I also like that as you highlight its it will still support the other less common user journeys.

I say go for it! :)

[sjjhsjjh]

Okey dokey
I might build some test releases just to have something to work with if that's OK?

[sjjhsjjh]

Hi, Here's an interim update for today.

• The version number now has a single source in a file here.
  https://github.com/AceCentre/FaceCommander/blob/v0.6.2.test_1/assets/Version.ini
  • That source is used every component that needs a version number, the installer builder, the GitHub Releases section, and the app UI.
• There's a new build workflow here.
  https://github.com/AceCentre/FaceCommander/blob/v0.6.2.test_1/.github/workflows/windows-build-version.yml
  • It's substantially a copy of the previous workflow.
  • It's triggered by pushing to the version file.
  • It adds the GitHub tag programmatically.
  • The release is flagged as a prerelease to facilitate the signing and upload.

At CoP the new build is working. I have tested the .exe installer. Sorry, I had to do a lot of commits to try things out in the workflow.

[willwade]

Never apologise about the number of commits. You want to see the number of commits (and timespan) I have on some of these GH workflows. Nice one Jim

[sjjhsjjh]

Note to self.
https://docs.github.com/en/rest/releases/releases?apiVersion=2022-11-28#list-releases-for-a-repository

[gavinhenderson]

This is brilliant work @sjjhsjjh!

Its probably already on your radar but it would be good to have the process documented briefly in the README. Mainly thinking about myself coming to this project in a few years and needing to remember how to do a release 🤦‍♂️

[sjjhsjjh]

Hi, Here's another interim update.

• I'm adding an UpdateManager singleton.
• So far, it can launch a thread to get release details from the GitHub API.
• The GitHub API looks simple enough but I ran into difficulty downloading an asset, i.e. an installer. The GitHub API redirected a couple of times and then threw an HTTP 400. I don't know why.
• I just had a quick go using the Requests library, see https://docs.python-requests.org/en/latest/api/ , instead of the Python built-in HTTP client. That worked first time downloading an asset.

So I'll be adopting that library into FaceCommander in due course maybe tomorrow.
After that my plan is to add some Tk variables to the UpdateManager. That seems to be the correct way to have an observable state that can be updated from a download thread and then reflected in the UI.

[gavinhenderson]

Awesome work @sjjhsjjh !

We are going to have one of the best update experiences around!

[sjjhsjjh]

At close of play I have proof-of-concept code pushed for

• download an installer exe from GitHub.
• launch the installer from the main app.
• the installer remains open when the main FaceCommander app terminates.
• observable status message.

[sjjhsjjh]

So, bit of a hiccough encountered today.
The observable status message is true but isn't multi-threaded. Specifically, a tkinter.StringVar or IntVar cannot be set from a thread other than the main thread that runs the UI. That seems to mean the app will need to poll the UpdateManager singleton's state from the tk mainloop.
One place there's already some polling is in the MainApp declared in the face_commander.py file. I can add UpdateManager polling there, unless there's some reason not to or a better place?

[sjjhsjjh]

Hi, Update for today is that this branch now has these features.

• Last release check time displayed on the About page.
• About page display updates when releases information is checked, which happens on a thread.
• Elective check-now option, also in the About page.
• Diagnostic CLI switch to slow releases information retrieval, for testing the above.

Remaining pieces are as follows.

• About page displays installer download progress and option to launch a downloaded installer.
• Evocative description of the last update check time, like "2 minutes ago".
• Display published time for the current running release.
• Block preview releases.
• Add another release or two for testing.

[sjjhsjjh]

Hi, These pieces are now done on the branch.

• About page displays installer download progress and option to launch a downloaded installer.
• Display published time for the current running release.
• Block prereleases, and there's a command line switch to override that.
• Added another prerelease for testing.

This piece isn't done.

• Evocative description of the last update check time, like "2 minutes ago".

Also to-do is the developer documentation.

[sjjhsjjh]

Evocative descriptions are done.

[gavinhenderson]

Awesome work @sjjhsjjh !

I have created a PR from your branch so I can easily look over the code etc: #24

I'll have a quick play around and then merge into main unless I have any issues, which I doubt I will.

My plan this week is to try and get a handle on the admin stuff then once we have all that done we can start getting users onto it and then we can just iterate from there (thanks to your updating mechanism)

[sjjhsjjh]

Thanks Gavin, I'm not sure myself that it's ready but I recorded a video here.
https://youtu.be/dyTzdQpYpmM?si=XTnxKcCubCJHFC2a

If that all looks ok I'll write the developer documentation.

[sjjhsjjh]

Thanks Gavin, I'm not sure myself that it's ready but I recorded a video here.
https://youtu.be/dyTzdQpYpmM?si=XTnxKcCubCJHFC2a

If that all looks ok I'll write the developer documentation.

[willwade]

Wow. That's stellar Jim!