The generate-docs action started failing, presumably because it is using
Debian Buster. Update the pinned commit for the third-party
totaldebug/sphinx-publish-action to hopefully fix this.
When 31.0.4 was published, it published to the Flathub beta channel,
which overwrote the running 31.1.0 beta/rc. This was due to an
assumption that we would not publish an out-of-band hotfix release once
we had moved to a new beta release cycle. To prevent this in the future,
we can check the last two releases to see if they are different tag
series and if one is a prerelease.
When 31.0.4 was published, it published to the Flathub beta channel,
which overwrote the running 31.1.0 beta/rc. This was due to an
assumption that we would not publish an out-of-band hotfix release once
we had moved to a new beta release cycle. To prevent this in the future,
we can check the last two releases to see if they are different tag
series and if one is a prerelease.
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.
We had previously pinned this to avoid a bug in the action. Said bug is
marked fixed as of actions/upload-artifact v4.4.1, so let us unpin this
and use actions/upload-artifact@v4 like we do everywhere else.
References:
- df742ed032
- https://github.com/actions/upload-artifact/releases/tag/v4.4.1
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.
