パス除外ルールを使用した検証の実行時に、中立状態を GitHub に投稿する
この更新プログラムでは、Azure Pipelines に複数の更新プログラムが含まれていました。 YAML パイプラインでは、保護されたリソースの既定値として、すべてのパイプラインへのアクセスの拒否を設定しています。 さらに、パス除外ルールのために検証ビルドを実行しないことを決定すると、Azure Pipelines は中立状態を GitHub にポストバックします。
詳細については、次の機能の説明を参照してください。
注意
2021 年 9 月 28 日、Azure DevOps は Axosoft から、一般的な Git GUI クライアントである GitKraken の依存関係の脆弱性について通知されました。 詳細については 、ブログ記事 を参照してください。
Azure Pipelines
- ビルドがスキップされたときに中立状態を GitHub に投稿する
- 保護されたリソースでは、すべてのパイプラインへのアクセスが既定で無効になっています
- デコレーターを使用して、指定したターゲット タスクの前後にタスクを挿入する
- Windows 2016 ホストイメージの非推奨スケジュールの発表
- macOS 10.14 ホストイメージの非推奨を発表
Azure Pipelines
ビルドがスキップされたときに中立状態を GitHub に投稿する
Azure Pipelines を使用すると、GitHub で pull request を 常に検証できます。 また、GitHub リポジトリでパイプラインをトリガーする パス を指定することもできます。 たとえば、次のパイプラインは、ブランチでmain
変更が にcode
プッシュされたときにトリガーされますが、変更がフォルダーにdocs
プッシュされたときにトリガーされません。
trigger: none
pr:
branches:
include:
- main
paths:
include:
- code
exclude:
- docs
pool:
vmImage: ubuntu-latest
steps:
- script: echo Hello, world!
displayName: 'Run a one-line script'
パイプラインが完了すると、Azure Pipelines は状態を GitHub にポストバックします。 GitHub リポジトリに対してブランチ保護ポリシーが有効になっている場合、Azure Pipelines によって投稿された状態によって、pull request がマージされるかどうかが決まります。
上記の例では、 に docs
変更を加えた場合、GitHub は現在、Azure Pipelines によって状態が返されるのを待機している pull request をブロックしています。 ただし、Azure Pipelines では検証ビルドは実行されません。このパスはトリガーから除外されるため、pull request を完了できません。 1 つの GitHub リポジトリに対してパス除外トリガーまたは複数のパイプラインを設定するお客様は、多くの場合、この課題に直面しています。
今後、Azure Pipelines は、パス除外ルールのために検証ビルドを実行しないことを決定すると、GitHub に状態をポスト neutral
バックします。 これにより、Azure Pipelines が処理を完了したことを示す明確な方向が GitHub に提供されます。
会話ビュー:
詳細を確認する:
保護されたリソースでは、すべてのパイプラインへのアクセスが既定で無効になっています
YAML パイプラインは、1 つ以上の 保護されたリソースに依存できます。 サービス接続、エージェント プール、変数グループ、セキュリティで保護されたファイル、リポジトリはすべて、保護されたリソースの例です。このようなリソースの管理者は、そのリソースにアクセスできるパイプラインを制御できるためです。 管理者は、リソースのセキュリティ設定パネルを使用して、パイプラインを有効または無効にします。
これらのリソースのいずれかを作成すると、明示的にオフにしない限り、既定のエクスペリエンスによってすべてのパイプラインへのアクセスが許可されます。 今後は、全体的なセキュリティ体制を改善するために、すべてのパイプラインへのアクセスを拒否するように既定値が設定されています。 すべてのパイプラインへのアクセスを許可するには、作成エクスペリエンスで、またはリソースの作成後にトグルをオンにします。
デコレーターを使用して、指定したターゲット タスクの前後にタスクを挿入する
デコレーター は、タスクをパイプラインに自動的に挿入する方法です。 これらは、必要なコンプライアンス手順を自動的に実行するために、organizationの中央チームによって一般的に使用されます。 デコレーターは、クラシック ビルド、クラシック リリース、または YAML パイプラインで使用できます。
現在、タスクは、すべてのジョブの開始時、すべてのジョブの終了時、またはチェックアウト タスクの直後にデコレーターを介して挿入できます。 これを制御するには、ここで説明するように、デコレーターの拡張機能のコントリビューション セクションで を指定target
します。 次のようにターゲットの一覧を展開しています。
ms.azure-pipelines-agent-job.pre-task-tasks
ms.azure-pipelines-agent-job.post-task-tasks
ms.azure-release-pipelines-agent-job.pre-task-tasks
ms.azure-release-pipelines-agent-job.post-task-tasks
タスクのすべてのインスタンスの前にタスクをパイプラインに挿入するデコレーターの例を PublishPipelineArtifacts
次に示します。
{
"manifestVersion": 1,
"contributions": [
{
"id": "my-required-task",
"type": "ms.azure-pipelines.pipeline-decorator",
"targets": [
"ms.azure-pipelines-agent-job.pre-task-tasks"
],
"properties": {
"template": "my-decorator.yml",
"targettask": "ECDC45F6-832D-4AD9-B52B-EE49E94659BE"
}
}
],
"files": [
{
"path": "my-decorator.yml",
"addressable": true,
"contentType": "text/plain"
}
]
}
Windows 2016 ホストイメージの非推奨スケジュールの発表
最近、Windows 2022 をホストされたイメージとして使用できるようになりました。 2022 年 1 月に Windows 2016 のメインストリーム サポートが終了する予定で、11 月 15 日以降はイメージが非推奨になります vs2017-win2016
。 このイメージの完全な廃止は、2022 年 3 月に予定されています。 これは一般的に使用されるイメージであるため、パイプラインに必要な変更を加えるのに十分な通知と時間を提供したいと考えました。
Windows 2016 でホストされているイメージを使用してすべてのプロジェクトとパイプラインを検索する方法と、新しいバージョンに移行するために実行できる手順の詳細については、 ブログ投稿 を参照してください。
macOS 10.14 ホストイメージの非推奨を発表
最近、macOS-11 をホストされたイメージとして使用できるようにしました。 その結果、2021 年 12 月に macOS-10.14 イメージが非推奨になります。 このイメージに依存するビルドは、非推奨になると失敗します。 さまざまな画像の廃止に関する詳細については、 ブログ記事を参照してください。
次の手順
Note
これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。
Azure DevOps に進み、見てみましょう。
フィードバックの提供方法
これらの機能についてご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。
Stack Overflow のコミュニティからアドバイスや質問に回答してもらうこともできます。
よろしくお願いします。
ヴィジャイ・マキラジュ