[desktop] Tinker with the release flow (#1652)
This commit is contained in:
Manav Rathi
GitHub
commit
1031801c66
|
|
@ -1,70 +0,0 @@
|
|||
name: "Draft release"
|
||||
|
||||
# Build the desktop/draft-release branch and update the existing draft release
|
||||
# with the resultant artifacts.
|
||||
#
|
||||
# This is meant for doing tests that require the app to be signed and packaged.
|
||||
# Such releases should not be published to end users.
|
||||
#
|
||||
# Workflow:
|
||||
#
|
||||
# 1. Push your changes to the "desktop/draft-release" branch on
|
||||
# https://github.com/ente-io/ente.
|
||||
#
|
||||
# 2. Create a draft release with tag equal to the version in the `package.json`.
|
||||
#
|
||||
# 3. Trigger this workflow. You can trigger it multiple times, each time it'll
|
||||
# just update the artifacts attached to the same draft.
|
||||
#
|
||||
# 4. Once testing is done delete the draft.
|
||||
|
||||
on:
|
||||
# Trigger manually or `gh workflow run desktop-draft-release.yml`.
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
release:
|
||||
runs-on: macos-latest
|
||||
|
||||
defaults:
|
||||
run:
|
||||
working-directory: desktop
|
||||
|
||||
steps:
|
||||
- name: Checkout code
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
repository: ente-io/ente
|
||||
ref: desktop/draft-release
|
||||
submodules: recursive
|
||||
|
||||
- name: Setup node
|
||||
uses: actions/setup-node@v4
|
||||
with:
|
||||
node-version: 20
|
||||
|
||||
- name: Install dependencies
|
||||
run: yarn install
|
||||
|
||||
- name: Build
|
||||
uses: ente-io/action-electron-builder@v1.0.0
|
||||
with:
|
||||
package_root: desktop
|
||||
|
||||
# GitHub token, automatically provided to the action
|
||||
# (No need to define this secret in the repo settings)
|
||||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
# If the commit is tagged with a version (e.g. "v1.0.0"),
|
||||
# release the app after building.
|
||||
release: ${{ startsWith(github.ref, 'refs/tags/v') }}
|
||||
|
||||
mac_certs: ${{ secrets.MAC_CERTS }}
|
||||
mac_certs_password: ${{ secrets.MAC_CERTS_PASSWORD }}
|
||||
env:
|
||||
# macOS notarization credentials key details
|
||||
APPLE_ID: ${{ secrets.APPLE_ID }}
|
||||
APPLE_APP_SPECIFIC_PASSWORD:
|
||||
${{ secrets.APPLE_APP_SPECIFIC_PASSWORD }}
|
||||
APPLE_TEAM_ID: ${{ secrets.APPLE_TEAM_ID }}
|
||||
USE_HARD_LINKS: false
|
||||
25
desktop/.github/workflows/desktop-release.yml
vendored
25
desktop/.github/workflows/desktop-release.yml
vendored
|
|
@ -1,20 +1,12 @@
|
|||
name: "Release"
|
||||
|
||||
# This will create a new draft release with public artifacts.
|
||||
# Build the ente-io/ente's desktop/rc branch and create/update a draft release.
|
||||
#
|
||||
# Note that a release will only get created if there is an associated tag
|
||||
# (GitHub releases need a corresponding tag).
|
||||
#
|
||||
# The canonical source for this action is in the repository where we keep the
|
||||
# source code for the Ente Photos desktop app: https://github.com/ente-io/ente
|
||||
#
|
||||
# However, it actually lives and runs in the repository that we use for making
|
||||
# releases: https://github.com/ente-io/photos-desktop
|
||||
#
|
||||
# We need two repositories because Electron updater currently doesn't work well
|
||||
# with monorepos. For more details, see `docs/release.md`.
|
||||
# For more details, see `docs/release.md` in ente-io/ente.
|
||||
|
||||
on:
|
||||
# Trigger manually or `gh workflow run desktop-release.yml`.
|
||||
workflow_dispatch:
|
||||
push:
|
||||
# Run when a tag matching the pattern "v*"" is pushed.
|
||||
#
|
||||
|
|
@ -38,11 +30,9 @@ jobs:
|
|||
- name: Checkout code
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
# Checkout the tag photosd-v1.x.x from the source code
|
||||
# repository when we're invoked for tag v1.x.x on the releases
|
||||
# repository.
|
||||
# Checkout the desktop/rc branch from the source repository.
|
||||
repository: ente-io/ente
|
||||
ref: photosd-${{ github.ref_name }}
|
||||
ref: desktop/rc
|
||||
submodules: recursive
|
||||
|
||||
- name: Setup node
|
||||
|
|
@ -69,7 +59,8 @@ jobs:
|
|||
github_token: ${{ secrets.GITHUB_TOKEN }}
|
||||
|
||||
# If the commit is tagged with a version (e.g. "v1.0.0"),
|
||||
# release the app after building.
|
||||
# create a (draft) release after building. Otherwise upload
|
||||
# assets to the existing draft named after the version.
|
||||
release: ${{ startsWith(github.ref, 'refs/tags/v') }}
|
||||
|
||||
mac_certs: ${{ secrets.MAC_CERTS }}
|
||||
|
|
|
|||
|
|
@ -1,46 +1,65 @@
|
|||
## Releases
|
||||
|
||||
Conceptually, the release is straightforward: We push a tag, a GitHub workflow
|
||||
gets triggered that creates a draft release with artifacts built from that tag.
|
||||
We then publish that release. The download links on our website, and existing
|
||||
apps already know how to check for the latest GitHub release and update
|
||||
accordingly.
|
||||
Conceptually, the release is straightforward: We trigger a GitHub workflow that
|
||||
creates a draft release with artifacts built. When ready, we publish that
|
||||
release. The download links on our website, and existing apps already check the
|
||||
latest GitHub release and update accordingly.
|
||||
|
||||
The complication comes by the fact that Electron Updater (the mechanism that we
|
||||
use for auto updates) doesn't work well with monorepos. So we need to keep a
|
||||
separate (non-mono) repository just for doing releases.
|
||||
The complication comes by the fact that electron-builder's auto updaterr (the
|
||||
mechanism that we use for auto updates) doesn't work with monorepos. So we need
|
||||
to keep a separate (non-mono) repository just for doing releases.
|
||||
|
||||
- Source code lives here, in [ente-io/ente](https://github.com/ente-io/ente).
|
||||
|
||||
- Releases are done from
|
||||
[ente-io/photos-desktop](https://github.com/ente-io/photos-desktop).
|
||||
|
||||
## Workflow
|
||||
## Workflow - Release Candidates
|
||||
|
||||
The workflow is:
|
||||
Leading up to the release, we can make one or more draft releases that are not
|
||||
intended to be published, but serve as test release candidates.
|
||||
|
||||
1. Finalize the changes in the source repo.
|
||||
The workflow for making such "rc" builds is:
|
||||
|
||||
- Update the CHANGELOG.
|
||||
- Update the version in `package.json`
|
||||
- `git commit -m "[photosd] Release v1.2.3"`
|
||||
- Open PR, merge into main.
|
||||
1. Update `package.json` in the source repo to use version `1.x.x-rc`. Create a
|
||||
new draft release in the release repo with tag `v1.x.x-rc`.
|
||||
|
||||
2. Tag the merge commit with a tag matching the pattern `photosd-v1.2.3`, where
|
||||
`1.2.3` is the version in `package.json`
|
||||
2. Push code to the `desktop/rc` branch in the source repo.
|
||||
|
||||
3. Trigger the GitHub action in the release repo
|
||||
|
||||
```sh
|
||||
git tag photosd-v1.x.x
|
||||
git push origin photosd-v1.x.x
|
||||
gh workflow run desktop-release.yml
|
||||
```
|
||||
|
||||
3. Head over to the releases repository and run the trigger script, passing it
|
||||
the tag _without_ the `photosd-` prefix.
|
||||
We can do steps 2 and 3 multiple times; each time it'll just update the
|
||||
artifacts attached to the same draft.
|
||||
|
||||
## Workflow - Release
|
||||
|
||||
1. Update `package.json` in the source repo to use version `1.x.x`. Create a
|
||||
new draft release in the release repo with tag `v1.x.x`.
|
||||
|
||||
2. Push code to the `desktop/rc` branch in the source repo. Remember to update
|
||||
update the CHANGELOG.
|
||||
|
||||
3. In the release repo
|
||||
|
||||
```sh
|
||||
./.github/trigger-release.sh v1.x.x
|
||||
```
|
||||
|
||||
4. If the build is successful, tag `desktop/rc` and merge it into main:
|
||||
|
||||
```sh
|
||||
# Assuming we're on desktop/rc that just got build
|
||||
|
||||
git tag photosd-v1.x.x
|
||||
git push origin photosd-v1.x.x
|
||||
|
||||
# Now open a PR to merge it into main
|
||||
```
|
||||
|
||||
## Post build
|
||||
|
||||
The GitHub Action runs on Windows, Linux and macOS. It produces the artifacts
|
||||
|
|
|
|||
|
|
@ -16,16 +16,19 @@ export const setupAutoUpdater = (mainWindow: BrowserWindow) => {
|
|||
* [Note: Testing auto updates]
|
||||
*
|
||||
* By default, we skip checking for updates automatically in dev builds.
|
||||
* This is because even if we were to find an update, installing it would
|
||||
* fail because (at least on macOS), the auto update process requires signed
|
||||
* builds.
|
||||
* This is because even if installing updates would fail (at least on macOS)
|
||||
* because auto updates only work for signed builds.
|
||||
*
|
||||
* So an end to end testing for updates requires using a temporary GitHub
|
||||
* repository and signed builds therein.
|
||||
* repository and signed builds therein. More on this later.
|
||||
*
|
||||
* Howvere for partial checks of the UI flow, something like tis can be used
|
||||
* to do a test of the update process (up until the actual installation
|
||||
* itself).
|
||||
* ---------------
|
||||
*
|
||||
* [Note: Testing auto updates - Sanity checks]
|
||||
*
|
||||
* However, for partial checks of the UI flow, something like the following
|
||||
* can be used to do a test of the update process (up until the actual
|
||||
* installation itself).
|
||||
*
|
||||
* Create a `app/dev-app-update.yml` with:
|
||||
*
|
||||
|
|
@ -39,20 +42,54 @@ export const setupAutoUpdater = (mainWindow: BrowserWindow) => {
|
|||
* In this directory, put `latest-mac.yml` and the DMG file that this YAML
|
||||
* file refers to.
|
||||
*
|
||||
* Alternatively, `dev-app-update.yml` can contain some arbitrary GitHub
|
||||
* repository, e.g.:
|
||||
* Alternatively, `dev-app-update.yml` can point to some arbitrary GitHub
|
||||
* repository too, e.g.:
|
||||
*
|
||||
* provider: github
|
||||
* owner: foo
|
||||
* repo: bar
|
||||
* owner: ente-io
|
||||
* repo: test-desktop-updates
|
||||
*
|
||||
* Finally, we can start the app to trigger the auto update. If we're in dev
|
||||
* mode, we can use the "Check for updates..." menu option to trigger the
|
||||
* Now we can use the "Check for updates..." menu option to trigger the
|
||||
* update flow.
|
||||
*/
|
||||
autoUpdater.forceDevUpdateConfig = isDev;
|
||||
if (isDev) return;
|
||||
|
||||
/**
|
||||
* [Note: Testing auto updates - End to end checks]
|
||||
*
|
||||
* Since end-to-end update testing can only be done with signed builds, the
|
||||
* easiest way is to create temporary builds in a test repository.
|
||||
*
|
||||
* Let us say we have v2.0.0 about to go out. We have builds artifacts for
|
||||
* v2.0.0 also in some draft release in our normal release repository.
|
||||
*
|
||||
* Create a new test repository, say `ente-io/test-desktop-updates`. In this
|
||||
* repository, create a release v2.0.0, attaching the actual build
|
||||
* artifacts. Make this release the latest.
|
||||
*
|
||||
* Now we need to create a old signed build.
|
||||
*
|
||||
* First, modify `package.json` to put in a version number older than the
|
||||
* new version number that we want to test updating to, e.g. `v1.0.0-test`.
|
||||
*
|
||||
* Then uncomment the following block of code. This tells the auto updater
|
||||
* to use `ente-io/test-desktop-updates` to get updates.
|
||||
*
|
||||
* With these two changes (older version and setFeedURL), create a new
|
||||
* release signed build on CI. Install this build - it will check for
|
||||
* updates in the temporary feed URL that we set, and we'll be able to check
|
||||
* the full update flow.
|
||||
*/
|
||||
|
||||
/*
|
||||
autoUpdater.setFeedURL({
|
||||
provider: "github",
|
||||
owner: "ente-io",
|
||||
repo: "test-desktop-updates",
|
||||
});
|
||||
*/
|
||||
|
||||
const oneDay = 1 * 24 * 60 * 60 * 1000;
|
||||
setInterval(() => void checkForUpdatesAndNotify(mainWindow), oneDay);
|
||||
void checkForUpdatesAndNotify(mainWindow);
|
||||
|
|
|
|||
Loading…
Reference in a new issue