AppVeyor で cygwin setup に失敗するようになったので対応した

2022/05/20 ごろから AppVeyor で Cygwin のセットアップが失敗するようになりました。

Starting cygwin install, version 2.900
User has backup/restore rights
Current Directory: C:\cygwin/var/cache/setup
Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access.
root: C:\cygwin system
Selected local directory: C:\cygwin/var/cache/setup
net: Preconfig
site: http://cygwin.mirror.constant.com/
mbox Parse Errors:  line 12: The current ini file requires at least version 2.903 of setup.
Please download a newer version from https://cygwin.com/setup-x86.exe
unattended_mode is set at mbox: returning default value
site: http://cygwin.mirror.constant.com/
mbox Parse Errors:  line 12: The current ini file requires at least version 2.903 of setup.
Please download a newer version from https://cygwin.com/setup-x86.exe
unattended_mode is set at mbox: returning default value
site: http://cygwin.mirror.constant.com/
mbox Parse Errors:  line 12: The current ini file requires at least version 2.903 of setup.
Please download a newer version from https://cygwin.com/setup-x86.exe
unattended_mode is set at mbox: returning default value
site: http://cygwin.mirror.constant.com/
mbox Parse Errors:  line 12: The current ini file requires at least version 2.903 of setup.
Please download a newer version from https://cygwin.com/setup-x86.exe
unattended_mode is set at mbox: returning default value
site: http://cygwin.mirror.constant.com/
mbox Parse Errors:  line 12: The current ini file requires at least version 2.903 of setup.
Please download a newer version from https://cygwin.com/setup-x86.exe
unattended_mode is set at mbox: returning default value
download/verify error in unattended_mode: out of retries
note: Installation incomplete.  Check C:\cygwin\var\log\setup.log.full for details
Ending cygwin install

issue も出てます。対処方法もそこでコメントされている通りで、最新の setup exe を上書きダウンロードして使用すれば OK です。

https://github.com/appveyor/ci/issues/3820

Powershell であれば issue のリンクのように書けば対応できます。
64bit 版は setup-x86_64.exe をダウンロードして C:\cygwin64\setup-x86_64.exe に保存します。
https://github.com/appveyor/build-images/blob/master/scripts/Windows/install_cygwin.ps1#L10-L13

Powershell 以外であれば curl で下記のようにダウンロードすれば大丈夫です。

      curl -sSL -o C:\cygwin\setup-x86.exe "https://cygwin.com/setup-x86.exe"
      curl -sSL -o C:\cygwin64\setup-x86_64.exe "https://cygwin.com/setup-x86_64.exe"

今回は以上。

[AppVeyor] fatal: reference is not a tree が出る場合の対応

AppVeyor に限らず git を使っていると遭遇するエラーかもしれませんが、AppVeyor でよく遭遇していて困ってたのでメモ。

"fatal: reference is not a tree: <sha>" on git checkout / Problems / Discussion Area - AppVeyor Support

原因としては「clone_depth: 1」としていることで、CI で実行されようとしているコミットハッシュが既に古く参照できないからのようなんですが、master の HEAD でも起きてる気がするんですよね。 

「New Build」をしても同じエラーになるので疑問が残るのですが、とりあえず 「clone_depth」をコメントアウトして対処しました。

ビルド時間を短縮する狙いで clone_depth を設定していたのですが残念です。

「それ以降はこのエラーに遭遇していません。」

と下書きに書いていたのですが、この記事を数ヶ月ストックしている間に再発しました。
おそらく、パスフィルターを導入して特定のファイルのみの変更はスキップするようにしたことが影響しているような気がしています。。

こちら、また進展があったら追記したいと思います。

今回は以上です。では。

[AppVeyor] Python3 系を使うようにする

AppVeyor で現在提供されているエージェント（環境）は Python 2.7 がデフォルトになっているので、Python 3 系に変更しました。

AppVeyor の環境にプリインストールされている Python は下記から確認できます。

Software pre-installed on Windows build VMs | AppVeyor

あとはお好きなバージョンのディレクトリを PATH に追加したら終わりです。

version: 1.0.{build}
branches:
  only:
  - master
image: Visual Studio 2019
init:
- cmd: SET PATH=C:\Python38;C:\Python38\Scripts;%PATH%

以上です。

AppVeyor のジョブを１つのマトリックスにまとめました

