次の方法で共有

Developer Communityからの複数の要求に対処しました

  • [アーティクル]

フィードバックに応じて、Developer Communityで要求した複数の機能に優先順位が付けされました。 パイプラインでは、YAML 式で文字列分割関数のサポートを追加しました。 さらに、パイプライン実行の最後のコミット メッセージの表示を無効にできるようになりました。 配信計画では、チームの制限を 15 から 20 に増やしました。

詳細については、リリース ノートを参照してください。

Azure Boards

Azure Pipelines

Azure Boards

配信計画チームの制限を 15 から 20 に引き上げる

配信プランを使用すると、organization全体で複数のバックログと複数のチームを表示できます。 以前は、さまざまなプロジェクトのバックログとチームの組み合わせを含む 15 個のチーム バックログを表示できました。 このスプリントでは、上限を 15 から 20 に増やしました。

リンクの種類に対して正しい remoteUrl 値を返すように、Reporting Work Item Links Get API のバグを System.LinkTypes.Remote.Related 修正しました。 この修正の前に、間違ったorganization名と不足しているプロジェクト ID が返されていました。

新しい Boards Hub のバグ修正

このスプリントでは、New Boards Hub の複数のバグを修正しました。 バグ修正の一覧については 、新しい Boards Hub、Sprint 209 更新プログラムのブログ投稿を参照してください。

Azure Pipelines

パイプライン実行の最後のコミット メッセージの表示を無効にする

以前は、パイプラインの実行を表示するときに最後のコミット メッセージを表示するために使用されたパイプライン UI。

最後のコミット メッセージの例

このメッセージは、たとえば、YAML パイプラインのコードがビルド中のコードを保持するリポジトリとは異なるリポジトリに存在する場合に、混乱を招く可能性があります。 Developer Communityから、すべてのパイプライン実行のタイトルに最新のコミット メッセージを追加することを有効または無効にする方法を求めるフィードバックが寄せられます。

この更新プログラムでは、 という名前 appendCommitMessageToRunNameの新しい YAML プロパティが追加されました。これを正確に行うことができます。 既定では、 プロパティは に true設定されています。 を に false設定すると、パイプラインの実行には のみが表示 BuildNumberされます。

ビルド番号を使用したパイプライン実行の例

最後のコミット メッセージを使用したパイプライン実行の例

Pipelines Runs Rest API で使用されるリソースとテンプレート パラメーター

拡張 パイプライン実行 REST API は 、パイプライン実行で使用されるより多くの種類の成果物と、その実行をトリガーするために使用されるパラメーターを返すようになりました。 API を拡張して、 container リソースと pipeline 、パイプライン実行で使用されるテンプレート パラメーターを返しました。 たとえば、パイプラインで使用されるリポジトリ、コンテナー、およびその他のパイプライン実行を評価する書き込みコンプライアンス チェックを作成できるようになりました。

新しい応答本文の例を次に示します。

"resources":
{
    "repositories":
    {
        "self":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        },
        "MyFirstProject":
        {
            "repository":
            {
                "id": "e5c55144-277b-49e3-9905-2dc162e3f663",
                "type": "azureReposGit"
            },
            "refName": "refs/heads/main",
            "version": "44153346ecdbbf66c68c20fadf27f53ea1394db7"
        }
    },
    "pipelines":
    {
        "SourcePipelineResource":
        {
            "pipeline":
            {
                "url": "https://dev.azure.com/fabrikam/20317ad0-ae49-4588-ae92-6263028b4d83/_apis/pipelines/51?revision=3",
                "id": 51,
                "revision": 3,
                "name": "SourcePipeline",
                "folder": "\\source"
            },
            "version": "20220801.1"
        }
    },
    "containers":
    {
        "windowscontainer":
        {
            "container":
            {
                "environment":
                {
                    "Test": "test"
                },
                "mapDockerSocket": false,
                "image": "mcr.microsoft.com/windows/servercore:ltsc2019",
                "options": "-e 'another_test=tst'",
                "volumes":
                [
                    "C:\\Users\\fabrikamuser\\mount-fabrikam:c:\\mount-fabrikam"
                ],
                "ports":
                [
                    "8080:80",
                    "6379"
                ]
            }
        }
    }
},
"templateParameters":
{
    "includeTemplateSteps": "True"
}

YAML テンプレート式での文字列分割関数のサポートを追加する

YAML パイプラインを使用すると、オブジェクトのリストまたはプロパティ の値を each ループ 処理するなど、コードの重複を減らす便利な方法が提供されます。

反復処理する項目のセットが文字列として表される場合があります。 たとえば、デプロイする環境の一覧が 文字列 integration1, integration2で定義されている場合です。

Developer Communityからのフィードバックを聞くと、YAML テンプレート式で文字列split関数が必要と聞きました。

これで、文字列を作成し、その部分文字列を反復処理eachできますsplit。

variables:
  environments: integration1, integration2

