For some reason the action can no longer check if the URL generated in
the metainfo is reachable.
So to avoid keeping CI failing, local exceptions rule are
added.
Unfortunately it requires to keep a copy of exceptions already submitted
to Flathub.
As gersemi exists as a core Homebrew formula now, CI needs to use a
version-pinned formula to avoid sudden format check failures due to
possible "breaking changes" between gersemi versions.
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.
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.
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.
We're currently using peter-evans/create-pull-request v6.0.0 which has a
known issue that affects our services-validator action when attempting
to update an existing PR. This issue was fixed in v6.0.1, but we can
update to v7.0.2.
cmake-format was replaced with gersemi in
19d3e30a3a and this action is now unused
(and wouldn't work anymore anyways due to the removal of the
./build-aux/run-cmake-format script).
This commit includes build-aux README fix-ups where the now nonexistent
run-cmake-format script was mentioned and the run-gersemi script was
misspelled.
Work around a bug with too many open files in versions before v4.3.5 and
also in v4.3.6 due to a revert. The relevant error message is:
Error: EMFILE: too many open files
We applied the same workaround to release/30.2.
By not specifying a checkout ref, actions/checkout does a second
checkout when this action is invoked by the Publish workflow (release
event). When this happens, it checks out the commit object from the tag,
and git can no longer locate the annotated tag that contains the release
notes. This then causes the release notes to be just the commit message
and not the annotated tag message.
The sparkle-appcast action in general and this actioo when invoked via
the Dispatch workflow do not have this issue, and they both specify the
tag as the ref.
