feat(release): publish the Linux .deb and .rpm from the release workflow by chukfinley · Pull Request #1 · bigpod98/t3code

chukfinley · 2026-08-06T19:21:01Z

Adds the release wiring to your branch, per the consolidation discussion in pingdotgg#5139 (@raulferrodrigues asked me to send this here rather than keep a competing PR open).

Your branch has complete packaging metadata but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm.

What this adds

File	Change
`.github/workflows/release.yml`	Linux entry builds `AppImage,deb,rpm` from one run; `.deb`/`.rpm` added to the collect step and to both release upload lists; a Linux-only step that guarantees `rpmbuild`.
`scripts/build-desktop-artifact.ts`	`resolveLinuxTargets` splits the comma-separated target; the `deb`/`rpm` sections and the headless launcher key off the resolved list instead of an exact string match.
`scripts/build-desktop-artifact.test.ts`	Covers the split and that one build configures both fpm formats while an AppImage-only build stays clean.
`package.json`	`:arm64`/`:x64` variants for `dist:desktop:deb`/`:rpm`, matching the `dmg`/`win` families. The bare script drops `--arch x64` so it uses host arch like `dist:desktop:dmg` does.
`docs/`, `download.astro`	Document both formats and the comma-separated target; add `.deb` and `.rpm` download cards.

Why one run instead of a matrix entry per format

A second Linux matrix entry collides on the upload artifact name: it is desktop-${{ matrix.platform }}-${{ matrix.arch }}, so two entries differing only by target both produce desktop-linux-x64 and upload-artifact fails. That is the collision pingdotgg#1655 was closed over. Building every target in the one existing entry avoids it by construction, and artifactName's ${ext} already keeps .AppImage, .deb and .rpm apart. No extra runner, no extra release wall-clock.

rpm and rpmbuild

electron-builder shells out to rpmbuild. The Ubuntu 24.04 runner image ships it in the rpm package (4.18.2+dfsg-2.1build2, which contains /usr/bin/rpmbuild), so the added step is a no-op in practice — it installs the package only if the binary is missing, so the target does not silently break if the image changes.

Two upload blocks, easy to miss

release.yml has two softprops/action-gh-release blocks — one for the first release, one for subsequent releases — each with its own file list. Both needed the new patterns. Miss the second and the packages build fine, upload to nothing, and nobody notices until someone goes looking for them in a release.

Notes

Left your headless /usr/bin/t3 launcher untouched, including its fpm wiring for both formats — you mentioned splitting it into its own PR, and that decision is yours to make on top of this.
Linux arm64 is still absent from the release matrix, as it is today for the AppImage too. The scripts here build it locally (dist:desktop:deb:arm64); shipping it needs a maintainer's call on an arm64 runner. Happy to write that follow-up.

Verified: vitest run scripts/build-desktop-artifact.test.ts 35 passed, vp lint clean on the touched scripts, release.yml parses.

The packaging metadata in this branch is complete, but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm. Rather than add a matrix entry per format, the existing Linux entry now builds `AppImage,deb,rpm` in one electron-builder run. A second entry would collide on the upload artifact name -- `desktop-${platform}-${arch}` is identical for two entries differing only by target, which is what sank pingdotgg#1655 -- while artifactName's ${ext} already keeps the output files apart. One runner, one artifact name, no extra release wall-clock. `resolveLinuxTargets` splits the comma-separated target, and the deb/rpm config sections plus the headless launcher now key off the resolved list rather than an exact string match, so a combined build configures both formats. Both `action-gh-release` blocks (first release and subsequent releases) carry their own file list; both needed the new patterns, otherwise the packages build and never ship. electron-builder shells out to rpmbuild for the rpm target. The Ubuntu runner image ships it in the `rpm` package (4.18.2 on 24.04), so the added step is a no-op there; it installs the package only when the binary is missing. Also adds the per-arch dist script variants (matching dist:desktop:dmg/win), docs for both formats, download-page cards, and tests over the target split.

raulferrodrigues · 2026-08-06T19:27:30Z

@chukfinley is this resolving and splitting necessary right now. we could just leave deb and rpm "hardcoded" there. if in the future we were to add more targets this would be warranted but not right now.

