Skip to content

Fix desiredBinaryName being ignored when installing from archives#71

Merged
albertodebortoli merged 1 commit intomainfrom
fix/archive-desired-binary-name
Apr 14, 2026
Merged

Fix desiredBinaryName being ignored when installing from archives#71
albertodebortoli merged 1 commit intomainfrom
fix/archive-desired-binary-name

Conversation

@albertodebortoli
Copy link
Copy Markdown
Member

Pull Request Title

Fix desiredBinaryName being ignored when installing from archives

Description

  • When installing a tool from a zip or tar.gz archive, desiredBinaryName was silently discarded. installArchive hardcoded desiredBinaryName: nil when constructing the resolvedTool passed to PermissionManager and SymLinker, so the symlink always used the in-archive binary filename instead of the desired name.
  • The direct-binary path (installExecutable) worked correctly because it renames the downloaded file to desiredBinaryName before storing it in the cache.
  • The fix applies the same rename step in installArchive: after extraction, if desiredBinaryName is set, the binary is moved from its extracted path to desiredBinaryName within the installation destination. resolvedTool is then built with the updated path, making PermissionManager and SymLinker both point to the correct (renamed) file.
  • Reproducer: Phrase CLI (binaryPath: phrase_macosx_arm64, desiredBinaryName: phrase) — symlink was named phrase_macosx_arm64 instead of phrase.

Type of Change

  • Feature
  • Bug fix
  • Maintenance / Refactor
  • Documentation
  • CI / Tooling
  • Other (specify)

How Has This Been Tested?

  • Added / updated unit tests — test_install_archiveWithDesiredBinaryName_usesDesiredNameForSymlink covers the Phrase scenario end-to-end through ToolInstaller
  • Manually tested locally (describe) — verified with a real Phrase CLI Lucafile entry
  • Tested on macOS (arch: arm64 / x86_64)
  • Other

Checklist

  • Swift code builds locally (swift build)
  • Tests pass locally (swift test)
  • Code style / formatting respected
  • Documentation updated (README / comments)
  • Version / tag alignment considered (if release related)

CI Considerations

  • Affects build time notably
  • Requires new secrets / env vars
  • Alters release process

Breaking Changes?

  • No
  • Yes (describe impact and migration path)

Additional Notes

The root cause was a single desiredBinaryName: nil line in installArchive (introduced when the resolvedTool pattern was added). The executable path never had this bug because it physically renames the file on download.

When a tool was installed from a zip or tar.gz archive, `desiredBinaryName`
was discarded: `installArchive` hardcoded `desiredBinaryName: nil` in the
`resolvedTool` it passed to `PermissionManager` and `SymLinker`. As a result,
the symlink used the in-archive binary name instead of the desired one.

The fix renames the extracted binary to `desiredBinaryName` in the cache
before building `resolvedTool`, mirroring the behaviour of `installExecutable`.
A regression test covering the Phrase CLI scenario is added.
@albertodebortoli albertodebortoli added this to the 0.16.0 milestone Apr 14, 2026
@albertodebortoli albertodebortoli added the bugfix Something isn't working label Apr 14, 2026
@codecov
Copy link
Copy Markdown

codecov Bot commented Apr 14, 2026

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

@albertodebortoli albertodebortoli marked this pull request as ready for review April 14, 2026 13:17
@albertodebortoli albertodebortoli merged commit 09aee98 into main Apr 14, 2026
3 checks passed
@albertodebortoli albertodebortoli deleted the fix/archive-desired-binary-name branch April 14, 2026 13:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bugfix Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant