texhex
commented
5 years ago The only experience I had so far with CI/CD is within the Hack-Test-Win-Installer that automatically creates a setup EXE as soon as a push is done.
Given that you know your tool chain well, an AppVeyor is also offering Linux machines by now, would it be possible that you give that a try?
If it works out, the build artifacts (generated fonts) could be pushed to this repo as "Pre-Release" and would be ready to be tested. I use the same method for the test installer and it works fine.
chrissimpkins
Problem: Hack releases are currently tied to my schedule and availability, and are currently being batched across large numbers of commits that make the release process (manual visual proofing, hinting, QA testing) arduous. This leads to foot dragging on my end and does not afford users the opportunity to immediately use contributions from project developers or to effectively test work in progress. The release design is the way that it is so that I can apply the brakes and confirm the quality of the fonts before a set of builds from a given commit is pushed out under the title of a "release". Much of this work to date has been manual and laborious. Much has changed with tools to support QA testing since the original workflow was put into place and the current design is a poor one that can be improved upon.
I suggest that we solve this by looking into a continuous deployment approach that permits us to merge new work into a branch (or simply apply this to any branch) that is built into a new set of usable deployed "beta/WIP" fonts on every commit. These will be fully mastered with the current state of our automated, scripted build process, QA tested with available automated tooling, and released as "pre-release" files with an understanding that humans may not have viewed the fonts, a shortcoming which at the moment is a mandatory part of the QA process in production-level typeface development. Obviously not something that you put into production use in situations where the renders really matter, but always available for cases where that level of quality assurance is not mandatory. We then create a production release schedule on some interval that involves the manual viewing steps based upon the commit history since the last release push. Ideally this approach provides cross-platform installation support and builds on the capacity offered by tools like our (currently release only) Hack Windows Installer that is developed by @texhex. I think that this may strike a better balance to address this issue and make the "release" something that is only a consideration for those who need production quality builds.
To make this happen, I need help from those out there who have experience with CD so that we can discuss how to approach this and pull the necessary pieces of the puzzle together. I am prepared to begin work on this immediately and anyone who would like to participate, irrespective of your experience in type software development, is very welcomed to join this effort.
Please use this thread to discuss.