chukfinley · 2026-08-06T19:21:01Z

Adds the release wiring to your branch, per the consolidation discussion in pingdotgg#5139 (@raulferrodrigues asked me to send this here rather than keep a competing PR open).

Your branch has complete packaging metadata but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm.

What this adds

File	Change
`.github/workflows/release.yml`	Linux entry builds `AppImage,deb,rpm` from one run; `.deb`/`.rpm` added to the collect step and to both release upload lists; a Linux-only step that guarantees `rpmbuild`.
`scripts/build-desktop-artifact.ts`	`resolveLinuxTargets` splits the comma-separated target; the `deb`/`rpm` sections and the headless launcher key off the resolved list instead of an exact string match.
`scripts/build-desktop-artifact.test.ts`	Covers the split and that one build configures both fpm formats while an AppImage-only build stays clean.
`package.json`	`:arm64`/`:x64` variants for `dist:desktop:deb`/`:rpm`, matching the `dmg`/`win` families. The bare script drops `--arch x64` so it uses host arch like `dist:desktop:dmg` does.
`docs/`, `download.astro`	Document both formats and the comma-separated target; add `.deb` and `.rpm` download cards.

Why one run instead of a matrix entry per format

A second Linux matrix entry collides on the upload artifact name: it is desktop-${{ matrix.platform }}-${{ matrix.arch }}, so two entries differing only by target both produce desktop-linux-x64 and upload-artifact fails. That is the collision pingdotgg#1655 was closed over. Building every target in the one existing entry avoids it by construction, and artifactName's ${ext} already keeps .AppImage, .deb and .rpm apart. No extra runner, no extra release wall-clock.

rpm and rpmbuild

electron-builder shells out to rpmbuild. The Ubuntu 24.04 runner image ships it in the rpm package (4.18.2+dfsg-2.1build2, which contains /usr/bin/rpmbuild), so the added step is a no-op in practice — it installs the package only if the binary is missing, so the target does not silently break if the image changes.

Two upload blocks, easy to miss

release.yml has two softprops/action-gh-release blocks — one for the first release, one for subsequent releases — each with its own file list. Both needed the new patterns. Miss the second and the packages build fine, upload to nothing, and nobody notices until someone goes looking for them in a release.

Notes

Left your headless /usr/bin/t3 launcher untouched, including its fpm wiring for both formats — you mentioned splitting it into its own PR, and that decision is yours to make on top of this.
Linux arm64 is still absent from the release matrix, as it is today for the AppImage too. The scripts here build it locally (dist:desktop:deb:arm64); shipping it needs a maintainer's call on an arm64 runner. Happy to write that follow-up.

Verified: vitest run scripts/build-desktop-artifact.test.ts 35 passed, vp lint clean on the touched scripts, release.yml parses.

The packaging metadata in this branch is complete, but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm. Rather than add a matrix entry per format, the existing Linux entry now builds `AppImage,deb,rpm` in one electron-builder run. A second entry would collide on the upload artifact name -- `desktop-${platform}-${arch}` is identical for two entries differing only by target, which is what sank pingdotgg#1655 -- while artifactName's ${ext} already keeps the output files apart. One runner, one artifact name, no extra release wall-clock. `resolveLinuxTargets` splits the comma-separated target, and the deb/rpm config sections plus the headless launcher now key off the resolved list rather than an exact string match, so a combined build configures both formats. Both `action-gh-release` blocks (first release and subsequent releases) carry their own file list; both needed the new patterns, otherwise the packages build and never ship. electron-builder shells out to rpmbuild for the rpm target. The Ubuntu runner image ships it in the `rpm` package (4.18.2 on 24.04), so the added step is a no-op there; it installs the package only when the binary is missing. Also adds the per-arch dist script variants (matching dist:desktop:dmg/win), docs for both formats, download-page cards, and tests over the target split.

raulferrodrigues · 2026-08-06T19:27:30Z

@chukfinley is this resolving and splitting necessary right now. we could just leave deb and rpm "hardcoded" there. if in the future we were to add more targets this would be warranted but not right now.

