starred/jellyfin
1
0
Fork 0
mirror of https://github.com/jellyfin/jellyfin.git synced 2026-07-16 05:43:54 +03:00
Code Issues 822 Packages Projects Releases 17 Wiki Activity

[PR #10363] Build Windows installer as part of packaging CI job #12455

New Issue
Closed
opened 2026-02-07 06:56:09 +03:00 by OVERLORD · 0 comments
OVERLORD commented 2026-02-07 06:56:09 +03:00
Owner
Copy Link

Original Pull Request: https://github.com/jellyfin/jellyfin/pull/10363

State: closed
Merged: No

This is more a proposal / proof of concept. I'm happy to take any suggestions and ideas, hence it's marked as a draft:

Changes
Using all the existing bits we can easily build the Windows installer for existing versions.

In this commit PR we:

  • Grab the latest version of JF Web (based on the latest unstable)
  • Grab the latest version of JF_UX
  • Install nsis
  • Build an installer as a dedicated artifact

Why; because being able to bundle JF installer as part of the daily builds increases the chances of finding bugs / getting fixes out. It also means that people don't have to figure out how to install ffmpeg...etc. if they want to test an unstable fix.

Limitations

  • The installer tags itself as the real version, this needs fixing in the upstream installer

  • We don't upload the installer as part of the CI to repos.jellyfin, this is partially because we don't want users easily finding "a released version", which is actually unstable but the installer is incorrect.

  • Some assumptions have been made about how JF web will name its files. Ideally we want a symlink which is repointed on repos.jellyfin which points to the latest version. For the moment (ab)use the date naming.

Testing
Run the docker build as follows from the source dir:

cd deployment && docker build .  -f Dockerfile.windows.amd64 -t win_build
cd .. && docker run -v $(pwd)/deployment/dist:/dist -v $(pwd):/jellyfin -e IS_UNSTABLE="yes" -e BUILD_ID="local" win_build

There will be an installer in deployment/dist/jellyfin-local-windows-x64.exe
Test on a Windows machine, I've got it working locally with the limitations described above:
image

I've also tested it with a forked pipeline to verify it plays nice with the CI (albeit with most of the packaging / testing steps deleted for my sanity) here

**Original Pull Request:** https://github.com/jellyfin/jellyfin/pull/10363 **State:** closed **Merged:** No --- This is more a proposal / proof of concept. I'm happy to take any suggestions and ideas, hence it's marked as a draft: **Changes** Using all the existing bits we can easily build the Windows installer for existing versions. In this ~commit~ PR we: - Grab the latest version of JF Web (based on the latest unstable) - Grab the latest version of JF_UX - Install nsis - Build an installer as a dedicated artifact Why; because being able to bundle JF installer as part of the daily builds increases the chances of finding bugs / getting fixes out. It also means that people don't have to figure out how to install ffmpeg...etc. if they want to test an unstable fix. Limitations - The installer tags itself as the real version, this needs fixing in the upstream installer - We don't upload the installer as part of the CI to repos.jellyfin, this is partially because we don't want users easily finding "a released version", which is actually unstable but the installer is incorrect. - Some assumptions have been made about how JF web will name its files. Ideally we want a symlink which is repointed on repos.jellyfin which points to the latest version. For the moment (ab)use the date naming. **Testing** Run the docker build as follows from the source dir: ``` cd deployment && docker build . -f Dockerfile.windows.amd64 -t win_build cd .. && docker run -v $(pwd)/deployment/dist:/dist -v $(pwd):/jellyfin -e IS_UNSTABLE="yes" -e BUILD_ID="local" win_build ``` There will be an installer in `deployment/dist/jellyfin-local-windows-x64.exe` Test on a Windows machine, I've got it working locally with the limitations described above: ![image](https://github.com/jellyfin/jellyfin/assets/1817032/4141c368-aa74-45aa-b133-271579919f98) I've also tested it with a forked pipeline to verify it plays nice with the CI (albeit with most of the packaging / testing steps deleted for my sanity) [here](https://dev.azure.com/DavidFair/Jellyfin%20Fork/_build/results?buildId=11&view=logs&j=b239e49c-c2c4-5033-bc88-01d0d0cdac65)
OVERLORD added the pull-request label 2026-02-07 06:56:09 +03:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
EFjellyfin.db
area:database
awaiting-feedback
backend
blocked
breaking change: web api
bug
build
ci
confirmed
discussion needed
dotnet future
downstream
duplicate
enhancement
feature
future
github-actions
good first issue
hdr
help wanted
invalid
investigation
librarydb
live-tv
lyrics
media playback
music
needs testing
nuget
performance
platform
pull-request
Mirrored from GitHub Pull Request
 question
regression
release critical
requires-web
roadmap
security
security
stale
support
syncplay
ui & ux
upstream
wontfix
No Label pull-request
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
OVERLORD
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/jellyfin#12455
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?