Weekly Update 2 - Simulating an update cycle for local testing

GSoC Projects Seamless Updates
, ,
1

Since I did not publish week 2 yet, so I will publish it now. (better late than never :sweat_smile:)

Progress

Before starting to implement the auto-updating service, it is important to understand how the current process works and get familiar with the code. I have asked myself some questions to help me understand better how Joplin handles updates.

How can you trigger an update?

  1. It is possible to trigger a manual update if you go to Help > Check for updates.
  2. The application periodically checks for new versions of the application. The function responsible for this is scheduled to run on startup and then repeatedly every 12 hours.

From where are the updates taken from?

The list of latest release is fetched from the remote server https://objects.joplinusercontent.com/r/releases

The application then processes this list to determine the most relevant release for the current platform and configuration. This process involves selecting the most suitable update for the user’s computer—whether it’s a Windows, Mac, or Linux system. It also checks if the user prefers stable versions or is okay with the latest features in pre-releases.

What happens when you trigger an update ?

If a newer version than the currently installed one is available, the application notifies the user through a dialog box with details about the update. The user is given options to download the new version, skip this version (which won't notify the user about the same version again), view the full changelog, or cancel the update.

If the user chooses to download the update, the application opens an external link where the user can download the new version. The app also performs a safety check to get the user’s consent for downloading the update.


After answering these questions, I wanted to make sure that I can test on my local environment the service I am about to implement. I have noticed that there is a test written, but I wanted to test this feature while I was in the app. How can I test the process of updating? Let’s say that an update consists of changing some text (for example, from “Notebooks” to “Notebooks Update!”).

Solution: To test the changes and to observe them through the update mechanism, I need to simulate an update cycle. This involves creating two versions of the application: one current (older) version and one new (updated) version with the changes I want to test. This is how I have done it:

  1. I checked the current version from app-desktop/package.json, which was 3.0.8
  2. I modified the text from “Notebooks” to “Notebooks Update!”
  3. Inside app-desktop/package.json, I changed the version from 3.0.8 to 3.1
  4. I opened a terminal and ran the command yarn dist inside app-desktop. This command will execute yarn electronRebuild and npx electron-builder, which should compile the application and package it into an executable (.exe) for Windows
  5. I have created a releases.json file (that provides the details about the release) inside the dist folder (doesn’t really matter the location as long as both the executable and the file are in the same location) . The contents of the file will be presented below.
  6. I installed python to set up local hosting. I started the server in the dist directory with the command python -m http.server 8080
  7. In code, I replaced https://objects.joplinusercontent.com/r/releases with http://localhost:8080/releases.json … then I changed the version back to the old one and deleted the modifications of the text.
  8. I ran the app and triggered a manual update. I will attach a screen recording.

Now that I can locally test the manual updates, the automatic updates will be tested in almost the same way.

Plans

For Week 3, my objective is to implement automatic detected updates. The focus will be more on “making it work”, not on the user experience or well structured code.

Problems

  • I had this error: [Error: EPERM: operation not permitted, unlink 'D:\joplin\packages\app-desktop\node_modules\keytar\build\Release\keytar.node’ … usually this happens with VSC, but I solved it eventually . Fortunately this was solved easier by closing VSC and every terminal, opening cmd as administrator, and running yarn dist again.
  • When installing python, I had to open ”App execution aliases” menu and to turn off for python
2

Thanks for the update. Another way to test auto-updates is to edit the file checkForUpdates.ts and modifying the packageInfo.version value to an older version. That will allow you to test while running in development mode.

1 Like