chukfinley · 2026-08-06T19:21:01Z

Adds the release wiring to your branch, per the consolidation discussion in pingdotgg#5139 (@raulferrodrigues asked me to send this here rather than keep a competing PR open).

Your branch has complete packaging metadata but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm.

What this adds

File	Change
`.github/workflows/release.yml`	Linux entry builds `AppImage,deb,rpm` from one run; `.deb`/`.rpm` added to the collect step and to both release upload lists; a Linux-only step that guarantees `rpmbuild`.
`scripts/build-desktop-artifact.ts`	`resolveLinuxTargets` splits the comma-separated target; the `deb`/`rpm` sections and the headless launcher key off the resolved list instead of an exact string match.
`scripts/build-desktop-artifact.test.ts`	Covers the split and that one build configures both fpm formats while an AppImage-only build stays clean.
`package.json`	`:arm64`/`:x64` variants for `dist:desktop:deb`/`:rpm`, matching the `dmg`/`win` families. The bare script drops `--arch x64` so it uses host arch like `dist:desktop:dmg` does.
`docs/`, `download.astro`	Document both formats and the comma-separated target; add `.deb` and `.rpm` download cards.

Why one run instead of a matrix entry per format

A second Linux matrix entry collides on the upload artifact name: it is desktop-${{ matrix.platform }}-${{ matrix.arch }}, so two entries differing only by target both produce desktop-linux-x64 and upload-artifact fails. That is the collision pingdotgg#1655 was closed over. Building every target in the one existing entry avoids it by construction, and artifactName's ${ext} already keeps .AppImage, .deb and .rpm apart. No extra runner, no extra release wall-clock.

rpm and rpmbuild

electron-builder shells out to rpmbuild. The Ubuntu 24.04 runner image ships it in the rpm package (4.18.2+dfsg-2.1build2, which contains /usr/bin/rpmbuild), so the added step is a no-op in practice — it installs the package only if the binary is missing, so the target does not silently break if the image changes.

Two upload blocks, easy to miss

release.yml has two softprops/action-gh-release blocks — one for the first release, one for subsequent releases — each with its own file list. Both needed the new patterns. Miss the second and the packages build fine, upload to nothing, and nobody notices until someone goes looking for them in a release.

Notes

Left your headless /usr/bin/t3 launcher untouched, including its fpm wiring for both formats — you mentioned splitting it into its own PR, and that decision is yours to make on top of this.
Linux arm64 is still absent from the release matrix, as it is today for the AppImage too. The scripts here build it locally (dist:desktop:deb:arm64); shipping it needs a maintainer's call on an arm64 runner. Happy to write that follow-up.

Verified: vitest run scripts/build-desktop-artifact.test.ts 35 passed, vp lint clean on the touched scripts, release.yml parses.

The packaging metadata in this branch is complete, but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm. Rather than add a matrix entry per format, the existing Linux entry now builds `AppImage,deb,rpm` in one electron-builder run. A second entry would collide on the upload artifact name -- `desktop-${platform}-${arch}` is identical for two entries differing only by target, which is what sank pingdotgg#1655 -- while artifactName's ${ext} already keeps the output files apart. One runner, one artifact name, no extra release wall-clock. `resolveLinuxTargets` splits the comma-separated target, and the deb/rpm config sections plus the headless launcher now key off the resolved list rather than an exact string match, so a combined build configures both formats. Both `action-gh-release` blocks (first release and subsequent releases) carry their own file list; both needed the new patterns, otherwise the packages build and never ship. electron-builder shells out to rpmbuild for the rpm target. The Ubuntu runner image ships it in the `rpm` package (4.18.2 on 24.04), so the added step is a no-op there; it installs the package only when the binary is missing. Also adds the per-arch dist script variants (matching dist:desktop:dmg/win), docs for both formats, download-page cards, and tests over the target split.

raulferrodrigues · 2026-08-06T19:27:30Z

@chukfinley is this resolving and splitting necessary right now. we could just leave deb and rpm "hardcoded" there. if in the future we were to add more targets this would be warranted but not right now.

chukfinley · 2026-08-06T19:21:01Z

