Create automated Windows installer builds

[chrissimpkins]

TODO:

• create automated Windows installer build when new Hack font builds are pushed to this repository

[chrissimpkins]

@texhex let's discuss here

[texhex]

I would like to propose the following:

1. Create new Hack fonts that are labeled DEV in both the font name (Hack DEV Regular etc.) and also have the DEV inside the filename (e.g. Hack-Regular-DEV.ttf)

2. This would allow to create a second repo (Hack-Windows-Installer-DEV) that could install these fonts BESIDE the existing "normal" Hack fonts.

3. This would allow users to give a new DEV release of Hack a quick try (by selecting "Hack DEV"), and if it doesn't work they just select "Hack" again. No re-installation etc. needed.

4. If possible we should find a way that a new push to the /Hack foundry causes a pull from the Windows-Installer-DEV repo, which would cause an automatic AppVeyor build so a setup.exe for the DEV fonts would be ready in about 5 minutes.

[chrissimpkins]

@texhex IMO this should be a post-compilation change in the font naming over in the new repository rather than a new set of duplicate build files that are released here with a different name scheme. Please let me know where you intend to support this tooling for automated builds and I can PR a Python script to perform the renaming (both OpenType tables and font paths) for now. It will require a new fontTools Python library build dependency in your Appveyor script. If you can automate the preparation of a new installation tool to take files from build/ttf and create a new installer anytime that there is a set pushed a non-master branch, then your proposed approach will work. We are commonly working on these issues outside of the dev branch and the testing happens before the compiled font files hit the dev branch.

The workflow on your end would look like this:

• pull all build/ttf/Hack-*.ttf files from any non-master branch when changes are pushed (note: there is not an automated build in build/ttf with every commit at the moment)
• run post-compilation Python script that renames fonts to whatever naming scheme you would like Hack-DEV Regular, Hack-DEV Italic, Hack-DEV Bold, Hack-DEV BoldItalic and associated new unique file paths (I can make these constants in the script that you can define however you'd like).
• create new build artifacts for Windows installs via Appveyor so that they are available to Windows users who would be testing changes and need to have access to pre/post testing renders with two installed fonts.

My longer term goal is to create a new tool that will modify OpenType name tables so that users can easily and directly (rather than requiring modification of source + rebuild) change the names displayed to the end user in the OpenType table of build products. This will support users who build one off modifications like a change in a single glyph and then want to release it under a different name (rather than modify the source to do this prior to builds). Font paths can be redefined using standard scripted operating system file path renames (e.g. mv, etc) or for those who do not need to automate this, OS dependent GUI file viewing/path editing tools (e.g. Finder).

Let's make sure that our approach for Windows testers is documented (either here or in the new installer repo) so that we have a site that can be used to link instructions rather than manually explaining the process for testing each time that we encounter it.

See #185 for associated issue report.

[chrissimpkins]

@texhex Also, if there really is a way to build the installer with font files that are pushed in a branch dependent way, it would be useful to (and I assume that you are planning this based upon your comment) also automate the Windows installer intended for releases as well! This would be fantastic if this happens within minutes of a new release being pushed to the repository.

As something along these lines materializes, let's review the Install sections of the README documentation here that currently point to your Windows Installer repo for all Windows users. Will confirm that all information for Windows installs remains current with the changes for routine releases that take place.

[chrissimpkins]

It also struck me that a much simpler alternative approach if you don't/cannot automate things in this fashion, is that I would be happy to PR new development files to the Windows development installer repo to build the installer tool. If you have a consistent directory for the files, the PR will run against Appveyor and the user could obtain the installer built with the files in the PR?

Let me know what approach works best for your Tex.

[texhex]

@chrissimpkins OK, I think now I understood it.

My first impression was that the Hack repo will also include DEV builds with different names and versions. But the DEV builds will only have the SHA1 hash as version, but are else still "Hack" (for the font name and the version).

This then really means the AV scripts needs to take the pushed fonts, change the file name and also apply new names. So I think for the start the manually push approach will be used and the AV script will be extended to make the necessary changes to the file name and the name table entries to allow a side-by-side installation with an existing Hack font.

Let me create the repo this week and after it I will drop you a note so you could push the PY scripts.

Regarding the automation:

In theory, this should be easy. Set up a webhook if something new is pushed to Hack, and push a simply "trigger" file to the Hack-Windows-Installer-DEV repo. The AppVeyor script could then pull the newest fonts from the Hack repo before working on them with the PY script. But let's move that to a later date, first let's see that we actually get a working auto build system.

[chrissimpkins]

@texhex sounds like a plan! poke me when / if anything that I can do

[chrissimpkins]

@texhex

v3.000 release files are now in master and ready for Windows installer. ty!

[texhex]

@chrissimpkins Thanks, installer updated. Version v1.4.1 is ready for use.

[chrissimpkins]

@texhex excellent! thanks Tex!

[chrissimpkins]

@texhex cleared v3.0 milestone and will leave this open so that we can continue to discuss the automated installer build process for the Windows installer. If easier/better to have the conversation on the Win installer repo, let me know and we can close this and continue there.