AppVeyor - Continuous Integration service for Windows

AppVeyor is a continuous integration service for Windows.
From their website:

​AppVeyor aims to give powerful Continuous Integration and Deployment tools to every .NET developer without the hassle of setting up and maintaining their own build server.

They offer their service free of charge for Open Source projects, like Trac.

We use it for automating our builds on Windows. See TracDev/AutomaticBuilds for the other automated build services we use.

It works together with the git repositories hosted on GitHub, like our mirror and their forks:

• Builds for the branches in the ​Trac mirror
• Builds for developer topic branches: ​cboos, ​rjollos, ​jomae

Settings

Common settings

The configuration and the build steps are taken directly from the repository:

• a configuration file .appveyor.yml,
• its companion PowerShell script contrib/appveyor.ps1, which contains some common utilities and settings, and one function for each build step

Per-project settings

A project can be configured to build all new branches, ​or just some. Also, in the settings, don't forget to specify that the appveyor.yml file is named .appveyor.yml.

Another useful tip is that a build ​can be skipped if the last changeset pushed contains [skip ci] in its commit log message.

Known issues

Test failures

There are still a number of test issues only seen on AppVeyor that need to be resolved before getting a "green" build, mostly SQLite related.

See all ​related tickets.

If you are on Windows, you can reproduce the build locally the same way AppVeyor would do it, from a PowerShell console. In some cases, if the problem only happens on AppVeyor build workers, it can be useful to ​run the test manually there via RDP, the procedure is similar.

Note that you may need to perform a few preparation steps first in that shell:

• enable sourcing local scripts by setting the execution policy to "unrestricted",
• backup your Makefile.cfg if you have customized it, as it will be overwritten by the scripts
• make sure you have a GNU make.exe in the Path (grab ​ezmake for example; on AppVeyor workers you have ​plenty of choice)
• set the environment variables that are normally set up by the "build matrix" in the configuration file, i.e.
  • PYTHONHOME, to point to the Python version you want to use
  • TEST_TRAC_DB_URI, as usual (see TracDev/UnitTests for details)
  • SVN_BRANCH, to indicate the "base" branch (e.g. if you forked a topic branch from 1.0-stable, set it to 1.0-stable)

For example:

> cd 1.0-stable
> cp Makefile.cfg Makefile.cfg.custom  # better safe than sorry...
> Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope Process
> $env:PATH = "$($env:PATH);C:/Dev/ez-make-4.1/bin"  # example
> $env:PYTHONHOME = 'C:\Python27'                    # example
> $env:TEST_TRAC_DB_URI = 'sqlite:test.py'           # example
> $env:SVN_BRANCH = '1.0-stable'
> $DebugPreference = "Continue"        # to see the Appveyor API calls
> . .\contrib\appveyor.ps1             # load the Trac-* functions
> Trac-Install                         #  - installs dependent software
> Trac-Build                           #  - creates DB, `make compile`
> Trac-Tests                           #  - `make unit-test`, `make functional-test`

Project not building

It can happen that the build won't trigger, and no matter what you do about it, the jobs stay in the "queued" state forever instead of just a few minutes.

If this happens, ask the support to do a global reset on the project. They're very friendly and responsive.

But frankly, this happened once at the very beginning, when setting up the automatic builds. Since then, it's running flawlessly.