Link to issue number:

Closes #16216
Fixed #8806 (Issue discovered after merge)

Summary of the issue:

Currently, for a developer to make a private AppVeyor build of NVDA, requires maintaining different build scripts, in addition to an intricately modified appveyor.yml file, and feeding them to AppVeyor on every build.

This PR removes much of the difficulty from private AppVeyor builds, by making the build process more configurable in appveyor.yml, without having to modify the build scripts at all to make a basic build work.

In addition, it adds a few sensible state checks to a couple build scripts.

It tries to avoid changing any of the existing logic, except where an if condition could be anded with another to achieve the desired result.

Description of user facing changes

None

Edit after merge: developer usage documentation can now be found in project_docs/dev/buildingNVDAOnAppVeyor.md.

Description of development approach

• appveyor.yml:
  • Move the environment section above the init section.
  • Added a scons_publisher variable, to avoid hard-coding "NV Access" in the scons variable script. Those doing private builds should change it to reflect their (org) name.
  • Added a feature subsection to the environment section. Included features to control:
    • building symbols,
    • Uploading symbols to Mozilla,
    • building the appx,
    • crowdinSync, and
    • package signing.
  • (For private builds, all of those features should be commented out, except, optionally, the one for building symbols.)
  • Added logic to check the setting of the buildSymbols feature before building symbols.
• appveyor/scripts/buildSymbolStore.ps1: Added a test for feature_buildSymbols.
• appveyor/scripts/deployScript.ps1:
  • Make symbol upload dependent on both the buildSymbols and uploadSymbolsToMozilla features being set in appveyor.yml.
  • Cause crowdin synchronization to be dependent on its feature from appveyor.yml.
  • Only deploy to the NV Access server, if it's an nvaccess owned repo.
• appveyor/scripts/setSconsArgs.ps1:
  • Use the scons_publisher variable from appveyor.yml to designate the publisher, instead of hardcoding in the script.
  • Don't include cert options if not signing based on feature in appveyor.yml.
  • Respond to the buildAppx feature in appveyor.yml.
• appveyor/scripts/pushPackagingInfo.ps1: Change the appVeyor message with the exe link to mention a "branch" instead of a "PR", if no PR number is set in the build. It is assumed that most private builds will be for branches, not PRs against their own clone.
• appveyor/scripts/decryptFilesForSigning.ps1: Do not attempt to decrypt files if signing feature is not set in appveyor.yml.
• appveyor/scripts/logCiTiming.ps1: added a test to exit successfully if the timing record file is not found.

Regarding the last: originally I included a feature to disable CI timing checks. I decided that feature was unnecessary so reverted it, but I kept the change to detect the missing timing file and silently exit rather than failing hard, since it makes sense that something else may cause that file not to exist, and we wouldn't want the build failing over it.

Testing strategy:

Built several versions of NVDA with various combinations of the features disabled, and reached a successful build. Enabling any of them (except buildSymbols) on a non-NV Access build, causes a failure of one kind or another, only sometimes resulting in an executable being made. This is as expected and intended.

This PR built successfully in an NV Access configured environment.

Known issues with pull request:

None

Code Review Checklist:

• Documentation:
  • Change log entry
  • User Documentation
  • Developer / Technical Documentation (In Add Documentation of the AppVeyor build process for NVDA forks #16293))
  • Context sensitive help for GUI changes
• Testing:
  • Unit tests
  • System (end to end) tests
  • Manual testing
• UX of all users considered:
  • Speech
  • Braille
  • Low Vision
  • Different web browsers
  • Localization in other languages / culture than English
• API is compatible with existing add-ons.
• Security precautions taken.