Adds the release wiring to your branch, per the consolidation discussion in pingdotgg#5139 (@raulferrodrigues asked me to send this here rather than keep a competing PR open).

Your branch has complete packaging metadata but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm.

What this adds

File	Change
`.github/workflows/release.yml`	Linux entry builds `AppImage,deb,rpm` from one run; `.deb`/`.rpm` added to the collect step and to both release upload lists; a Linux-only step that guarantees `rpmbuild`.
`scripts/build-desktop-artifact.ts`	`resolveLinuxTargets` splits the comma-separated target; the `deb`/`rpm` sections and the headless launcher key off the resolved list instead of an exact string match.
`scripts/build-desktop-artifact.test.ts`	Covers the split and that one build configures both fpm formats while an AppImage-only build stays clean.
`package.json`	`:arm64`/`:x64` variants for `dist:desktop:deb`/`:rpm`, matching the `dmg`/`win` families. The bare script drops `--arch x64` so it uses host arch like `dist:desktop:dmg` does.
`docs/`, `download.astro`	Document both formats and the comma-separated target; add `.deb` and `.rpm` download cards.

Why one run instead of a matrix entry per format

A second Linux matrix entry collides on the upload artifact name: it is desktop-${{ matrix.platform }}-${{ matrix.arch }}, so two entries differing only by target both produce desktop-linux-x64 and upload-artifact fails. That is the collision pingdotgg#1655 was closed over. Building every target in the one existing entry avoids it by construction, and artifactName's ${ext} already keeps .AppImage, .deb and .rpm apart. No extra runner, no extra release wall-clock.

rpm and rpmbuild

electron-builder shells out to rpmbuild. The Ubuntu 24.04 runner image ships it in the rpm package (4.18.2+dfsg-2.1build2, which contains /usr/bin/rpmbuild), so the added step is a no-op in practice — it installs the package only if the binary is missing, so the target does not silently break if the image changes.

Two upload blocks, easy to miss

release.yml has two softprops/action-gh-release blocks — one for the first release, one for subsequent releases — each with its own file list. Both needed the new patterns. Miss the second and the packages build fine, upload to nothing, and nobody notices until someone goes looking for them in a release.

Notes

Left your headless /usr/bin/t3 launcher untouched, including its fpm wiring for both formats — you mentioned splitting it into its own PR, and that decision is yours to make on top of this.
Linux arm64 is still absent from the release matrix, as it is today for the AppImage too. The scripts here build it locally (dist:desktop:deb:arm64); shipping it needs a maintainer's call on an arm64 runner. Happy to write that follow-up.

Verified: vitest run scripts/build-desktop-artifact.test.ts 35 passed, vp lint clean on the touched scripts, release.yml parses.

The packaging metadata in this branch is complete, but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm. Rather than add a matrix entry per format, the existing Linux entry now builds `AppImage,deb,rpm` in one electron-builder run. A second entry would collide on the upload artifact name -- `desktop-${platform}-${arch}` is identical for two entries differing only by target, which is what sank pingdotgg#1655 -- while artifactName's ${ext} already keeps the output files apart. One runner, one artifact name, no extra release wall-clock. `resolveLinuxTargets` splits the comma-separated target, and the deb/rpm config sections plus the headless launcher now key off the resolved list rather than an exact string match, so a combined build configures both formats. Both `action-gh-release` blocks (first release and subsequent releases) carry their own file list; both needed the new patterns, otherwise the packages build and never ship. electron-builder shells out to rpmbuild for the rpm target. The Ubuntu runner image ships it in the `rpm` package (4.18.2 on 24.04), so the added step is a no-op there; it installs the package only when the binary is missing. Also adds the per-arch dist script variants (matching dist:desktop:dmg/win), docs for both formats, download-page cards, and tests over the target split.

raulferrodrigues · 2026-08-06T19:27:30Z

@chukfinley is this resolving and splitting necessary right now. we could just leave deb and rpm "hardcoded" there. if in the future we were to add more targets this would be warranted but not right now.

chukfinley · 2026-08-06T19:21:01Z

