利用するCI/CDサービスをGitHub Actionsに一本化する

[ghost]

やりたいこと

利用するCI/CDサービスをGitHub Actionsに一本化したい。

やりたい理由

1. どのCIサービスでビルドしたか識別できるようにする必要がある
2. 各CIサービスの使い分けが不明確
   • 逆に言えば、複数サービスを併用するなら何かしらの理由で使い分けた方がいいと思っています。
3. AppVeyorは…
   • 並列実行できないため、ビルドの完了を長時間待機しなければならない。
     • 単体テストが増えるにつれて、さらに時間を要するようになるかもしれません。
   • 機能の制約が多いため、自前でいろいろな処理を用意しなければならない。
4. Azure Pipelinesは…
   • ジョブを並列実行するためには追加の申請手続きが必要である。 https://docs.microsoft.com/en-us/azure/devops/pipelines/licensing/concurrent-jobs?view=azure-devops&tabs=ms-hosted

     We have temporarily disabled the free grant of parallel jobs for public projects and for certain private projects in new organizations. However, you can request this grant by submitting a request.

GitHub Actionsを選んだ理由

• GitHubに統合されているため、フォークリポジトリなら特に設定せずとも使えます。
• Azure Pipelinesからフォークされたサービスなので、おおむね同じ使い方ができます。
  • AZPはビルトインタスクが複数定義されいますが、GHAもGitHub Marketplaceに公開されている様々なタスクを利用できます。
  • AZPとGHAは、どちらも actions/virtual-environments の仮想イメージを利用しており、仮想環境のソフトウェア構成が同じです。実行ユーザーにOSの管理者権限が付いてくるのも同様。

検討課題

• [x] parse-buildlog.py の扱い（参照： #1669 ）
• （他に見つかり次第追記しますが、各自でも何かあれば自由に追記してください。）

関連

• 10

• https://github.com/sakura-editor/management-forum/issues/65

• 1259

  • 1263

• 1687

残作業

https://github.com/sakura-editor/sakura/issues/1809#issuecomment-1120376046 より転記(2022/09/19 by @berryzplus)

1. [ ] Azure Pipelines上でしか実行されていないジョブをGHAに移す

   • 本体のビルドジョブに含まれるbuild-bmp-tools.batの移し忘れに注意すること。
2. [ ] AppVeyorとAzure Pipelinesのジョブを止める
3. [ ] 不要になる設定ファイル・コード・ドキュメントの更新および削除
   • appveyor.yml
   • appveyor_env.py
   • azure-pipelines.yml
   • parse-buildlog.bat
   • parse-buildlog.py
   • ci/appveyor/*
   • ci/azure-pipelines/*
   • SonarQube.md（要更新：内容がAzure Pipelines用のため、GHA用の記述に修正すべき）
   • ci/build-batchfiles.md（要更新）
   • ci/build-envvars.md（要更新）
   • sakura/githash.bat（要更新：AppVeyor専用の環境変数が残存している）

[ghost]

とりあえず立ててみます。 AppVeyorとAzure Pipelinesの利用をやめるという意味を含みますが、併用する理由が生じれば残しても良いです。

[takke]

私もGHA一本化がいいと思います。

[berryzplus]

どうしましょ？

検討課題「parse-buildlog.py の扱い」は「捨て」の一択で、議論の余地がない気がします。 他の課題も出て来ないようですし、検討は終わりにして「GHAに一本化する」を進めていいんじゃないでしょうか？

「parse-buildlog.py の扱い」を「捨て」にする理由

• ビルド警告よりも詳細に問題点を報告してくれるツールを既に利用している
• parse-buildlog.py の解析結果は活用されていない（≒なくてもプロジェクト活動に影響がない）
• parse-buildlog.py はvs2019に対応していない（≒既に動いていない）

[ghost]

検討課題「parse-buildlog.py の扱い」は「捨て」の一択で、議論の余地がない気がします。 他の課題も出て来ないようですし、検討は終わりにして「GHAに一本化する」を進めていいんじゃないでしょうか？

ではそれで。僕はもう参加できないのでどなたかお願いします。

1. [ ] Azure Pipelines上でしか実行されていないジョブをGHAに移す
   • 本体のビルドジョブに含まれるbuild-bmp-tools.batの移し忘れに注意すること。
2. [ ] AppVeyorとAzure Pipelinesのジョブを止める
3. [ ] 不要になる設定ファイル・コード・ドキュメントの更新および削除
   • appveyor.yml
   • appveyor_env.py
   • azure-pipelines.yml
   • parse-buildlog.bat
   • parse-buildlog.py
   • ci/appveyor/*
   • ci/azure-pipelines/*
   • SonarQube.md（要更新：内容がAzure Pipelines用のため、GHA用の記述に修正すべき）
   • ci/build-batchfiles.md（要更新）
   • ci/build-envvars.md（要更新）
   • sakura/githash.bat（要更新：AppVeyor専用の環境変数が残存している）

なお、AppVeyor対応廃止するなら（先月メインストリームサポートが終了した）VS2017とInnoSetup5も廃止できると思われるのでこれも検討してください。 関係するファイル：

• installer/Languages/*(old).isl（Inno Setup 5でしか利用されない）
• installer/Languages/README.md（Inno Setup 5でしか利用されない）
• tools/find-tools.bat
• tools/find-tools.md
• vcx-props/*
• .vsconfig.vs2017

[berryzplus]

一本化は、「誰かが勝手にやる」で良いように思っています。 レビュアーの確保が難しいので、自分はレビュー側に回ります。

前提としてAZPのみで実施しているMinGWビルドをGHAで実施するようにactionsを実装する必要があります。 AppveyorとAzure Pipelinesのビルドを止めるのは、依頼があれば自分が実施できるはずです。（たぶん

AppveyorとAzure Pipelinesのためのバッチは、消してしまったほうが分かりやすい気がしています。 消さなくてもよいですが、ルートフォルダのファイルが多過ぎる問題を緩和するために、少なくともルートフォルダから外したい気がします。

[berryzplus]

タスクリストを更新してみました。

[dep5]

GitHub Actionsってダウンロードにログインが必要じゃないですか？ Artifact download URL only work for registered users (404 for guests) #51 InPrivateウィンドウ(Edge)で試してみるとわかると思います。

nightly.link こんなサイトもあるようですけど、githubが提供しているものではないような？

テストに参加してくれる人が減ってしまうと思います…