https://wiki.mudlet.org/index.php?action=history&feed=atom&title=Random_notes_about_CI_ScriptsRandom notes about CI Scripts - Revision history2026-06-14T14:32:15ZRevision history for this page on the wikiMediaWiki 1.35.0https://wiki.mudlet.org/index.php?title=Random_notes_about_CI_Scripts&diff=15685&oldid=prevSlysven: Initial document - incomplete2020-10-16T22:14:29Z<p>Initial document - incomplete</p>
<p><b>New page</b></p><div>We have about four different build processes configured for the AppVeyor/Travis CI builds:<br />
* '''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.<br />
* '''PTB''' - ''Public Test Build'' (though that B sometimes gets read as ''Beta'').<br />
* '''Development''' - A build of the 'development' branch code that is prompted by something being merged into it.<br />
* '''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.'''†'''<br />
<br />
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.<br />
<br />
The second one is produced as a result of a cron (scheduled job) setting on the CI platforms:<br />
* 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 [[https://github.com/atifaziz/NCrontab/wiki/Crontab-Expression 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<br />
* Travis - ''tbd''<br />
<br />
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.<br />
<br />
<br />
<br />
<br />
'''†''' 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.<br />
<br />
== Windows AppVeyor ==<br />
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.<br />
<br />
== Linux & MacOs Travis ==</div>Slysven