Adds the release wiring to your branch, per the consolidation discussion in pingdotgg#5139 (@raulferrodrigues asked me to send this here rather than keep a competing PR open).

Your branch has complete packaging metadata but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm.

What this adds

File	Change
`.github/workflows/release.yml`	Linux entry builds `AppImage,deb,rpm` from one run; `.deb`/`.rpm` added to the collect step and to both release upload lists; a Linux-only step that guarantees `rpmbuild`.
`scripts/build-desktop-artifact.ts`	`resolveLinuxTargets` splits the comma-separated target; the `deb`/`rpm` sections and the headless launcher key off the resolved list instead of an exact string match.
`scripts/build-desktop-artifact.test.ts`	Covers the split and that one build configures both fpm formats while an AppImage-only build stays clean.
`package.json`	`:arm64`/`:x64` variants for `dist:desktop:deb`/`:rpm`, matching the `dmg`/`win` families. The bare script drops `--arch x64` so it uses host arch like `dist:desktop:dmg` does.
`docs/`, `download.astro`	Document both formats and the comma-separated target; add `.deb` and `.rpm` download cards.

Why one run instead of a matrix entry per format

A second Linux matrix entry collides on the upload artifact name: it is desktop-${{ matrix.platform }}-${{ matrix.arch }}, so two entries differing only by target both produce desktop-linux-x64 and upload-artifact fails. That is the collision pingdotgg#1655 was closed over. Building every target in the one existing entry avoids it by construction, and artifactName's ${ext} already keeps .AppImage, .deb and .rpm apart. No extra runner, no extra release wall-clock.

rpm and rpmbuild

electron-builder shells out to rpmbuild. The Ubuntu 24.04 runner image ships it in the rpm package (4.18.2+dfsg-2.1build2, which contains /usr/bin/rpmbuild), so the added step is a no-op in practice — it installs the package only if the binary is missing, so the target does not silently break if the image changes.

Two upload blocks, easy to miss

release.yml has two softprops/action-gh-release blocks — one for the first release, one for subsequent releases — each with its own file list. Both needed the new patterns. Miss the second and the packages build fine, upload to nothing, and nobody notices until someone goes looking for them in a release.

Notes

Left your headless /usr/bin/t3 launcher untouched, including its fpm wiring for both formats — you mentioned splitting it into its own PR, and that decision is yours to make on top of this.
Linux arm64 is still absent from the release matrix, as it is today for the AppImage too. The scripts here build it locally (dist:desktop:deb:arm64); shipping it needs a maintainer's call on an arm64 runner. Happy to write that follow-up.

Verified: vitest run scripts/build-desktop-artifact.test.ts 35 passed, vp lint clean on the touched scripts, release.yml parses.

The packaging metadata in this branch is complete, but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm. Rather than add a matrix entry per format, the existing Linux entry now builds `AppImage,deb,rpm` in one electron-builder run. A second entry would collide on the upload artifact name -- `desktop-${platform}-${arch}` is identical for two entries differing only by target, which is what sank pingdotgg#1655 -- while artifactName's ${ext} already keeps the output files apart. One runner, one artifact name, no extra release wall-clock. `resolveLinuxTargets` splits the comma-separated target, and the deb/rpm config sections plus the headless launcher now key off the resolved list rather than an exact string match, so a combined build configures both formats. Both `action-gh-release` blocks (first release and subsequent releases) carry their own file list; both needed the new patterns, otherwise the packages build and never ship. electron-builder shells out to rpmbuild for the rpm target. The Ubuntu runner image ships it in the `rpm` package (4.18.2 on 24.04), so the added step is a no-op there; it installs the package only when the binary is missing. Also adds the per-arch dist script variants (matching dist:desktop:dmg/win), docs for both formats, download-page cards, and tests over the target split.

raulferrodrigues · 2026-08-06T19:27:30Z

@chukfinley is this resolving and splitting necessary right now. we could just leave deb and rpm "hardcoded" there. if in the future we were to add more targets this would be warranted but not right now.

chukfinley · 2026-08-06T19:21:01Z

Adds the release wiring to your branch, per the consolidation discussion in pingdotgg#5139 (@raulferrodrigues asked me to send this here rather than keep a competing PR open).

Your branch has complete packaging metadata but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm.

What this adds

File	Change
`.github/workflows/release.yml`	Linux entry builds `AppImage,deb,rpm` from one run; `.deb`/`.rpm` added to the collect step and to both release upload lists; a Linux-only step that guarantees `rpmbuild`.
`scripts/build-desktop-artifact.ts`	`resolveLinuxTargets` splits the comma-separated target; the `deb`/`rpm` sections and the headless launcher key off the resolved list instead of an exact string match.
`scripts/build-desktop-artifact.test.ts`	Covers the split and that one build configures both fpm formats while an AppImage-only build stays clean.
`package.json`	`:arm64`/`:x64` variants for `dist:desktop:deb`/`:rpm`, matching the `dmg`/`win` families. The bare script drops `--arch x64` so it uses host arch like `dist:desktop:dmg` does.
`docs/`, `download.astro`	Document both formats and the comma-separated target; add `.deb` and `.rpm` download cards.

Why one run instead of a matrix entry per format

A second Linux matrix entry collides on the upload artifact name: it is desktop-${{ matrix.platform }}-${{ matrix.arch }}, so two entries differing only by target both produce desktop-linux-x64 and upload-artifact fails. That is the collision pingdotgg#1655 was closed over. Building every target in the one existing entry avoids it by construction, and artifactName's ${ext} already keeps .AppImage, .deb and .rpm apart. No extra runner, no extra release wall-clock.

rpm and rpmbuild

electron-builder shells out to rpmbuild. The Ubuntu 24.04 runner image ships it in the rpm package (4.18.2+dfsg-2.1build2, which contains /usr/bin/rpmbuild), so the added step is a no-op in practice — it installs the package only if the binary is missing, so the target does not silently break if the image changes.

Two upload blocks, easy to miss

release.yml has two softprops/action-gh-release blocks — one for the first release, one for subsequent releases — each with its own file list. Both needed the new patterns. Miss the second and the packages build fine, upload to nothing, and nobody notices until someone goes looking for them in a release.

Notes

Left your headless /usr/bin/t3 launcher untouched, including its fpm wiring for both formats — you mentioned splitting it into its own PR, and that decision is yours to make on top of this.
Linux arm64 is still absent from the release matrix, as it is today for the AppImage too. The scripts here build it locally (dist:desktop:deb:arm64); shipping it needs a maintainer's call on an arm64 runner. Happy to write that follow-up.

Verified: vitest run scripts/build-desktop-artifact.test.ts 35 passed, vp lint clean on the touched scripts, release.yml parses.

The packaging metadata in this branch is complete, but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm. Rather than add a matrix entry per format, the existing Linux entry now builds `AppImage,deb,rpm` in one electron-builder run. A second entry would collide on the upload artifact name -- `desktop-${platform}-${arch}` is identical for two entries differing only by target, which is what sank pingdotgg#1655 -- while artifactName's ${ext} already keeps the output files apart. One runner, one artifact name, no extra release wall-clock. `resolveLinuxTargets` splits the comma-separated target, and the deb/rpm config sections plus the headless launcher now key off the resolved list rather than an exact string match, so a combined build configures both formats. Both `action-gh-release` blocks (first release and subsequent releases) carry their own file list; both needed the new patterns, otherwise the packages build and never ship. electron-builder shells out to rpmbuild for the rpm target. The Ubuntu runner image ships it in the `rpm` package (4.18.2 on 24.04), so the added step is a no-op there; it installs the package only when the binary is missing. Also adds the per-arch dist script variants (matching dist:desktop:dmg/win), docs for both formats, download-page cards, and tests over the target split.

raulferrodrigues · 2026-08-06T19:27:30Z

@chukfinley is this resolving and splitting necessary right now. we could just leave deb and rpm "hardcoded" there. if in the future we were to add more targets this would be warranted but not right now.

chukfinley · 2026-08-06T19:21:01Z

Adds the release wiring to your branch, per the consolidation discussion in pingdotgg#5139 (@raulferrodrigues asked me to send this here rather than keep a competing PR open).

