Publish a first release

[iderex]

This plugin has never published a release. Until it does, it cannot
appear in the Flowfin manifest, and the manifest URL cannot be announced.
The programme and the decisions behind it sit in a plan I keep elsewhere.

Why nothing has published

There is a publish.yaml, but the repository has no tag, so it has never
run. It also triggers on release: released, which means a person has to
create the release by hand and CI only attaches files afterwards.

What to build

Model it on Flowfin/jellyfin-plugin-sso, which publishes today and is the
quality target for every board. Read its .github/workflows/publish.yml and
build.yaml first.

• Trigger on a pushed tag X.Y.Z-stable. CI creates and publishes the
  release from that tag. Nothing is minted by hand, because deleting an
  immutable release burns its tag permanently.
• Attach the plugin archive, exactly one .md5 for that archive, a
  .sha256, and build.yaml. Only one asset in the release may end in
  .md5. A generator that kept the last such asset once published an SBOM
  checksum as the plugin checksum and broke every install.
• Fail the run if the numeric part of the tag does not equal version in
  build.yaml. Checked by the workflow, not by reading.
• Remove the call into jellyfin/jellyfin-meta-plugins and the three deploy
  secrets it demands. We do not hold them, and the steps that would use them
  skip on a repository name test, so they are ballast that will look like a
  cause the first time something else fails.
• Set imageUrl in build.yaml. There is none today, so the catalogue
  entry would be an empty tile.

This repository in particular

build.yaml says version 1.0.0.0 and targetAbi 10.11.11.0.

The floor 10.11.11.0 is unusually specific for a plugin that has never shipped. Establish where it came from and whether a build proves it, or widen it to a floor that does. A 1.0.0.0 on code with no release is a claim somebody has to stand behind; raise it as a question for the decision holder.

Done when

A tag push produces a published release whose assets install cleanly into a
Jellyfin server at the claimed targetAbi floor, with exactly one .md5
present, and a second tag push produces a second release without manual steps.

[iderex]

Most of the five items under "What to build" are already in the tree, and saying which
ones is the useful thing to put here, so that whoever picks this up does not rebuild
them. Read against origin/master at 7d548a8.

Trigger and creation are met. The workflow runs on a pushed tag and creates the release
itself rather than waiting for one made by hand:

git show 'origin/master:.github/workflows/publish.yaml' | sed -n '/^on:/,/^# Deny/p'
on:
  push:
    tags:
      - "[0-9]+.[0-9]+.[0-9]+-stable"
      - "[0-9]+.[0-9]+.[0-9]+.[0-9]+-stable"

The version check is met, in the gate job, which refuses the run when the numeric part
of the tag and version in build.yaml differ.

The call into jellyfin/jellyfin-meta-plugins and its deploy secrets are gone from this
route. One secret is left and it is the token the forge issues to the run:

git grep -c 'jellyfin-meta-plugins' origin/master -- .github/workflows/publish.yaml ; echo "exit=$?"
exit=1
git grep -o 'secrets\.[A-Z_]*' origin/master -- .github/workflows/publish.yaml | sort -u
origin/master:.github/workflows/publish.yaml:secrets.GITHUB_TOKEN

Four other workflows still call that repository. They are the build, test, changelog and
label routes rather than this one, and they belong to #90 and #176.

imageUrl is set and points at the logo in this tree.

The single .md5 is met and it is enforced rather than assumed. The release job counts
the archives before it writes any checksum and stops on anything other than one, so the
failure this issue describes cannot arrive by accident on this route.

The one item that is not met

build.yaml is not among the release assets. The release job takes no checkout and
uploads only what the build job handed it:

git show 'origin/master:.github/workflows/publish.yaml' | grep -n 'No checkout'
405:      # No checkout. This job only handles the bytes the build job produced.

git show 'origin/master:.github/workflows/publish.yaml' | sed -n '362,365p'
          path: |
            ${{ steps.jprm.outputs.artifact }}
            ${{ steps.jprm.outputs.artifact }}.meta.json

So a release carries the archive, the packaging metadata written beside it, and the two
checksums. The manifest itself is not there. Whether the packaging metadata is what this
condition wanted, given it is generated from build.yaml and travels with the bytes
that shipped, is a judgement about the route rather than a fact about the tree, and it
is not taken here.

The version

#180 moves build.yaml from 1.0.0.0 to 0.1.0.0. That is the question this issue
raises under "This repository in particular", and the answer is the decision recorded on
#1 that versions begin at 0.x and reach 1.0 when the board's done conditions are met.
docs/RELEASING.md already used 0.1.0.0-stable as its worked example.

The targetAbi floor is the other half of that paragraph and it is not answered here.
#91 holds it, with the measurement showing the floor is read off the assembly each
target compiled against rather than declared independently.

Why this stays open

The done condition is a published release, and then a second one. Nothing short of a tag
push produces either, and a release cannot be withdrawn without burning its tag, so the
first one is not a step to take on the way to checking whether the workflow works. The
condition also asks that the assets install cleanly into a Jellyfin server at the claimed
floor, and docs/compatibility.md records that no line has been run on a server at all,
so there is nothing here that could observe an install.

