Skip to content

ci: rename DevolutionsAgentUpdater with arch suffix to avoid duplicate release assets#1760

Merged
Benoît Cortier (CBenoit) merged 5 commits intomasterfrom
ci/fix-github-releases
Apr 20, 2026
Merged

ci: rename DevolutionsAgentUpdater with arch suffix to avoid duplicate release assets#1760
Benoît Cortier (CBenoit) merged 5 commits intomasterfrom
ci/fix-github-releases

Conversation

@CBenoit
Copy link
Copy Markdown
Member

@CBenoit Benoît Cortier (CBenoit) commented Apr 20, 2026

DevolutionsAgentUpdater.exe is a new artifact that exists in both the arm64 and x86_64 output directories without an architecture suffix. When uploading to the GitHub release, gh uses the basename as the asset name, causing the second upload to fail with 'ReleaseAsset.name already exists'.

Name the file DevolutionsAgentUpdater_Windows__.exe, following the same convention already used for DevolutionsAgent_Windows_*.exe. Update all references in ci.yml and package.yml accordingly, and remove the now-unnecessary exclusions from the OneDrive upload flattening step.

@CBenoit Benoît Cortier (CBenoit) changed the title ci: rename DevolutionsAgentUpdater with arch suffix to avoid duplicat… ci: rename DevolutionsAgentUpdater with arch suffix to avoid duplicate release assets Apr 20, 2026
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR updates the CI/package workflows to rename the Windows Devolutions Agent Updater executable to an architecture-suffixed filename so GitHub Release asset uploads don’t collide between arm64 and x86_64.

Changes:

  • Rename the updater artifact from DevolutionsAgentUpdater.exe to DevolutionsAgentUpdater_<OS>_<version>_<arch>.exe in the CI staging output.
  • Update packaging/code-signing workflows to reference DevolutionsAgentUpdater_*.exe instead of the unsuffixed filename.
  • Remove now-unnecessary OneDrive upload exclusions for the updater (since the filename becomes unique per arch).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File Description
.github/workflows/ci.yml Changes the staged updater filename to include OS/version/arch; adjusts OneDrive flattening exclusions accordingly.
.github/workflows/package.yml Updates signing/MSI regeneration steps to look for the new updater filename pattern.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread .github/workflows/package.yml Outdated
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread .github/workflows/package.yml Outdated
Comment thread .github/workflows/ci.yml
…e release assets

DevolutionsAgentUpdater.exe is a new artifact that exists in both the
arm64 and x86_64 output directories without an architecture suffix.
When uploading to the GitHub release, gh uses the basename as the asset
name, causing the second upload to fail with 'ReleaseAsset.name already
exists'.

Name the file DevolutionsAgentUpdater_Windows_\_\.exe,
following the same convention already used for DevolutionsAgent_Windows_*.exe.
Update all references in ci.yml and package.yml accordingly, and remove
the now-unnecessary exclusions from the OneDrive upload flattening step.
…acts

The Regenerate Agent MSI step defaults to x86_64 (tlk.ps1 architecture
default) but was searching recursively across both arm64 and x86_64
directories, leaving the executable selection to chance via Select -First 1.

Introduce an $x64Root variable pointing to windows\x86_64 and scope all
per-architecture file lookups to that path. tun2socks and wintun are kept
with a recursive search on the full PackageRoot since they live under a
separate tun2socks\ subdirectory.
Copy link
Copy Markdown
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.


💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread .github/workflows/ci.yml
It is an internal MSI update helper bundled inside the installer,
not a useful standalone download for end users.
When MSBuild runs /t:restore,build in a single invocation on a fresh
runner without cached NuGet packages, the WixSharp.bin package .props
file (which sets WixSharpBinPath) is not evaluated at project-load
time (before restore runs). This leaves WixSharpBinPath empty, so
/WIXBIN: is empty, and WixSharp throws 'WiX binaries cannot be found'.

Fix by exporting WIXSHARP_WIXDIR via GITHUB_ENV in the Configure runner
step. WixSharp checks this env var as a fallback at runtime, reliably
finding WiX 3.14 binaries regardless of NuGet cache state.
@CBenoit Benoît Cortier (CBenoit) merged commit fc3b46f into master Apr 20, 2026
41 checks passed
@CBenoit Benoît Cortier (CBenoit) deleted the ci/fix-github-releases branch April 20, 2026 14:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

3 participants