AppVeyor は１つのリポジトリに対して、複数のプロジェクトを作成することができます。
GUI Config では複雑なマトリックスを構築できないですが、複数のプロジェクトを作成することによって、擬似的に複雑なマトリックスを組みことができてました。

これで十分ではあったのですが、 iutest で使用している CI サービスも増えてきて（現在 15 サービス超）、管理する場所をなるべく少なくしたいという点と、Webhook が足りなくなってきたという２点の理由から、なるべくまとめることとしました。
（１プロジェクトにつき、GitHub の Webhook を１つ消費する。GitHub の Webhook　は１リポジトリにつき、２０ まで）

複雑なマトリックスの鍵： for

通常マトリックスは matrix: で環境変数やワーカーを複数用意して、"同じ"ビルド処理を行います。

environment:
  matrix:
    - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2013
      PROJECT_DIR: msvc12
      CMAKE_GENERATOR_NAME: Visual Studio 12 2013
    - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2015
      PROJECT_DIR: msvc14
      CMAKE_GENERATOR_NAME: Visual Studio 14 2015
    - APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2017
      PROJECT_DIR: msvc15
      CMAKE_GENERATOR_NAME: Visual Studio 15 2017
    - BUILD_NUGET: yes

ただ、これでは同じリポジトリで、ビルド・テスト以外のリリース（デプロイ）ビルドや、全く別環境（Windows vs Ubuntu）でビルドフローが異なるような場合には対応できず、
iutest でももともとやっていたような複数プロジェクト化による対応が必要でした。
（設定をパラメタライズドにして状態の異なるビルド・テストはできる。処理が単一で設定でいろいろ複雑に処理を変えるのは面倒だった）

しかし、今回紹介する for を利用することで、任意のマトリックスに対して通常とは異なるビルドやテスト・デプロイを記述することができるようになります。
for の使い方はこちらです。　Build configuration | AppVeyor

上記のマトリックスは iutest で実際に利用している yml の抜粋になりますが、NuGet ビルドの特殊化の部分を例として以下に載せます。

for:
# NuGet
-
  matrix:
    only:
      - configuration: Release
        BUILD_NUGET: yes
  before_build:
    cmd: echo.
  build_script:
    ps: |
      $nuspecPath = "projects\nuget\iutest.nuspec"
      Write-Output "Building NuGet package"
      nuget pack $nuspecPath -OutputDirectory ".\"
  test: off

for の要素として、特殊化するマトリックスの条件を matrix に記述し、任意のステップを上書き設定します。

注意したいこと

for を使った特殊化は、通常フローの上書きになります。
特殊化するケースで使用しないステップ（未記載）でも、通常フローでそのステップを使用している場合はそちらが呼ばれてしまいます。
そのため、何もしない場合でも、空の状態に上書きする必要があります。
上記例では、before_build と test のステップを空にしています。

YAML の構文チェック

さて、YAML Config は記述を間違うと、YAML 解析時に失敗してジョブが即失敗してしまいます。
なので、 push するまえに YAML の構文チェックをしておきましょう。

AppVeyor では以下のページで構文チェックができます。
構文がエラーがあると以下のように、エラーの箇所を教えてくれるので便利です。
https://ci.appveyor.com/tools/validate-yaml


特に問題がなければ、グリーン表示になります。

最後に

for でまとめた結果、複数に分かれていたプロジェクトの統一ができました。（全部じゃないけど）

for を使った高度なマトリックスは本家ブログでも紹介されています。
Advanced build matrix configuration in AppVeyor | AppVeyor
詳細は、公式ドキュメントや上記を参考にすると良いと思います。

では。

AppVeyor で Auto Cancel

最近、iutest の開発が活発？（無駄なコミットが多いとも言う）な影響で、AppVeyor の回転が非常に悪くなっていたので、Auto Cancel 設定を有効にしました。

Auto Cancel とは？

Auto Cancel 機能は、新しいビルドがキューに積まれたら、現在実行中（およびキュー済み）のジョブをキャンセルする機能です。
普通に開発していると、短い時間の間に何回か push することってあると思いますが、そうすると CI にはその分だけビルドがキューされ実行されます。
CI の１サイクルが短ければ、すぐさま実行されて終わり。とは思いますが、そうもいかないことも多いでしょう。(AppVeyor はなかなかキューが回らなくてよく詰まる・・・)


つまりんぐ・・・

