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.
Explicitly label the Windows x64 artifacts and assets as such to
disambiguate them from the Windows arm64 artifacts and assets.
Subsequently, make the windows-patches action able to take an
architecture argument which defaults to x64. This will help enable later
usage for Windows arm64.
Lastly, rearrange some of the Windows lines in push.yaml to have a
consistent order.
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.
I discovered while investigating a separate caching issue that the read
command was not assigning ref correctly. This is inconsequential since
we do not use that value, but it led me to look up the documentation for
the GitHub CLI extension used here, gh-actions-cache.
The GitHub CLI extension gh-actions-cache is deprecated as of October
2024. The recommendation is to use the offical gh cache command. That
command produces slightly different output, so adjust the read command
accordingly.
By adding the workflow_dispatch trigger, the scheduled workflow can
also be manually triggered if the scheduled run failed to run due to
scheduling issues or because of an error that might have been fixed
since then.
actions/cache versions other than v4, v3, v4.2.0, and v3.4.0 were
deprecated and gradually sunset through February.
@actions/cache versions other than v4.0.0+ were deprecated and gradually
sunset through February.
See:
* https://github.com/actions/cache/discussions/1510
* https://github.com/actions/toolkit/discussions/1890
flathub-infra/flatpak-github-actions/flatpak-builder set its
@actions/cache dependency version to "^3.2.3" and was last updated on
July 29, 2024. As a result, its yarn.lock file specifies version
"3.2.4", which is no longer supported and does not work.
Update flathub-infra/flatpak-github-actions actions now that they have
updated their @actions/cache dependency.
The "provisioning" and "notarization" steps that set the
"haveProvisioningProfile" and "haveNotarizationUser" outputs
respectively only run if "haveCodesignIdent" has evaluated to true in
the prior "codesign" step.
This means that if "haveCodesignIdent" is false, the other two outputs
are left unset, evaluating their "value" expressions (and as such the
output of the action) to empty instead of false.
This issue was found in the equivalent action in obs-plugintemplate. As
that action is basically a mirror from the obs-studio action, let's fix
it here too.
Once upon a time there was the idea to enable use of Ccache for
Windows builds on CI as well, but to achieve this the project would
need to switch to clang-cl.exe as its compiler and use an additional
post-build step to generate PDBs from binaries.
Using a different compiler for continuous integration than for building
release builds defeats the purpose of CI however, so the idea was
dropped.
Ryan Foster