[#142] Stable release asset names, automated release publishing, README install block - #143
Merged
Merged
Conversation
…block Installing the tool took more inference than it should, and assembling a release was manual enough to be easy to get wrong. The release zips now have stable names (UnityDataTool-<os>-<arch>.zip), so releases/latest/download/ links are permanent and anything automated can fetch a build without querying the releases API. Pushing a vX.Y.Z tag now builds all three platforms, writes checksums.txt and creates a draft release with them attached, leaving only the title and notes to write by hand. The zips are built in the platform jobs rather than taken from upload-artifact, which drops the executable permission bit on macOS and Linux. The README gains an Install section at the top with per-platform commands that can be copied verbatim, replacing the Downloads section; the agent guide gets the same commands. Documentation/releasing.md describes cutting a release. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Install into ~/.local/share/UnityDataTool rather than ~/UnityDataTool on macOS and Linux: a visible app folder at the top of the home directory is not a convention, while the XDG data directory is the usual home for a per-user tool on both. Windows keeps %LOCALAPPDATA%\Programs\UnityDataTool, which is where per-user app installs go. The prose now names both paths instead of saying "a directory", and points at the dest variable for installing elsewhere. Re-running the commands overwrites what the new release ships but leaves behind any file the release dropped, so say so and mention deleting the directory first for an exact copy. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Fixes #142.
Installing UnityDataTool worked but took more steps and more inference than it should, and
assembling a release was manual enough to be easy to get wrong. This covers the three parts agreed
in the issue: stable asset names, publishing the release from the tag push, and an install section
at the top of the README. Install/upgrade shell scripts and package managers remain out of scope.
Release assets are now named
UnityDataTool-<os>-<arch>.zipwith no version prefix, which makeshttps://github.com/Unity-Technologies/UnityDataTools/releases/latest/download/UnityDataTool-windows-x64.zipa permanent, unauthenticated download link — nothing has to query the releases API and parse JSON to
find the right asset. The version is still in the release title, in
checksums.txtand in--version.Changes
Release automation (
.github/workflows/.build.yml)UnityDataTool-<os>-<arch>.zipand uploadsthat zip as the artifact. The zip is built in the job rather than taken from
upload-artifact,because that one drops the executable permission bit on macOS and Linux.
releasejob runs on av*tag: it collects the three zips, writeschecksums.txt, andcreates a draft GitHub release with all four assets attached. Re-running the workflow for a
tag that already has a release re-uploads over the existing assets.
platform can be left out by hand, and the zips always come from a build of the tagged commit.
Documentation
README.md: newInstallsection directly after the intro, with per-platform commands that canbe copied verbatim (download, unzip,
--version), a note that re-running them upgrades, plusPATH, macOS quarantine and Intel Mac notes. It replaces the old
Downloadssection further down,which described the process in prose with no commands.
Documentation/agent-guide.md: the same commands underGetting the tool, so an agent pointed atthis guide can install the tool instead of assuming it is present.
Documentation/releasing.md: new; the version convention (-devon main), the release steps, andwhy the asset names must stay stable. Linked from the README and
AGENTS.md.Testing
No product code changed, so the test suite is unaffected.
The packaging steps were verified locally by mirroring the Windows job (publish, prune other
platforms' native libraries and
.pdbs, copy the docs,Compress-Archive, extract): the zip is33.3 MB — the same as the current release asset — its contents are flat, and the extracted
executable runs and reports its version. The workflow YAML parses, and the README's
Invoke-WebRequestdownload command was checked on Windows PowerShell 5.1 as well as PowerShell 7.The
releasejob itself can only be exercised by pushing a tag, so it is worth watching the nextrelease run. Note that the
releases/latest/download/URLs in the README resolve only once a releasewith the new asset names has been published — the current v2.2.0 assets still carry the old names.
🤖 Generated with Claude Code