[desktop] Resurrect build
Untested
This commit is contained in:
parent
85522a946a
commit
fa182b951d
72
.github/workflows/desktop-release.yml
vendored
Normal file
72
.github/workflows/desktop-release.yml
vendored
Normal file
|
@ -0,0 +1,72 @@
|
||||||
|
name: "Release (photos desktop)"
|
||||||
|
|
||||||
|
# This will create a new draft release with public artifacts.
|
||||||
|
#
|
||||||
|
# Note that a release will only get created if there is an associated tag
|
||||||
|
# (GitHub releases need a corresponding tag).
|
||||||
|
|
||||||
|
on:
|
||||||
|
workflow_dispatch: # Allow manually running the action
|
||||||
|
push:
|
||||||
|
# Run when a tag matching the pattern "photosd-v*"" is pushed
|
||||||
|
# See: [Note: Testing release workflows that are triggered by tags]
|
||||||
|
tags:
|
||||||
|
- "photosd-v*"
|
||||||
|
|
||||||
|
jobs:
|
||||||
|
release:
|
||||||
|
runs-on: ${{ matrix.os }}
|
||||||
|
|
||||||
|
defaults:
|
||||||
|
run:
|
||||||
|
working-directory: desktop
|
||||||
|
|
||||||
|
strategy:
|
||||||
|
matrix:
|
||||||
|
os: [macos-latest, ubuntu-latest, windows-latest]
|
||||||
|
|
||||||
|
steps:
|
||||||
|
- name: Checkout code
|
||||||
|
uses: actions/checkout@v4
|
||||||
|
with:
|
||||||
|
submodules: recursive
|
||||||
|
|
||||||
|
- name: Setup node
|
||||||
|
uses: actions/setup-node@v4
|
||||||
|
with:
|
||||||
|
node-version: 20
|
||||||
|
|
||||||
|
- name: Install dependencies
|
||||||
|
run: yarn install
|
||||||
|
|
||||||
|
- name: Prepare for app notarization
|
||||||
|
if: startsWith(matrix.os, 'macos')
|
||||||
|
# Import Apple API key for app notarization on macOS
|
||||||
|
run: |
|
||||||
|
mkdir -p ~/private_keys/
|
||||||
|
echo '${{ secrets.APPLE_API_KEY }}' > ~/private_keys/AuthKey_${{ secrets.APPLE_API_KEY_ID }}.p8
|
||||||
|
|
||||||
|
- name: Install libarchive-tools for pacman build
|
||||||
|
if: startsWith(matrix.os, 'ubuntu')
|
||||||
|
# See:
|
||||||
|
# https://github.com/electron-userland/electron-builder/issues/4181
|
||||||
|
run: sudo apt-get install libarchive-tools
|
||||||
|
|
||||||
|
- name: Build
|
||||||
|
uses: ente-io/action-electron-builder@v1.0.0
|
||||||
|
with:
|
||||||
|
# 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 API key details
|
||||||
|
API_KEY_ID: ${{ secrets.APPLE_API_KEY_ID }}
|
||||||
|
API_KEY_ISSUER_ID: ${{ secrets.APPLE_API_KEY_ISSUER_ID }}
|
||||||
|
USE_HARD_LINKS: false
|
55
desktop/.github/workflows/build.yml
vendored
55
desktop/.github/workflows/build.yml
vendored
|
@ -1,55 +0,0 @@
|
||||||
name: Build/release
|
|
||||||
|
|
||||||
on:
|
|
||||||
push:
|
|
||||||
tags:
|
|
||||||
- v*
|
|
||||||
|
|
||||||
jobs:
|
|
||||||
release:
|
|
||||||
runs-on: ${{ matrix.os }}
|
|
||||||
|
|
||||||
strategy:
|
|
||||||
matrix:
|
|
||||||
os: [macos-latest, ubuntu-latest, windows-latest]
|
|
||||||
|
|
||||||
steps:
|
|
||||||
- name: Check out Git repository
|
|
||||||
uses: actions/checkout@v3
|
|
||||||
with:
|
|
||||||
submodules: recursive
|
|
||||||
|
|
||||||
- name: Install Node.js, NPM and Yarn
|
|
||||||
uses: actions/setup-node@v3
|
|
||||||
with:
|
|
||||||
node-version: 20
|
|
||||||
|
|
||||||
- name: Prepare for app notarization
|
|
||||||
if: startsWith(matrix.os, 'macos')
|
|
||||||
# Import Apple API key for app notarization on macOS
|
|
||||||
run: |
|
|
||||||
mkdir -p ~/private_keys/
|
|
||||||
echo '${{ secrets.api_key }}' > ~/private_keys/AuthKey_${{ secrets.api_key_id }}.p8
|
|
||||||
|
|
||||||
- name: Install libarchive-tools for pacman build # Related https://github.com/electron-userland/electron-builder/issues/4181
|
|
||||||
if: startsWith(matrix.os, 'ubuntu')
|
|
||||||
run: sudo apt-get install libarchive-tools
|
|
||||||
|
|
||||||
- name: Ente Electron Builder Action
|
|
||||||
uses: ente-io/action-electron-builder@v1.0.0
|
|
||||||
with:
|
|
||||||
# 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 API key
|
|
||||||
API_KEY_ID: ${{ secrets.api_key_id }}
|
|
||||||
API_KEY_ISSUER_ID: ${{ secrets.api_key_issuer_id}}
|
|
||||||
USE_HARD_LINKS: false
|
|
|
@ -10,12 +10,6 @@ To know more about Ente, see [our main README](../README.md) or visit
|
||||||
|
|
||||||
## Building from source
|
## Building from source
|
||||||
|
|
||||||
> [!CAUTION]
|
|
||||||
>
|
|
||||||
> We're improving the security of the desktop app further by migrating to
|
|
||||||
> Electron's sandboxing and contextIsolation. These updates are still WIP and
|
|
||||||
> meanwhile the instructions below might not fully work on the main branch.
|
|
||||||
|
|
||||||
Fetch submodules
|
Fetch submodules
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
|
|
|
@ -1,43 +1,33 @@
|
||||||
## Releases
|
## Releases
|
||||||
|
|
||||||
> [!NOTE]
|
|
||||||
>
|
|
||||||
> TODO(MR): This document needs to be audited and changed as we do the first
|
|
||||||
> release from this new monorepo.
|
|
||||||
|
|
||||||
The Github Action that builds the desktop binaries is triggered by pushing a tag
|
The Github Action that builds the desktop binaries is triggered by pushing a tag
|
||||||
matching the pattern `photos-desktop-v1.2.3`. This value should match the
|
matching the pattern `photosd-v1.2.3`. This value should match the version in
|
||||||
version in `package.json`.
|
`package.json`.
|
||||||
|
|
||||||
So the process for doing a release would be.
|
To make a new release
|
||||||
|
|
||||||
1. Create a new branch (can be named anything). On this branch, include your
|
1. Create a new branch (can be named anything). On this branch, change the
|
||||||
changes.
|
`version` in `package.json` to `1.x.x` and finalize `CHANGELOG.md`.
|
||||||
|
|
||||||
2. Mention the changes in `CHANGELOG.md`.
|
2. Commit, tag and push to remote. Note that the tag should have a `photosd-`
|
||||||
|
prefix:
|
||||||
3. Changing the `version` in `package.json` to `1.x.x`.
|
|
||||||
|
|
||||||
4. Commit and push to remote
|
|
||||||
|
|
||||||
```sh
|
```sh
|
||||||
git add package.json && git commit -m 'Release v1.x.x'
|
git add CHANGELOG.md package.json
|
||||||
git tag v1.x.x
|
git commit -m 'Release v1.x.x'
|
||||||
git push && git push --tags
|
git tag photosd-v1.x.x
|
||||||
|
git push origin photosd-v1.x.x
|
||||||
```
|
```
|
||||||
|
|
||||||
This by itself will already trigger a new release. The GitHub action will create
|
This will trigger the GitHub action that will create a new draft release.
|
||||||
a new draft release that can then be used as descibed below.
|
|
||||||
|
|
||||||
To wrap up, we also need to merge back these changes into main. So for that,
|
3. To wrap up, increase the version number in `package.json` the next release
|
||||||
|
train. That is, suppose we just released `v4.0.1`. Then we'll change the
|
||||||
|
version number in main to `v4.0.2-beta.0`. Each pre-release will modify the
|
||||||
|
`beta.0` part. Finally, at the time of the next release, this'll become
|
||||||
|
`v4.0.2`.
|
||||||
|
|
||||||
5. Open a PR for the branch that we're working on (where the above tag was
|
4. Open a PR for the branch to get it merged into main.
|
||||||
pushed from) to get it merged into main.
|
|
||||||
|
|
||||||
6. In this PR, also increase the version number for the next release train. That
|
|
||||||
is, supposed we just released `v4.0.1`. Then we'll change the version number
|
|
||||||
in main to `v4.0.2-next.0`. Each pre-release will modify the `next.0` part.
|
|
||||||
Finally, at the time of the next release, this'll become `v4.0.2`.
|
|
||||||
|
|
||||||
The GitHub Action runs on Windows, Linux and macOS. It produces the artifacts
|
The GitHub Action runs on Windows, Linux and macOS. It produces the artifacts
|
||||||
defined in the `build` value in `package.json`.
|
defined in the `build` value in `package.json`.
|
||||||
|
@ -49,26 +39,14 @@ defined in the `build` value in `package.json`.
|
||||||
Additionally, the GitHub action notarizes the macOS DMG. For this it needs
|
Additionally, the GitHub action notarizes the macOS DMG. For this it needs
|
||||||
credentials provided via GitHub secrets.
|
credentials provided via GitHub secrets.
|
||||||
|
|
||||||
During the build the Sentry webpack plugin checks to see if SENTRY_AUTH_TOKEN is
|
To rollout the build, we need to publish the draft release. This needs to be
|
||||||
defined. If so, it uploads the sourcemaps for the renderer process to Sentry
|
done in the old photos-desktop repository since that the Electron Updater
|
||||||
(For our GitHub action, the SENTRY_AUTH_TOKEN is defined as a GitHub secret).
|
mechanism doesn't work well with monorepos. So we need to create a new tag with
|
||||||
|
changelog updates on
|
||||||
|
[photos-desktop](https://github.com/ente-io/photos-desktop/), use that to create
|
||||||
|
a new release, copying over all the artifacts.
|
||||||
|
|
||||||
The sourcemaps for the main (node) process are currently not sent to Sentry
|
Thereafter, everything is automated:
|
||||||
(this works fine in practice since the node process files are not minified, we
|
|
||||||
only run `tsc`).
|
|
||||||
|
|
||||||
Once the build is done, a draft release with all these artifacts attached is
|
|
||||||
created. The build is idempotent, so if something goes wrong and we need to
|
|
||||||
re-run the GitHub action, just delete the draft release (if it got created) and
|
|
||||||
start a new run by pushing a new tag (if some code changes are required).
|
|
||||||
|
|
||||||
If no code changes are required, say the build failed for some transient network
|
|
||||||
or sentry issue, we can even be re-run by the build by going to Github Action
|
|
||||||
age and rerun from there. This will re-trigger for the same tag.
|
|
||||||
|
|
||||||
If everything goes well, we'll have a release on GitHub, and the corresponding
|
|
||||||
source maps for the renderer process uploaded to Sentry. There isn't anything
|
|
||||||
else to do:
|
|
||||||
|
|
||||||
- The website automatically redirects to the latest release on GitHub when
|
- The website automatically redirects to the latest release on GitHub when
|
||||||
people try to download.
|
people try to download.
|
||||||
|
@ -76,7 +54,7 @@ else to do:
|
||||||
- The file formats with support auto update (Windows `exe`, the Linux AppImage
|
- The file formats with support auto update (Windows `exe`, the Linux AppImage
|
||||||
and the macOS DMG) also check the latest GitHub release automatically to
|
and the macOS DMG) also check the latest GitHub release automatically to
|
||||||
download and apply the update (the rest of the formats don't support auto
|
download and apply the update (the rest of the formats don't support auto
|
||||||
updates).
|
updates yet).
|
||||||
|
|
||||||
- We're not putting the desktop app in other stores currently. It is available
|
- We're not putting the desktop app in other stores currently. It is available
|
||||||
as a `brew cask`, but we only had to open a PR to add the initial formula,
|
as a `brew cask`, but we only had to open a PR to add the initial formula,
|
||||||
|
@ -87,6 +65,4 @@ else to do:
|
||||||
We can also publish the draft releases by checking the "pre-release" option.
|
We can also publish the draft releases by checking the "pre-release" option.
|
||||||
Such releases don't cause any of the channels (our website, or the desktop app
|
Such releases don't cause any of the channels (our website, or the desktop app
|
||||||
auto updater, or brew) to be notified, instead these are useful for giving links
|
auto updater, or brew) to be notified, instead these are useful for giving links
|
||||||
to pre-release builds to customers. Generally, in the version number for these
|
to pre-release builds to customers.
|
||||||
we'll add a label to the version, e.g. the "beta.x" in `1.x.x-beta.x`. This
|
|
||||||
should be done both in `package.json`, and what we tag the commit with.
|
|
||||||
|
|
Loading…
Reference in a new issue