Sprint 192出ているの気づいていなくて遅くなりましたが、Azure DevOps Sprint 192のリリースノートの翻訳を行いました。オリジナルはこちらからご覧ください。
docs.microsoft.com
YAMLの新しい条件式これは便利ですね。例にも載っていますが、パイプライン内で動くコマンドに対して動的にパラメータの指定ができるとか、パイプラインの中でdiagnosticsが有効にされた状態と連動してツールがデバッグログを詳細に出したい時などに有効に使えそうですね。
YAMLパイプラインでCIやPRトリガーにパスフィルターの指定ができなかったの不便だったのですが、ようやく改良されて大変うれしいです。
ここからはちょっとわかりづらい機能改良ですが、GitHubレポジトリと組み合わせて、forkされたレポジトリからのPull Requestで自動的に検証のビルドを実行しないことをお勧めされています。なぜかというと、この仕様を利用してビットコインのマイニングに使われたからです。信頼されない外部の人からのPull Requestで自動的に検証を動かしてしまうとそこでマイニングが始まってしまう可能性があります。
Pull Requestをレビューしたうえで、コラボレーターにコメントを付けてもらうことで、検証ビルドを実行するように設定することで回避できます。このあたりの設定をWebの設定でTriggerを設定します。この設定をチーム外からのPull Requestのみにすると大体いい感じになるはずです。
ただ、この設定は少々面倒だったので、今回の更新から一度Pull Requestがマージされた後は信頼されるコントリビューターとして、コメントがなくても自動的にパイプラインが実行されます。これは外部からのコントリビューションを受け取るようなレポジトリを運用する場合は便利ですね。
Windows Server 2022のイメージがプレビュー提供、Big Surが一般提供、Ubuntu 16.04が廃止と一気に入れ替えになりますね。特に廃止になるUbuntu 16.04使っている人は気を付けてください。
ブランチ作ると基本的にそのブランチの管理権限を持ちます。管理権限があるということはそのブランチにほかの人の編集権限を追加できるということになって、コンプライアンスがきつい組織では問題になることがあります。こういう時にブランチ作成者にブランチ管理権限が付かないようにできる設定が増えました。
作ることを抑止する機能ではないので、気を付けてください。特定のブランチを管理者が認識しないメンバーが編集できないようにするという機能ですが、ケースによっては便利そうです。既定値は従来通りなので、困る場合のみ設定してください。
次もforkした場合の仕様追加です。今までupstreamへpull requestを出す権限にはupstreamのレポジトリでpull requestに対してvoteする権限も一緒に管理しているので、自分で自分のpull requestに対して「これOKOK」とupvoteの投票ができてしまっていました。Strict Vote Modeという権限と分離ししたそうです。
これ、オリジナルのドキュメントのスクリーンショットが間違ってますね。フィードバックしておきます。
今回もこまごまとセキュリティ＆コンプライアンス関係の修正が多いですね。非常にニッチながらも役に立つ人はいると思いますが、一般向けではないかもしれないですね。
ではまた三週間後。
Translate to Japanese to Azure DevOps release not…