[iderex]

#201 is on the mainline as 9f4b86e3acc7657d6820971ec8698b6c8fb616dc. The one item the note above records as unmet is met, and this is what is left rather than a claim that the issue is done.

The manifest is now a release asset

The build job copies it next to the package and hands the copy over with the archive and the metadata:

git grep -n 'cp build.yaml' origin/master -- .github/workflows/publish.yaml
origin/master:.github/workflows/publish.yaml:377:          cp build.yaml "${directory}/build.yaml"

git grep -n -A3 'path: |' origin/master -- .github/workflows/publish.yaml
origin/master:.github/workflows/publish.yaml:408:          path: |
origin/master:.github/workflows/publish.yaml-409-            ${{ steps.jprm.outputs.artifact }}
origin/master:.github/workflows/publish.yaml-410-            ${{ steps.jprm.outputs.artifact }}.meta.json
origin/master:.github/workflows/publish.yaml-411-            ${{ steps.assets.outputs.manifest }}

The copy is the part that is not decoration. The upload roots an artifact at the deepest directory every path it is given has in common, so a path taken from the checkout root would move the archive one directory down in the download, where the release job's ./*.zip matches nothing and the run stops after the tag has been pushed. ReleaseAssetsTests refuses that shape, and the fixture it is proven on is the mistake as somebody would write it.

The release job also asks for the manifest by name after the download, because a path that stopped matching in the upload is a warning rather than an error:

git grep -n 'not among the downloaded files' origin/master -- .github/workflows/publish.yaml
origin/master:.github/workflows/publish.yaml:531:            echo "::error::The manifest the package was built from is not among the downloaded files, so the release would carry the archive without it."

docs/RELEASING.md lists five files rather than four and says which of them carry a checksum beside them.

Why this stays open

The done condition is a published release, and then a second one. No tag was pushed here and none should be pushed to find out whether the route works, because a release cannot be withdrawn without burning its tag. So every part of the route above is held by the file, by the suite and by a reading, and not by a run.

The other half of the condition, that the assets install cleanly into a Jellyfin server at the claimed floor, is unchanged: docs/compatibility.md records that no line has been run on a server at all, so there is nothing here that could observe an install.

The targetAbi question raised under "This repository in particular" is also unchanged and is #91's, where the measurement shows the floor is read off the assembly each target compiled against rather than declared beside it.

[iderex]

This issue was closed by the merge of #201 and is reopened. It is not done, and the note above says what is left.

The cause is the one #89 recorded when the same thing happened there. The pull request body carried a sentence disclaiming a close, and the forge reads the verb in it as an instruction and never the negation in front of it:

gh api repos/Flowfin/jellyfin-plugin-watch-sync/issues/159/timeline \
  --jq '.[] | select(.event=="closed") | "\(.event) commit=\(.commit_id)"'
closed commit=null

No commit is named because the sentence was in the body rather than in a commit message. The body is edited to say that this issue stays open and on what, which is the form that carries the same meaning without performing anything.

[iderex]

The version half of "This repository in particular" is on the mainline. #180 merged as 92025335a296dc2d8acb047198a6227689884357:

git show origin/master:build.yaml | grep -n '^version:'
5:version: "0.1.0.0"

That paragraph asks whether a 1.0.0.0 on code with no release is a claim somebody has to stand behind. The answer it now carries is the one recorded on #1, that versions begin at 0.x and reach 1.0 once the board's done conditions are met, and the manifest and the assembly are held to one number by PluginVersionTests rather than by two files being kept in step.

One thing about that landing is worth having on the record here, because it reads as a rule being skipped and is the opposite. The pull request had been red on the rule that a version bump carries a changelog entry. The rule now declines to fire on this repository and prints its reason instead of passing in silence:

a-version-bump-carries-a-changelog-entry: not applied, because the repository
has published no release, so the number that moves from 1.0.0.0 to 0.1.0.0 was
never one anybody could look up. The rule asks for an entry an operator can read
against a release they can install, and there is none to read it against.

The premise it declines on is this issue:

gh release list --limit 5 ; echo "exit=$?"
exit=0

No output, so no release exists for an entry to be read against. The first one published closes that window, and every version bump after it meets the rule with the entry it asks for.

This issue stays open on the rest, which is unchanged and is written above rather than again here: a published release, a second one after it without manual steps, and assets observed installing at the claimed floor, which docs/compatibility.md records has not happened on either line. The targetAbi half of the same paragraph is #91's.

Pushing the first tag is not a step to take on the way to finding out whether the route works, because a release cannot be withdrawn without burning its tag. It is left for the decision holder to start.

[iderex]

What this waits on

The first release tag being pushed, which is yours to start because a published release cannot be withdrawn without burning its tag, and a Jellyfin server to observe the assets installing at the claimed floor on either line.

[iderex]

Decision: the first-release wave is a go, all six boards at once. Prepare everything up to the human act - notes, versioning, artefacts, whatever this board's release procedure owes - and when only my click or signature remains, say so here and flag it; I will walk the finished list in one pass.