Your branch has complete packaging metadata but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm.

What this adds

File	Change
`.github/workflows/release.yml`	Linux entry builds `AppImage,deb,rpm` from one run; `.deb`/`.rpm` added to the collect step and to both release upload lists; a Linux-only step that guarantees `rpmbuild`.
`scripts/build-desktop-artifact.ts`	`resolveLinuxTargets` splits the comma-separated target; the `deb`/`rpm` sections and the headless launcher key off the resolved list instead of an exact string match.
`scripts/build-desktop-artifact.test.ts`	Covers the split and that one build configures both fpm formats while an AppImage-only build stays clean.
`package.json`	`:arm64`/`:x64` variants for `dist:desktop:deb`/`:rpm`, matching the `dmg`/`win` families. The bare script drops `--arch x64` so it uses host arch like `dist:desktop:dmg` does.
`docs/`, `download.astro`	Document both formats and the comma-separated target; add `.deb` and `.rpm` download cards.

Why one run instead of a matrix entry per format

A second Linux matrix entry collides on the upload artifact name: it is desktop-${{ matrix.platform }}-${{ matrix.arch }}, so two entries differing only by target both produce desktop-linux-x64 and upload-artifact fails. That is the collision pingdotgg#1655 was closed over. Building every target in the one existing entry avoids it by construction, and artifactName's ${ext} already keeps .AppImage, .deb and .rpm apart. No extra runner, no extra release wall-clock.

rpm and rpmbuild

electron-builder shells out to rpmbuild. The Ubuntu 24.04 runner image ships it in the rpm package (4.18.2+dfsg-2.1build2, which contains /usr/bin/rpmbuild), so the added step is a no-op in practice — it installs the package only if the binary is missing, so the target does not silently break if the image changes.

Two upload blocks, easy to miss

release.yml has two softprops/action-gh-release blocks — one for the first release, one for subsequent releases — each with its own file list. Both needed the new patterns. Miss the second and the packages build fine, upload to nothing, and nobody notices until someone goes looking for them in a release.

Notes

Left your headless /usr/bin/t3 launcher untouched, including its fpm wiring for both formats — you mentioned splitting it into its own PR, and that decision is yours to make on top of this.
Linux arm64 is still absent from the release matrix, as it is today for the AppImage too. The scripts here build it locally (dist:desktop:deb:arm64); shipping it needs a maintainer's call on an arm64 runner. Happy to write that follow-up.

Verified: vitest run scripts/build-desktop-artifact.test.ts 35 passed, vp lint clean on the touched scripts, release.yml parses.

The packaging metadata in this branch is complete, but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm. Rather than add a matrix entry per format, the existing Linux entry now builds `AppImage,deb,rpm` in one electron-builder run. A second entry would collide on the upload artifact name -- `desktop-${platform}-${arch}` is identical for two entries differing only by target, which is what sank pingdotgg#1655 -- while artifactName's ${ext} already keeps the output files apart. One runner, one artifact name, no extra release wall-clock. `resolveLinuxTargets` splits the comma-separated target, and the deb/rpm config sections plus the headless launcher now key off the resolved list rather than an exact string match, so a combined build configures both formats. Both `action-gh-release` blocks (first release and subsequent releases) carry their own file list; both needed the new patterns, otherwise the packages build and never ship. electron-builder shells out to rpmbuild for the rpm target. The Ubuntu runner image ships it in the `rpm` package (4.18.2 on 24.04), so the added step is a no-op there; it installs the package only when the binary is missing. Also adds the per-arch dist script variants (matching dist:desktop:dmg/win), docs for both formats, download-page cards, and tests over the target split.

raulferrodrigues · 2026-08-06T19:27:30Z

@chukfinley is this resolving and splitting necessary right now. we could just leave deb and rpm "hardcoded" there. if in the future we were to add more targets this would be warranted but not right now.

chukfinley · 2026-08-06T19:21:01Z

Adds the release wiring to your branch, per the consolidation discussion in pingdotgg#5139 (@raulferrodrigues asked me to send this here rather than keep a competing PR open).

Your branch has complete packaging metadata but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm.

What this adds

