This repository contains a complete AppVeyor CI configuration solution which enables easy, one-step, Windows-based testing of Perl distributions.

1. Add the single supplied .appveyor.yml file to the Perl distribution being tested.
2. Create an AppVeyor project which observes the Perl distribution's repository.

Optional extra steps

1. Enable "Skip branches without appveyor.yml" (located within the "General" section of the AppVeyor project settings).
2. Enable code coverage reports ...
   1. Create a project or projects on CodeCov and/or Coveralls which observes the distribution repository.
   2. Copy the API token value obtained from the observer project(s) into their respective environment variables (CODECOV_TOKEN and/or COVERALLS_TOKEN) within the AppVeyor project. These environment variables are set within the "Environment" section of the AppVeyor project settings. Note that the API token values are secrets. They should not be placed in the .appveyor.yml config file or committed to the repo, in any way. And they should be encrypted within the AppVeyor project settings tab (by clicking the lock icon next to each value).

.appveyor.yml is a single "drop-in" file which, when added into a Perl distribution, will add the ability to test and analyze the a user's Perl distribution within an AppVeyor CI Windows environment (ie, for the MSWin32 platform).

If either Build.PL or Makefile.PL is present in the distribution main directory, the module will be automatically built prior to testing, using the standard Perl build or make idiom. Testing will then be done with the respective usual idiom (either perl Build test or %make% test), with prove as a fallback for distributions without the traditional build tooling (eg, many dzil packages).

Distributions which lack both Build.PL and Makefile.PL, but which can be tested without needing non-CORE dependencies, should work "out-of-the-box", using the prove fallback method. If additional non-CORE dependencies are needed, a "cpanfile" or the DIST_EXTRA_DEPS configuration variable (see below) can be used to install any required modules prior to prove testing.

Alternate build and test methods are also possible via the use of configuration variables (detailed below).

Notably, there is no direct support for dzil building and testing. Support may be added in the future, but the current dzil module ecosystem (as of 2018-11) has many dependencies which won't install on MSWin32 environments. Until better MSWin32 support is available for direct dzil building and testing, prove fallback testing combined with the use of "cpanfile"/DIST_EXTRA_DEPS (for testing dependencies) can be a workable solution. Alternatively, the "Dist::Zilla::Plugin::MakeMaker" module could be used by authors to generate an ExtUtils::MakeMaker-compatible distribution.

If either a "cpanfile" or generated "Makefile.PL" (via "Dist:Zilla:Plugin::MakeMaker") is used, it must be stored in the distribution repository.

The optional file .appveyor_init.BAT and/or .appveyor_init.PS1 can serve as distribution-specific overrides of the AppVeyor configuration, especially (but not limited to) overriding global environment variables.

This hook allows use of the unchanged .appveyor.yml from this repository while still allowing distribution-specific configuration changes (eg, for CORE modules using set DIST_SUPPRESS_DEPS=1).

A sample .appveyor_init.BAT file is included in the eg directory.

The .appveyor_bin directory contains multiple helper scripts to streamline .appveyor.yml and to provide workarounds for various build issues (within both the AppVeyor and the Perl build/test processes).

This solution implements an "API" contract so that it can be reliably used into the future while still enabling change within the solution itself.

The "API" is detailed in the section below and specifies files and configuration variables that users can expect to remain available when using that "API" iteration. Two repository branches, "stable" and "canary", will always be available for each iteration of the "API", using the branch name as a prefix (eg, "stable.APIv1" and "canary.APIv1").

Any change to the noted file names or configuration variables will constitute an API change. If/when an API change occurs, the API version number will be incremented by 1 and new stable and canary branches will be generated (eg, "stable.APIv2" and "canary.APIv2"). Prior API branches will always be left in place for continuity.

The "canary" branch will receive more frequent helper updates with the (default) "stable" branch updating behind "canary" as the code becomes more time-trusted. The default .appveyor.yml configuration includes testing with both branches but allows failure of any "canary"-type branch so as not to break the test build. This helps test any "canary" changes widely without materially affecting test outcomes.

Options for choosing the configuration branch is detailed below (see CI_HELPER_BRANCH in the "configuration variable" section). Additionally, "vendoring" the helper scripts is discussed below in the "vendoring" section.

The current public "API" (APIv1) includes .appveyor_init.{BAT,PS1} and all files/directories within .appveyor_bin, excepting any files/directories that are prefaced with a leading underscore ('_'). All files and directories prefixed with a leading underscore ('_') are considered private and are not included in the "API" contract (ie, their names and function are allowed to change within the "API" branch). All contents of private directories are also considered private. Don't depend on private files or directories.

These scripts are named to correspond with specific AppVeyor CI phases and are listed in order of expected use.

These variables have intelligent defaults and can, in general, be left alone as empty strings. Modifications are usually only necessary for special circumstances.

CI_HELPER_BRANCH can be used to select between frequent helper updates (eg, "canary"), more stable code (eg, "stable" [the default]), or invariant (using a release TAG). Generally, from most to least stable ... [ "vendoring" (see below) > TAG > stable > canary > BRANCH ]. By definition, code updates and changes to the helper scripts are applied in the inverse order of "stability".

Perl_VERSION is obviously used to select between various perl versions for testing. Shorthand, "generic" versions can be used (eg, 5.8, 5.16, ...) and, for versions in the "known" set, will be expanded to an appropriate full version. Current "generic" and "known" versions can be seen in the #install.install-perl.PS1 script (located in the .appveyor_bin directory). Additionally, these "known" versions are available via mirror and will be downloaded automatically whenever the main StrawberryPerl source site is unavailable (see strawberryperl.com/issues#16, strawberryperl.com/issues#10).

Note that caching can drop the perl install time by about 10% to 20% (usually, a few seconds). Because this is such a small overall time savings and because the available cache size, at 1GB total across all projects, is too small to hold the multiple perl downloads, caching remains unused (see ref: https://www.appveyor.com/docs/build-cache/#cache-size-beta).

The listed variables are not in the "API" per se but are commonly used in testing by most Perl distributions. The table lists these configuration variables and their usual respective definition / action. But notably the true effects of these variables will be defined by the user's testing design and usually only matters to the author. If defined, these variables will be listed in the build log.

All the configuration variables (including utility and common user configuration) can be overridden by using the AppVeyor ...

Code coverage can be enabled by adding the CODECOV_TOKEN and/or COVERALLS_TOKEN to the environment variables of the AppVeyor project, on the AppVeyor site. These tokens are obtained from their respective sites.

Please note that these are secrets and should be treated as such. Neither of the token values should ever be included in the .appveyor.yml file or submitted into the distribution repository.

This repository can be "vendored" into a distribution by including both the .appveyor.yml configuration file and a copy of the .appveyor_bin directory at the root directory level of the distribution. During AppVeyor execution of the .appveyor.yml file, when the .appveyor_bin directory is found, the code within that directory will supersede and suppress cloning/downloading of the repository helper files.

Copyright 2017-2019 by Roy Ivy III. All rights reserved.

Licensed under the MIT License (a copy may be obtained from https://opensource.org/licenses/mit).