CI

Appveyor

As a hybrid C#/PowerShell package, PrtgAPI uses a sophisticated build process to test and deploy for Visual Studio and PowerShell environments

All config files required by the Appveyor build process are hosted on Gist. Hosting the config on Gist allows the config to be developed separately, without clogging up the build repo with commits whenever a config change is made.

Files are referenced within Gist by accessing <gist path>\raw\<file name>. This is important as clicking the "Raw" button next to each file within Gist only gives the path of that particular commit. When making changes in Gist, there can sometimes be a delay of 5-10 minutes before the raw version refreshes. Keep this in mind when developing your configuration; it may be faster to configure it first within Appveyor, then move it out when it's working.

When a new commit is pushed to the PrtgAPI repo, the following actions occur

1. Appveyor clones the repository and then builds Release configuration of all projects in the solution
2. A script is executed to detect the version of the build that was just compiled, and update the Appveyor version to match
3. Pester and MSTest Unit Tests from the PrtgAPI.Tests.UnitTests solution are executed against the main project
4. If the tests are successful, the NuGet Build script from Gist is executed to compile the separate NuGet Packages required by nuget.org and the PowerShell Gallery
5. The NuGet Build script tests each of the NuGet Packages can be imported successfully into PowerShell and that a Cmdlet can be executed
6. During this process, the PowerShell Module Manifest is updated to include explicit references to all Cmdlets, Functions and Aliases. For the package destined for nuget.org, the path to the DLL relative to the Module Manifest is also patched up, allowing the nuget.org package to be used for both Visual Studio and PowerShell
7. If all steps complete successfully, the NuGet Packages are moved to a location to be scooped up by the artifacts sweeper.

In order to prevent uploads to live repositories during the build process, a temporary filesystem repository is created. This allows for easy cleanup after the build has completed, and facilitates testing of the build script on development machines.

As PrtgAPI updates its Module Manifest to include the names of the Cmdlets, Functions and Aliases included within the module, the build is configured to use the WMF 5 image. This is required as Update-ModuleManifest is broken in PowerShell 5.0, which is included in the Visual Studio 2015 image. At time of writing, the Visual Studio 2017 image cannot be used, as the RTM T4 Template compiler does not work.

Artifacts

Once a build has completed, all artifacts are available to be manually inspected. Once a build has been given the all clear, it is uploaded to nuget.org and powershellgallery.com.

Four artifacts are produced by the build process

• PrtgAPI.<version>.nupkg - nupkg for upload to nuget.org
• PrtgAPI.<version>.symbols.nupkg - symbol package for upload to symbolsource.org
• PrtgAPI.<version>_PowerShell.nupkg - PowerShell package for upload to powershellgallery.com
• PrtgAPI.zip - Portable version for manual installation

Appveyor is configured with two deploy environments: NuGet and PSGallery. Each of these environments is configured as follows

NuGet

• API key: <your API key>
• Artifact(s): /(^((?!_PowerShell).)*)\.nupkg/

The NuGet artifacts expression filters for all artifacts ending in .nupkg not preceded by _PowerShell. This allows Appveyor to detect only the PrtgAPI.<version>.nupkg and PrtgAPI.<version>.symbols.nupkg artifacts, for upload to nuget.org and symbolsource.org respectively.

PowerShell

• NuGet Server URL: https://powershellgallery.com
• API key: <your API key>
• Do not publish symbol packages
• Artifact(s): /.*_PowerShell\.nupkg/

The PSGallery expression filters for all packages ending in _PowerShell.nupkg. This allows Appveyor to exclude all other packages incompatible with PowerShell Gallery.