Make it easier for devs outside of NV Access to utilize the Appveyor build process

[XLTechie]

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.

[XLTechie]

Regarding the developer/technical documentation point in the documentation checkbox above: I already have the developer documentation from my previous how-to on doing Appveyor builds of NVDA. I would need only to simplify it to account for these changes, and could then either contribute it to the WIKI, the non-wiki docs, or make it part of the developer guide (which I do not think is the correct approach).

Regardless of where it should go, a documentation PR will come shortly after this one, if this work is successful and approved.

[AppVeyorBot]

• PASS: Translation comments check.
• PASS: Unit tests.
• PASS: Lint check.
• FAIL: System tests (tags: installer NVDA). See test results for more information.
• Build (for testing PR): https://ci.appveyor.com/api/buildjobs/8rbjfukbcr87w3ol/artifacts/output/nvda_snapshot_pr16221-31329,c849cfc5.exe
• CI timing (mins):
  INIT 0.0,
  INSTALL_START 1.1,
  INSTALL_END 1.0,
  BUILD_START 0.0,
  BUILD_END 31.2,
  TESTSETUP_START 0.0,
  TESTSETUP_END 0.3,
  TEST_START 0.0,
  TEST_END 0.8,
  FINISH_END 0.2

See test results for failed build of commit c849cfc5d0

[XLTechie]

I would just like to point out, that situations like @mltony's #16270, are a good potential reason to approve this. Being able to build in the same CI environment NVDA uses, isn't valuable only for private purpose builds and usual development, but also for debugging actual issues with, and playing with variations in, the CI process.

[seanbudd]

For documentation, I would encourage a new file in projectDocs\dev\CICD.md linked from projectDocs\dev\contributing.md and projectDocs\dev\readme.md

[XLTechie]

Thanks Sean, and I like the phrasing tweaks. Docs on the way.

[XLTechie]

@seanbudd you wrote:

For documentation, I would encourage a new file in projectDocs\dev\CICD.md

Would you accept an alternate name? I propose buildingNVDAWithAppveyor.md. I suggest this, because CICD is general. There may come a time when I or someone else, wants to document building with other CI platforms, especially GitHub Actions. I do not have plans for working on that this year personally, but it is on my long term radar. If another platform is documented, it will be unwieldy to include that documentation in the same CICD.md file, as the steps will be significantly different. I will continue with the PR using CICD.md unless I hear from you that I have a go ahead on the other name.

[seanbudd]

Sure thing, the name was just a suggestion