Skip to content
This repository has been archived by the owner on Oct 25, 2022. It is now read-only.

AppVeyor

Jump to bottom
Jakub Bereżański edited this page Oct 16, 2020 · 55 revisions

You can make AU updater run on AppVeyor.

For this to work you must create account and then create the .appveyor.yml file in the package repository root. AU provides an AppVeyor build template that you can use to quickly get started.

            Setup  -  Setting up the force test  -  Sending commands to AppVeyor  -  Notes

Setup

  1. Go to AppVeyor and sign up/sign in. https://ci.appveyor.com
  2. Set up new AppVeyor project: https://ci.appveyor.com/projects/new
  3. Go to project settings and ensure the following items are set (these items cannot be configured in the yaml file):
    • In Build Schedule, set up the cron job (a.k.a. Scheduled Build) - if we want to run this three times a day - set it like this: 5 */8 * * *. This ensures it runs at 06:05, 12:05, and 18:05. You can use crontab.guru for help with this. Note that you may need to contact AppVeyor team to enable cron job.
    • Ensure Skip branches without appveyor.yml is checked.
    • Click Save.

This is enough to make AppVeyor run the build. However, if you want it to use all AU plugins you need to set few environment variables. Edit appveyor.yml environment and create secure variables. Go to encrypt tool and log in, then:

  • Get encrypted values for
    • Github password or api token (only if you use non anonymous Gist and/or Git plugins).
    • Email password (only if you use email for notifications).
    • Chocolatey API key (mandatory).
  • Edit the .appveyor.yml to add those values in and also fill in all other non-secure variables.

Its advisable to disable build on push request as some plugins will fail due to the way AppVeyor handles secrets:

Secure variables are not decoded during Pull Request builds which prevents someone from submitting PR with malicious build script displaying those variables

Go to your Github repository settings - Repository Settings -> Webhooks - and edit the AppVeyor hook then uncheck Pull request.

Setting up the force test project [optional]

You may want to periodically invoke the force test of all or subset of packages. In this test, all packages are forced with push disabled and we can see how the packages behave during complete update procedure.

This run is done by the script test_all.ps1 in the repository root and it runs within its own project. This project uses the same .appveyor.yml so its very quick to setup once the first project is created and set:

  1. Create a new AppVeyor project that connects to the same repository and add test somewhere in its name - for example, name it au-packages Force Test. The word test in the project name will be seen when build runs and appropriate code will be executed.
  2. Create a new gist that will hold test results and set environment variable gist_id_test.
  3. We don't want this project to build on commit as it will block the main updater, so we need to remove AppVeyor repository web hook it just created. Find the Id of the hook (Project Settings -> Webhook URL) and go to your Github repository settings to deactivate this web hook.
  4. Add schedule when you want to run the test, make it different then that of updater as they will wait for eachother otherwise due to AppVeyor free account limitiations. For example, to run once a day at 4AM set to 0 4 * * *.

You will be able to run this test manually or as a scheduled build. You can link this gist to your updater gist by specifying its URL via UserMessage parameter of the Report plugin.

Sending commands to AppVeyor

You can send commands to build server using specific keywords on the first line of the commit message.

NOTE: These commands are handled by the .appveyor.yml and update_all.ps1 files in your repository. Please check the template repository from time to time to see if any new features were added to those files. You will need to replicate any such additions manually to your repository. If you copied those files a long time ago and never updated them, some functions described here may behave differently or not work at all.

Forcing update of set of packages

You can force update of specific packages by sending specially crafted commit message keyword:

git commit -m '[AU pkg1 pkg2:ver2 pkg3\stream3 pkg4\stream4:ver4 ... pkgN ]' --allow-empty

which will trigger

./update_all.ps1 -ForcedPackages 'pkg1 pkg2:ver2 ...'

that will force update for given packages (equivalent to setting $au_Force). Invalid package names are ignored, stream and/or version is optional.

Specifying a version (after a colon) is equivalent to setting $au_Version prior to running update.ps1 for that package. Specifying a stream (after a backslash) is equivalent to setting $au_IncludeStream. If both stream and version are specified, the stream must be first. If a stream is not specified for a package with streams, the first stream returned from au_GetLatest will be processed.

If a package is specified multiple times in the command (possibly with different versions and/or streams), no error will be displayed, but only the last entry will be used. This is an easy trap to fall into when wanting to publish several streams of a package; it must be done with each stream in a separate commit.

NOTE: In order for this NOT to produce and push a chocolatey package with version set to fixed choco notation you need to set the package version to lower then current RemoteVersion (0.0 for example). On the other hand, if you want the fix notation, you should set the package version equal to RemoteVersion.

Pushing specific automatic or manual packages

You can push any package on any repository path using simple push command:

git commit -m '[PUSH pkg1 pkg2 ... pkgN ]' --allow-empty

This will choco pack the package and use AU function Push-Package to publish it to the community repository. You are responsible for setting correct nuspec version. Prior to pushing, the update.ps1 script will be invoked if it exists in the package directory. No report is available, build output should be enough. Invalid package names produce warnings but build will not fail.

Unlike [AU ...], this command accepts only package ids, without any additions such as version or stream.

Notes

  • If you don't want to always use the latest AU release you can specify the AU version in the appveyor.yml that you want to use.
  • AppVeyor secrets are not decrypted on branches which means some of the AU features do not work on branches (for example gist plugin).

Function & Variable Reference

Clone this wiki locally