Pascal Linxweiler 4b827941ee fix: make the release workflow build and package a real Jellyfin plugin ...

The release workflow was copied from another project and could not succeed on
any tag: it installed the .NET 8 SDK for a net9.0 project, published a
JellyfinSso.csproj that does not exist, called a missing update_manifest.py,
and zipped the entire publish tree instead of the three DLLs declared in
build.yaml.

Replace it with a tag-driven release:

- Build with the .NET 9 SDK, injecting the tag version via -p:Version,
  -p:AssemblyVersion and -p:FileVersion so the assembly no longer carries a
  hardcoded 1.0.3.0.
- Package via scripts/build_plugin.py, which emits the JPRM layout Jellyfin
  expects: the build.yaml artifacts plus a generated meta.json. The previous
  zips shipped without meta.json, which only worked for repository installs
  because Jellyfin synthesises one from the folder name.
- Update manifest.json via scripts/update_manifest.py, keeping build.yaml as
  the single source of truth for plugin metadata.
- Commit the zip and manifest to main and attach the zip to the Gitea release.
  Pushing uses the injected token, falling back to a RELEASE_TOKEN secret when
  the built-in one lacks write access.

Also fix the published download URLs. manifest.json and the README pointed at
pascallinxweiler/jellyfinplugin, which 404s; the repository is jellyfinsso, so
the plugin repository could not be added to Jellyfin and no version could be
downloaded. The workflow now derives the URL from GITHUB_REPOSITORY.

Add a build workflow so main and pull requests are compiled and packaged.

Co-Authored-By: Claude <noreply@anthropic.com>

2026-07-29 15:18:40 +02:00

930 B

Raw Blame History

View Raw