Random notes about CI Scripts

We have about four different build processes configured for the AppVeyor/Travis CI builds:

• Release - the final one that produces the official (signed if we can get certification sorted out - it is currently a long painful process getting our Windows one renewed!) version that end-users will (hopefully) want to download and use.
• PTB - Public Test Build (though that B sometimes gets read as Beta).
• Development - A build of the 'development' branch code that is prompted by something being merged into it.
• Testing - A build of the code as it stands with all the commits of a Pull-Request on-top of the development branch of the code.†

The first one is produced after Vadim (our BDFL) edits the top-level CMake and the QMake project files (./CMakeList.txt and ./src/mudlet.pro) to remove the normally present -dev value for the APP_BUILD variable. That triggers different behaviour when the commit that pushes the change to the main Mudlet GitHub repository. It also requires that there is a Git tag applied at the same time - we have been using Mudlet-x.y.z where x, y and z are the major, minor and patch numbers respectively.

The second one is produced as a result of a cron (scheduled job) setting on the CI platforms:

• AppVeyor - log in to the site, navigate to the Mudlet project (click on the top white on black "Projects" and then on the "Mudlet" line several icons will appear on hovering on it - click the rightmost "cog" icon to get to the Settings page. The top most left tab "General" has a field about two thirds of the way down labelled Build schedule which accepts a 5 element [crontab] value that specifies when the job should be run. We currently use 0 0 * * * which translates to "at the 0th minute of the 0th hour of every day of the month (1 to 31), every month (1 to 12), for every day of the week (0=Sunday, 6=Saturday). For this job AppVeyor defines the environmental variable APPVEYOR_SCHEDULED_BUILD to "True" if the build runs by scheduler More details here: https://www.appveyor.com/docs/build-configuration/#scheduled-builds
• Travis - tbd

The last two are not so obvious to tell apart but the testing ones have an additional -PR1234 element in the zip file or app-image that is produced.

† The changes should be piled on top of the development branch at the time the PR was started (if the coder is doing the right thing and starting a new branch from there) but the GitHub webpage for the PR will make it clear if the code can or cannot be combined with the development branch code as it is currently either by rebasing (preferred) or squashing (alternative recommended where there is a large number of commits in the PR). If the latter is done it is really helpful if the person doing the merge takes a moment to clean up the commit message (in plain text NOT the markup that GitHub uses) as otherwise one can end up with a long message comprising a list of commit messages which may not make sense to anyone other than the committer - and that message gets written into the git history for good.

Windows AppVeyor

The package production builds ("version uses the native(?) Nuget tool to read a mudlet.nuspec in the mudlet/installer repository files and uses that to convert all the files in a specific location into a specially constructed zip archive that has a .nupkg extension. squirrel.windows then converts that file into a setup.exe installer which is intended for initial installation of the packaged application and also a -full.nupkg version which presumably has a few extra squirrel bits and, if it can detect a previous version of the same project a -delta.nupkg which is a update file that is much smaller (to download) and contains the data to patch the previous one to update it to the new version.