そんなときに、有効にしておくと便利なのが Auto Cancel 機能です。
他の CI サービスでもよく見ることがありますが、AppVeyor では Rolling Builds という名前で提供されています。
Rolling Builds は、YAML 設定では変えられないので、 GUI 設定で変える必要があります。
Settings の General にあります。



（キューだけキャンセルとか、プルリクだけキャンセルとか、もできそうですね）

最後に

他の CI サービスの対応状況もまとめたいなーと思いつつ、今回は以上です。

では。

[CI] 各種 CI サービスのビルドスキップコメントまとめ (2018/3)

CIサービスの自動ビルドをスキップする方法まとめ - Qiita
こちらに Travis CI、Circle CI、Appveyor の場合がまとまっていますが、この記事では私が利用している CI サービスすべてをまとめたいと思います。

[ci skip] vs [skip ci]

CI サービスでスキップするためのコミットコメントの定番が [ci skip] と [skip ci] です。どちらにも対応しているサービスもあれば、片方だけだったり、これに加えて独自のメッセージに対応していたりします。

iutest では全部で10以上のサービスを利用しているので、すべてのサービスで共通して使えるコメントでないと困るので今回のまとめに至りました。
また、特定のサービスだけスキップしたいなどの要求もあるかもしれないので、そういった場合にも役立つまとめになっているかと思います。

前置きはこれくらいにして、まとめを見ていきましょう。

まとめ

サービス	[ci skip]	[skip ci]	その他	ユーザー定義
Travis CI	○	○
Circle CI	○	○
AppVeyor	○	○	[skip appveyor]	○
wercker	○	○
Shippable	○	○
Codeship	○	○	--skip-ci,--ci-skip
Semaphore	○	○
Codefresh				○
Bitrise	○	○
Scrutinizer	○	○	[skip Scrutinizer]
Rocro(INSPECODE)

以前は、[ci skip] 派と [skip ci] 派が分かれていたのですが、
現在は [ci skip]/[skip ci] どちらも使える派が主流のようです。
Rocro はスキップできないみたいですね。

ユーザー定義も可能な AppVeyor

AppVeyor ではユーザーが任意のスキップコメントをつけることもできます。
https://www.appveyor.com/docs/how-to/filtering-commits/#skip-commits

やり方は appveyor.yml に以下を追加するだけです。

skip_commits:
  message: /\[no appveyor\]/

これを設定しておけば、AppVeyor だけスキップするような使い方ができます。

自分ですべて設定する Codefresh

https://docs.codefresh.io/docs/build-1
Codefresh にはデフォルトでスキップコメント機能はついていませんでした。
ただ、上記リンクのようにコンディションに書けば対応が可能でした。

steps:
  BuildingDockerImage:
    title: Building Docker Image
    type: build
    image_name: srzzumix/ciskip
    working_directory: ./
    dockerfile:
      content: |-
        FROM ubuntu:latest
        COPY . /usr/src/myapp
        WORKDIR /usr/src/myapp
    tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
    when:
      condition:
        all:
          noSkipCiInCommitMessage: |
            includes(lower("${{CF_COMMIT_MESSAGE}}"), "[ci skip]") == false && includes(lower("${{CF_COMMIT_MESSAGE}}"), "[skip ci]") == false

注意が必要なのは、スキップ設定はすべてのステップに記述しないといけない点です。
（前のステップがスキップされても、後続のステップはスキップされないです。前のステップに依存しているとビルドが失敗します。）

また、スキップしたと言ってもビルド回数はカウントアップされます。。。（フリーアカウントの場合ビルド回数制限があるので気をつけましょう）

Only the head/last commit message is checked!

Bitrise のドキュメントに以下の注意書きがありました。

Only the head/last commit message is checked!
If you push more than one commit, only the last ("head") commit's message will be checked for the skip ci pattern!

http://devcenter.bitrise.io/tips-and-tricks/skip-a-build/

複数のコミットをまとめて push した場合、コメントは最後のコミットのものしかチェックしないようです。つまり、途中のコミットにスキップコメントを入れてもスキップされないということです。

他のサービスではどうなのか調べてみたところ、（Travis CI を除く）他のサービスも同様の挙動をしてました。

Travis CI は全部にスキップコメントが必要

