After bf48a84d1c, the scheduled nightly
runs began to fail because the filenames of the artifacts had changed.
This would also have caused uploads on tag to fail. Explicitly specify
the asset architecture here. Windows arm64 builds are still ignored for
Steam Upload for now.
The recent addition of WoA builds caused Steam Upload to fail. Be more
explicit about what file to unzip and what files to remove to get the
Steam Upload for Windows x64 working again.
Note that this does remove all Windows zip files and not just the x64
ones. This is because we don't currently process the WoA files, and the
intent here seems to be to clean up all unnecessary files before running
the actual upload step. This will have to be updated if/when this is
updated to process WoA files.
We're currently using CyberAndrii/steam-totp c7f636bc64 which is
based on the deprecated node16. This was fixed in 45775c3219, so let's
update to that commit.
We're currently using CyberAndrii/setup-steamcmd b786e0da44 which is
based on the deprecated node16. This was fixed in 29e114af03, so let's
update to that commit.
* Add provisioning profile support for macOS builds
* Fix internal variable names in macOS packaging script
* Add fallback git reference for validator actions
* Add required repository environment to documention deployment jobs
* Pass GitHub pull request number to GitHub CLI explicitly
* Use shortened commit hash for Steam nightly versions
* Ensure that concurrency check for tagged push uses a boolean value
* Update disk image creation function to retry ejection on CI
* Fix repository checkout in Flatpak publish action
* Fix output paths and filenames of generated appcast XML files
* Limit notice about notarization password use to non-CI usage
* Remove architecture-specific suffix from appcast artifact name
steamcmd seems to have a quirk where it cannot find a file in the
current working directory on macOS, but requires the absolute path
to the file instead - using the `:a` Zsh modifier yields the absolute
path of a valid filename in the current directory scope.
GitHub's CLI utility is not capable of downloading artifacts generated
by the workflow job it is being run in itself. Thus the official
repository action is needed.
Ryan Foster
derrod
PatTheMav