Remove inaccurate and redundant signing determination code from build system #2567
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
The "build" workflow signs the macOS and Windows builds of the application. The signing process relies on access to GitHub Actions secrets. For this reason, the workflow is configured to only sign the builds when it has access to GitHub Actions secrets to avoid spurious failures of the workflow that would otherwise be caused by signing failure.
A flexible general purpose system for accurately determining whether to attempt signing of a build was established years ago (#1115) However, when the Windows signing system was reworked to support the new "eToken" hardware authenticator-based approach (#2452), that system was circumvented, causing workflow runs triggered by pull requests to fail spuriously (#2545). When this was later discovered, an inferior redundant system was added (#2554) specific to the Windows build instead of just using the existing system.
This redundant system determines whether to sign based on the value of the
github.event.pull_request.head.repo.fork
context item. That is effective for the use case of the workflow being triggered by a pull request from a fork (for security reasons, GitHub Actions does not give access to secrets under these conditions).However, there is another context under which the workflow might run without access to the signing secrets, for which the use of context item is not appropriate. It is important to support the use of the workflow in forks of the repository. In addition to the possible value to hard forked projects, this is essential to allow conscientious contributors to test contributions to the build and release system in their own fork prior to submitting a pull request. The previous configuration would cause a workflow run performed by a contributor in a fork to attempt to sign the Windows build. Unless the contributor had set up the ridiculously complex infrastructure required to perform the signing for the Windows build (#2452), which is utterly infeasible, this would cause the workflow to fail spuriously:
Change description
Remove the inferior and redundant signing determination code and use the previously established system for all targets.
This makes the workflow easier to understand and maintain.
Reviewer checklist