jobs:
  - job: Deploy
    steps:
    - ${{ each env in split(variables.environments, ', ') }}:
      - script: ./deploy.sh -e ${{ env }}
      - script: ./runTest.sh -e ${{ env }}

Git リポジトリをフェッチするときにタグを同期しない

チェックアウト タスクでは、Git リポジトリの内容をフェッチする際にオプションが使用--tagsされます。 これにより、サーバーはすべてのタグと、それらのタグが指すすべてのオブジェクトをフェッチします。 これにより、パイプラインでタスクを実行する時間が長くなります。特に、多数のタグを持つ大規模なリポジトリがある場合です。 さらに、シャロー フェッチ オプションを有効にした場合でも、チェックアウト タスクはタグを同期するため、その目的を打ち負かす可能性があります。 Git リポジトリからフェッチまたはプルされるデータの量を減らすために、タグの同期動作を制御するための新しいオプションがタスクに追加されました。 このオプションは、クラシック パイプラインと YAML パイプラインの両方で使用できます。

この動作は、YAML ファイルまたは UI から制御できます。

YAML ファイルを介したタグの同期をオプトアウトするには、チェックアウト ステップに を fetchTags: false 追加します。 オプションが fetchTags 指定されていない場合は、 が使用されている場合 fetchTags: true と同じです。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchTags: boolean # whether to sync the tags
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: boolean | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

既存の YAML パイプラインの動作を変更する場合は、YAML ファイルを更新するのではなく、UI でこのオプションを設定する方が便利な場合があります。 UI に移動するには、パイプラインの YAML エディターを開き、[トリガー]、[プロセス]、[チェックアウト] の順に選択します。

この設定を YAML ファイルと UI の両方で指定すると、YAML ファイルで指定された値が優先されます。

作成したすべての新しいパイプライン (YAML またはクラシック) では、タグは既定で同期されます。 このオプションでは、既存のパイプラインの動作は変更されません。 上記のようにオプションを明示的に変更しない限り、これらのパイプラインでタグは同期されます。

Ubuntu 18.04 イメージのブラウンアウト スケジュールを更新しました

Azure Pipelines は、ホストされているプール上の Ubuntu 18.04 イメージ (ubuntu-18.04) を非推奨とします。 この画像は 12 月 1 日に廃止されます。 長いキュー時間が表示され始める場合があります。

ubuntu-18.04 イメージを使用しているパイプラインをより適切に特定できるように、ブラウンアウトを計画しています。 ジョブは、ブラウンアウト期間中に失敗します。

  • ubuntu-18.04 イメージを使用してパイプラインの実行に警告メッセージが表示される
  • ubuntu-18.04 を含む非推奨のイメージを使用してパイプラインを見つけるのに役立つ スクリプト を使用できます
  • 短い "ブラウンアウト" をスケジュールしています。 ubuntu-18.04 の実行は、ブラウンアウト期間中に失敗します。 そのため、ブラウンアウトの前にパイプラインを移行することをお勧めします。

ブラウンアウト スケジュール (更新)

  • 10 月 3 日、12:00 UTC - 10 月 3 日、14:00 UTC
  • 10 月 18 日、14:00 UTC - 10 月 18 日、16:00 UTC
  • 11 月 15 日、18:00 UTC - 11 月 15 日、20:00 UTC
  • 11 月 30 日、20:00 UTC - 11 月 30 日、22:00 UTC
  • 12 月 15 日、20:00 UTC - 12 月 16 日 00:00 UTC
  • 1 月 5 日、10.00 UTC - 14.00 UTC の 1 月 5 日
  • 1 月 13 日、12.00 UTC - 1 月 13 日、16.00 UTC
  • 1 月 18 日、14.00 UTC - 18.00 UTC の 1 月 18 日
  • 1 月 24 日、16.00 UTC - 20.00 UTC の 1 月 24 日
  • UTC 2 月 1 日、18.00 UTC - 22.00 UTC 2 月 1 日
  • UTC 2 月 7 日、16.00 UTC - 22.00 UTC 2 月 7 日
  • 2 月 13 日、14.00 UTC - 22.00 UTC の 2 月 13 日
  • 2 月 21 日、10.00 UTC - 22.00 UTC の 2 月 21 日
  • 2 月 28 日、10.00 UTC - 22.00 UTC の 2 月 28 日
  • UTC 00.00 3 月 6 日 - 00.00 UTC 3 月 7 日
  • 3 月 13 日、00.00 UTC - 00.00 UTC の 3 月 14 日
  • 3 月 21 日、00.00 UTC - 00.00 UTC の 3 月 22 日

次の手順

Note

これらの機能は、今後 2 ~ 3 週間にわたってロールアウトされます。

Azure DevOps に向かい、見てみましょう。

Azure DevOps に移動する

フィードバックの提供方法

これらの機能に関するご意見をお聞かせください。 ヘルプ メニューを使用して、問題を報告したり、提案を提供したりします。

ご提案の送信

Stack Overflow のコミュニティが回答したアドバイスや質問を受けることもできます。

よろしくお願いします。

アーロン・ハルベルク