BEACHSIDE BLOG

Azure とか C# 好きなエンジニアの個人メモ ( ・ㅂ・)و ̑̑

GitHub のコードを Azure Pipelines 使って Azure Artifacts へ公開 (NuGet パッケージ, Azure DevOps )

前回は NuGet パッケージの作る際の注意点と手作業での Azure Artifacts への発行をメモしましたが、
今回は Azure Pipelines で CICD します。

公式ドキュメントの左側のメニューで "classic" と記載のある古い時代の Release pipelines ではなく、Multi stage pipelines です。ここ大切。

Multi stage pipeline の基本的な話は昔に触れてるのでリンク張っときます。

blog.beachside.dev

本題に戻りますが、前提とやりたいことはこんな感じです。

  • GitHub にソースコードがある
  • Pull Request に応じて Azure Pipelines で CI する
  • GitHub 上でバージョンのタグをつけたら Azure Pipelines で CD (Azure Artifacts へ発行) する

Azure Pipelines でパイプラインの作成

パイプラインを作る

Azure DevOps のポータルで、左側にある Pipelines のアイコンをクリック > Pipelines をクリックします。

f:id:beachside:20191023163357p:plain

Pipelines の画面が表示されます。Pipeline の作成ボタン(初めて作る場合は画面中央に Create Pipeline、以降は、画面右上に New pipeline ボタンがあります。)をクリックします。

Code の選択画面が表示されます。今回は GitHub のコードを使うので、GitHub を選択します。

f:id:beachside:20191023163740p:plain

対象の repository を選択します。

f:id:beachside:20191023163904p:plain

選択すると GitHub の認証が求められます。パスワードを入力して認証が出来たら GitHub の画面が表示されます。内容を確認し、Azure Pipelines の アクセス権限を許可しましょう。画面を下の方に進めると、Approve and install ボタンをクリックします。

f:id:beachside:20191023164854p:plain

Azure DevOps の画面に戻ってきてくれるはずです。Configure your pipeline の画面になるはずです。

📌 私が既に Azure DevOps と GitHub を連携済みの状態なので、そうじゃない場合にどうなるか覚えてないですが、もしかしたらGitHub の Marketplace で Azure Pipelines をインストールする必要があるかもしれません。あと、Azure DevOps の Organization や Project を選択する操作が必要かもしれません。
私の場合、Azure DevOps の画面に戻ったタイミングでなぜか別の Organization にリダイレクトされていまうという闇に遭遇しました(画面開きなおしたら進めた)。

闇に遭遇しなければ、下図のようにテンプレートの選択に遷移します。ちょうどよいものはないので、Starter pipeline を選んでおきます。

f:id:beachside:20191023165741p:plain

Multi stage pipeline の YAML を設定

パイプラインでやりたいこと

やりたいことの1つは、GitHub から PR 時に CI が動くことです。

PR時は、デフォで2つあると思ってます。

  1. PR が作成されたタイミング(PR作成後、merge される前までに push したタイミングを含む)
  2. PRが Merge されたタイミング

今回は NuGet パッケージへの発行なので、CD はあまり考えてません。GiHub でバージョンのタグを打ったタイミング( GitHub の Release を記載したタイミングともいいますかね)でリリースしたいからです。

ということで、作りたい Pipeline は以下にしました。

  • master branch に PR が作成された(前述 1 )時に ビルド・テスト
  • 手作業で pipeline が実行されたときもビルド・テスト する
  • PRが Merge された(前述 2 )時は、何もしない
  • GitHub 上でタグをつけたときに Azure Artifacts の Feed へ発行

GitHub のバージョンの情報をとってきてライブラリに埋め込むは簡単できそうですが、今回は個人的に興味がないのでやりません。

YAML の定義

こんな感じ。

私個人的な癖としては、stage や job の名前の最後にわざわざ *_stage とか *job とか Suffix 付けてます。ダサいなーと思いつつも以前 condition をたくさん指定するケースの時に suffix が無かったせいでミスったのと、job と stage で名前が被って naming に無駄に悩むことがあったので...。

YAML のざっくりな解説します。

2行目

tags のトリガーの書き方はこちらのドキュメントを確認すればOKです。

17行目

条件には、Pull Request 時と手動にしてます。Build.Reason に関してはこちらのドキュメントに書かれています。

18-29行目

build_test_stage では、dotnet の test コマンドだけ実行してます。 test 時に build 走るので build は省略しがちですが、この考えは良いのかな...とたまに思っています。

31行目

今回は動作的に意味ない stage です。PR の merge 後に condition の設定が正しく動くかだけの確認用に書きました。

42-43行目

この stage は、GitHub で v から始まる tag を登録した時に動作するよう43行目の condition を設定しています。

50-63行目

NuGet のパッケージ化と発行には、NuGetCommand@2 の pack は build が動くはずなんですが、設定がおかしかったときにエラーログ見るのが大変だったので build と pack を分けました。ということで2度ビルドしないよう pack するときに ----no-build オプションが動くよう設定しています(62行目)。
バージョン指定は、私はソースコード側で指定したものを使うので特に設定してませんが、BuildNumber をつけたり色々できます。方法についてはこちらのドキュメントにあります。

Azure Pipelines 上で設定

Azure DevOps の Azure Pipelines から編集すると、 Package task は、Settings をクリックすることで GUI で入力できるのでちょっとわかりやすいですね。もちろんドキュメントでどんなオプションを設定できるのか確認は必要ですが。

f:id:beachside:20191025122837p:plain


これで GitHub で PR 作ってから Azure Artifacts の Feed への発行まで自動化できました。

YAMLの作成はわかると簡単なんですが、パイプラインの作成はプロジェクトの最初にしかしない分頻度が低いし、Azure DevOps は進化が早いので触る度に変わってる印象あります(いいことですね!)。気づいたタイミングでブログにメモしておきたいところです 。

これ使ったプロジェクトはこちら。

github.com

その他

azure-pipelines.yml のパス

とりあえずで sln ファイルと同じパスに azure-pipelines.yml に置いてます。ファイル名を変えたりパスを変えた場合、Pipelines 側でファイルパスを設定する必要があります。設定方法は以前に書いたのでリンクだけはっておきます。

Azure Pipelines の Multi-stage pipeline Yaml をテンプレート化する ( Web Apps / ASP.NET Core ) - BEACHSIDE BLOG

Azure Pipelines で パイプライン作成時に警告が出る

ソースコードが GitHub: public, パイプラインには Azure DevOps: private を使ってるいるせいか、パイプラインの作成時にこんな警告が出てました。

You selected a public repository, but this is not a public project. Go to project settings to change the visibility of the project. Learn more

f:id:beachside:20191023165946p:plain

私の場合、結局なにも設定せずに正常に動いていますが、だめなケースあるのかなと気になります。警告文の最後にあるリンクは、Organization の Security policies で public project を allow してねって内容です。ちなみにそこは私のは on にしてるので、Off の時あかんくなるのかなと思ったり( 私が Off にすることはないので試してない)。

参考

docs.microsoft.com

docs.microsoft.com

docs.microsoft.com