File	Change
`.github/workflows/release.yml`	Linux entry builds `AppImage,deb,rpm` from one run; `.deb`/`.rpm` added to the collect step and to both release upload lists; a Linux-only step that guarantees `rpmbuild`.
`scripts/build-desktop-artifact.ts`	`resolveLinuxTargets` splits the comma-separated target; the `deb`/`rpm` sections and the headless launcher key off the resolved list instead of an exact string match.
`scripts/build-desktop-artifact.test.ts`	Covers the split and that one build configures both fpm formats while an AppImage-only build stays clean.
`package.json`	`:arm64`/`:x64` variants for `dist:desktop:deb`/`:rpm`, matching the `dmg`/`win` families. The bare script drops `--arch x64` so it uses host arch like `dist:desktop:dmg` does.
`docs/`, `download.astro`	Document both formats and the comma-separated target; add `.deb` and `.rpm` download cards.

Why one run instead of a matrix entry per format

A second Linux matrix entry collides on the upload artifact name: it is desktop-${{ matrix.platform }}-${{ matrix.arch }}, so two entries differing only by target both produce desktop-linux-x64 and upload-artifact fails. That is the collision pingdotgg#1655 was closed over. Building every target in the one existing entry avoids it by construction, and artifactName's ${ext} already keeps .AppImage, .deb and .rpm apart. No extra runner, no extra release wall-clock.

rpm and rpmbuild

electron-builder shells out to rpmbuild. The Ubuntu 24.04 runner image ships it in the rpm package (4.18.2+dfsg-2.1build2, which contains /usr/bin/rpmbuild), so the added step is a no-op in practice — it installs the package only if the binary is missing, so the target does not silently break if the image changes.

Two upload blocks, easy to miss

release.yml has two softprops/action-gh-release blocks — one for the first release, one for subsequent releases — each with its own file list. Both needed the new patterns. Miss the second and the packages build fine, upload to nothing, and nobody notices until someone goes looking for them in a release.

Notes

Left your headless /usr/bin/t3 launcher untouched, including its fpm wiring for both formats — you mentioned splitting it into its own PR, and that decision is yours to make on top of this.
Linux arm64 is still absent from the release matrix, as it is today for the AppImage too. The scripts here build it locally (dist:desktop:deb:arm64); shipping it needs a maintainer's call on an arm64 runner. Happy to write that follow-up.

Verified: vitest run scripts/build-desktop-artifact.test.ts 35 passed, vp lint clean on the touched scripts, release.yml parses.

The packaging metadata in this branch is complete, but nothing builds or ships the packages: the release matrix builds AppImage only, and the collect and upload steps never mention .deb or .rpm. Rather than add a matrix entry per format, the existing Linux entry now builds `AppImage,deb,rpm` in one electron-builder run. A second entry would collide on the upload artifact name -- `desktop-${platform}-${arch}` is identical for two entries differing only by target, which is what sank pingdotgg#1655 -- while artifactName's ${ext} already keeps the output files apart. One runner, one artifact name, no extra release wall-clock. `resolveLinuxTargets` splits the comma-separated target, and the deb/rpm config sections plus the headless launcher now key off the resolved list rather than an exact string match, so a combined build configures both formats. Both `action-gh-release` blocks (first release and subsequent releases) carry their own file list; both needed the new patterns, otherwise the packages build and never ship. electron-builder shells out to rpmbuild for the rpm target. The Ubuntu runner image ships it in the `rpm` package (4.18.2 on 24.04), so the added step is a no-op there; it installs the package only when the binary is missing. Also adds the per-arch dist script variants (matching dist:desktop:dmg/win), docs for both formats, download-page cards, and tests over the target split.

raulferrodrigues · 2026-08-06T19:27:30Z

@chukfinley is this resolving and splitting necessary right now. we could just leave deb and rpm "hardcoded" there. if in the future we were to add more targets this would be warranted but not right now.

chukfinley mentioned this pull request Aug 6, 2026
feat(packaging): add deb and rpm desktop targets pingdotgg/t3code#5139
Closed

raulferrodrigues reviewed Aug 6, 2026
View reviewed changes