Travis CI は push したときの head だけでなく、commit 毎にビルドが実行されるようなので、全部のコミットにスキップメッセージを入れないとイケナイようです。
「Auto cancel branch builds」設定ができるようになりましたが、これは新しいビルドがキューイングされたらキャンセルする機能です。
スキップコメントの commit はキューイングされないため自動キャンセルもされません。

なので、Travis CI を使う場合は [ci skip] をスキップしたいコミットにつける必要があります。

Travis CI は、スキップしたいコミットに [ci skip] をつける。
それ以外は、スキップしたいコミットを含む push を行う場合は head のコミットに [ci skip] をつける。
ということになるので、Travis CI の方が直感的かもしれませんね。

最後に

今回調べたことは、こちらのリポジトリで検証・記録として見ることができます。
https://github.com/srz-zumix/ci-skip

他に試して欲しい CI サービスなどありましたら、連絡もしくは PR ください。
では。

AppVeyor のフリーアカウントで定期ビルドが無効になっていたので有効化した

Scheduled builds for free accounts | AppVeyor

最近気づいたのですが、AppVeyor のフリーアカウントで定期ビルドがデフォルト無効になってました。
有料機能になったわけではなく、オプショナル機能として有効化依頼を出せば使えるっぽいです。

定期ビルド機能は、Wandbox の更新チェックに利用してたのですが、２ヶ月ほど停止してました・・・

2ヶ月ほどジョブが停止してた・・・ https://t.co/RHUOWmekEe

— ずみっくす★ (@srz_zumix) 2018年1月5日

実際にプロジェクトページに行って、設定しようとするとこうなります。


というわけで、有効化依頼をしました。
連絡手段はなんでも良さそうでした（メール、フォーラム、Twitter）。
最初 Twitter で連絡してみたのですが、レスポンスがなかなかなかったので、こちらのフォーラムを参考に同じ感じで依頼を出したところ、すぐに有効化していただけました！


外部サービスから Webhook で定期ビルドしようか、とか
別の CI サービスへの引っ越し、とか
サービス連携サービスで実装しなおす、とか
いろいろ考えましたけど、案外簡単に有効化できたのでよかったです。

ではでは。

[Appveyor] イメージを環境変数で指定する

今回は Appveyor で環境変数を使ったイメージの指定を紹介します。
iutest のテストでイメージごとにそれぞれ異なる環境変数を設定したかったときに、この方法に行き着きましたのでそれの紹介です。

テストではよくマトリックスを組んで複数の環境でテストをすることが多いと思います。
Appveyor なら、イメージが複数用意されているので、それぞれでテストを実行することになります。その場合はイメージを複数指定すれば OK です。
さらに環境変数を列として、イメージ×環境変数のマトリックスも組むこともできます。
さきにこちらの方法を紹介しておきます。

イメージと環境変数のマトリックス

まずイメージは「SETTINGS」「Environment」の「Build worker image」で複数設定することができます。
指定したイメージの分だけ、ジョブが実行されます。


さらに、同じく「Environment」の「Environment variables」で環境変数を指定できます。
「Add variable」だと、各イメージで共通の環境変数が設定されますが、「Add build matrix group」では環境変数のマトリックスを作成できます。


グループを追加すると「Environment variables - 1」「Environment variables - 2」のようにグループが増えていきます。
それぞれ「Add variable」から環境変数を設定できます。



テーブルにするとこんな感じです。

ENV_M value	Visual Studio 2015	Visual Studio 2017
Environment variables - 1	1	1
Environment variables - 2	2	2

Visual Stduio 2015/2017 のイメージそれぞれに対して、ENV_M が 1 と 2 のジョブが実行され、計4つのジョブが実行されます。

iutest でやりたかった構成

さて、これに対して iutest でやりたかったことはこうです。

ENV_M value	Visual Studio 2015	Visual Studio 2017
Environment variables - 1	1	×
Environment variables - 2	×	2

※×印はジョブを実行しないという意味です
上と合わせて書きましたが、わかりやすくするとこうです。

	Visual Studio 2015	Visual Studio 2017
ENV_M value	1	2

つまり、マトリックスにしたいわけではなく、イメージ対して一意な環境変数を設定したいわけです。



これができないか調べていたら、イメージのマトリックスを使わずに、「APPVEYOR_BUILD_WORKER_IMAGE」環境変数でイメージの指定ができることを知りましたので、これで解決しました。

イメージを環境変数で指定する

