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.
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.