環境変数マトリックスでイメージを指定するので「Build worker image」は空にします。
次に、「Add build matrix group」で環境変数のグループを作成し、環境変数名「APPVEYOR_BUILD_WORKER_IMAGE」でイメージの名前を設定します。


これで実行すると「Environment variables - 1」のときだけ、イメージ設定が上書きされます。


環境変数が変わっただけでイメージが変わってないかもしれないので、以下のコマンドで確認しました。


結果、このようにイメージが変わっていることを確認。

まとめ

イメージに対して環境変数を別途指定したい場合は、環境変数のマトリックスと APPVEYOR_BUILD_WORKER_IMAGE を使うと実現できます。
イメージ×環境変数のマトリックスを組みつつ、イメージに対して個別で一意な環境変数をセットしたい場合は、APPVEYOR_BUILD_WORKER_IMAGE 環境変数を参照して判断するのが良さそうです。

マトリックス化する予定があるなら、最初から APPVEYOR_BUILD_WORKER_IMAGE を参照して分岐させるほうがいいかもしれないです。
このへんは好み、かなぁ・・・
ともあれ、APPVEYOR_BUILD_WORKER_IMAGE は ReadOnly じゃなくて Write もできるってことを覚えておくと今後役に立つかもしれません。（たぶん）


今回は以上です。では。

Wandbox のコンパイラー追加を通知する環境を作った

Wandbox で対応コンパイラーが増えたら、自分宛てにツイートしてくれる環境を作りました。

@srz_zumix [NEW!] C: gcc-7.1.0-c, C++: gcc-7.1.0, C++: zapcc-1.0.1 [Wandbox]三へ( へ՞ਊ ՞)へ ﾊｯﾊｯ https://t.co/9GNf3KoflL

— ずみっくす (@srz_zumix) 2017年5月30日

構成

Appveyor + Zapier

概要

https://github.com/srz-zumix/wandbox-news
ソースコードをみていただければ、どんなことやっているかはわかると思います。
特に難しいことはしてなくて、Wandbox API で取ってきたリストを成果物として保存して、前回との差分があれば Webhook を投げます。
あとは、Zapier で Webhook を受け取ってツイートするだけです。

その他

最初は、Google App Engine とか Circle CI とか使おうと思ってましたが、定期ビルド、Webhook Notification、成果物の保存・取得ができる Appveyor に落ち着きました。

あとは、Notification でカスタム json を作るのに、ちょっと手間取りました。
デフォルトで送ると Zapier で message を取るのがめんどくさかった（というか、うまくできない？）ので、カスタムで送るようにしてます。
url が secure 指定できなかったので、Web UI 設定にしてますが、appveyor.yml にコメントで書いてあるので参考にしてください。

では。


※更新なしが FAIL 更新ありが PASS になっているが、どちらも PASS にできるならしたい。
※Webhook を発行するトリガーとして、ステータスを利用しているため。
※最初は逆だったが、成果物取得で落ちてくるのが lastSuccessBuild のものだったため、更新があったときを PASS にしている。

※Zapier で tweet する際に改行がスペースに置換されてしまっている。
※改行のまま tweet したい。

[MSBuild] コード分析警告をエラーとする

Visual Studio コード分析機能については省略。
こちらの機能が無効な状態で SCM 管理されている場合、MSBuild で /p:RunCodeAnalysis=true /p:EnablePREfast=true をつけてビルドするとコード分析が有効になります。
Jenkins でこれを実行して、警告集計している場合は、警告プラグインの設定でジョブを失敗にしたり、不安定にしたりできるので問題ないのですが、CI サービスを使っていると Warning は成功となってしまいます。（exit code 0）
実際、自作 C++ テスティングフレームワークの iutest を AppVeyor でコード分析させてましたが、ずーーーっと警告を無視してました…

---

これを解決する方法はとても簡単です。
MSBuild のコマンドラインオプションに /p:CodeAnalysisTreatWarningsAsErrors=true を追加してください。これで、コード分析警告をエラーとして扱うようになります。



今回は以上です。

無料で使える CI サービス比較（定期実行編）

SCM との連携で更新タイミングで CI が実行されるサービスがほとんどですが、ちょっと定期的に実行させたいことがあり調べたのでまとめました。

以前まとめた情報はこちら
※まとめた時期が結構前なのでもう腐った情報になってるかもしれませんので注意！

ブログズミ: 無料で使える CI サービス比較
ブログズミ: 無料で使える CI サービス比較（Artifacts）

	AppVeyor	Circle CI	Codeship	drone.io	Magnum CI	semaphore	Shippable	Snap CI	Travis CI	Wercker
定期実行	◯	△	×	×	△	◯	△	◯	◯	◯

Appveyor

Build configuration - AppVeyor
Syntax はこちら Crontab Expression · atifaziz/NCrontab Wiki
Jenkins と同じ感じです。

Circle CI

Circle CI では定期実行する仕組みはありませんが、外部から実行開始することができます。
Nightly Builds - CircleCI
なので、何かしらの cron サービスと組み合わせれば定期実行は可能というわけです。

実際に定期実行させた例が Qiita にありました。

CircleCIを使ってbundle updateを定期実行する - Qiita

Codeship

API | Codeship Documentation
API が用意されていて、リスタートはできそうなのですが、新規に実行する方法が？だったので×にしました。

Magnum CI

Circle CI と同様に外部から実行開始できるので △ にしました。
https://magnum-ci.com/docs/integration

Semaphore

Project Settings に Build Scheduler があります。
Scheduling builds - Semaphore

Shippable

API を利用して外部から実行開始できるので △ にしました。
Shippable API for Projects - Shippable Docs

Snap CI

Scheduling and skipping builds | Snap CI Documentation, FAQ, and Troubleshooting
プロジェクトのページに「Build Schedule」があるので、そこから設定できます。

Travis CI

Cron Jobs - Travis CI

Please note that cron jobs are not enabled by default. Set “Build pushes” to on in your settings, then ask us to unlock this feature for your repository: support@travis-ci.com

デフォルトでは使えません。サポートチームに連絡する必要があるようです。

Wercker

Introducing Cronetes
こちらにやり方が書いてあります。が、ちょっと面倒くさそう。

最後に

ここで×としたサービスもただ単に機能を見逃しているだけで使えるかもしれません。
また、この情報記事投稿前の情報です。今後サービスは拡充していくと思いますので、公式ページで最新の情報を確認するようにお願いします。


さて、これで一旦調べ終わったので、どこかで定期実行ジョブを作りたいと思います。
では、今回は以上。

無料で使える CI サービス比較（Artifacts）

この記事は「ブログズミ: 無料で使える CI サービス比較」の追加記事です。
iutest の開発の都合で成果物を保存できるサービスを調べたので備忘録として残しておきます。

	AppVeyor	Circle CI	Codeship	drone.io	Magnum CI	semaphore	Shippable	Snap CI	Travis CI	Wercker
Artifacts	◯	◯	×	◯	×	×	×	◯	×	×

今回◯印をつけているのは、CI サービスのみで成果物保存が可能なものにつけています。
×のサービスでも Amazon S3 などを利用すれば成果物を保存することができます。

調べたものの結局使ってないので
短いですが、以上です。

[AppVeyor] リモートデスクトップでアクセスしてみた

AppVeyor ではワーカーマシンにリモートデスクトップでログインできます。
Accessing build worker via Remote Desktop (RDP) - Appveyor

iutest の cygwin ビルドのテストが落ちていたのですが、ログだけでは原因がよくわからなかったのでリモートデスクトップでアクセスしてみました。

設定

Accessing build worker via Remote Desktop (RDP) - Appveyor
こちらの説明では、init と on_finish のタイミングで RDP を有効にする方法が説明されています。

ビルド開始直後から有効にする場合は、下記の PS スクリプトを init で実行するように設定をします。

iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))

ビルド終了後に有効にする場合は、下記の PS スクリプトを on_finish で実行するように設定をします。

$blockRdp = $true; iex ((new-object net.webclient).DownloadString('https://raw.githubusercontent.com/appveyor/ci/master/scripts/enable-rdp.ps1'))

いずれの場合も時間制限があり、60分までとなっています。

ログインする

設定ができたら、ビルドを実行します。すると、
以下のようにコンソールログがでるので、そのアドレスとユーザー名、パスワードでリモートデスクトップ接続します。

init:

on_finish:



はい。できました。
これだけです。とっても簡単ですね。

日本語キーボード

リモートデスクトップでログインするとキーボードが英字配列として認識されて、やり辛かったです。
対処方法を色々試してみましたが、結果としては上手くいかず。
誰か教えて下さい～＞＜

まとめ

AppVeyor は至れり尽くせり。
（テキトーまとめごめんなさい）