Skip to content

Instantly share code, notes, and snippets.

@kkamegawa
Created September 23, 2022 09:17
Show Gist options
  • Save kkamegawa/1fda758406bc039fd5e7b2a30c3d0146 to your computer and use it in GitHub Desktop.
Save kkamegawa/1fda758406bc039fd5e7b2a30c3d0146 to your computer and use it in GitHub Desktop.

Developer Communityからの複数の要望にお応えしました - Sprint 209

Developer Communityで皆様からいただいたご要望にお応えして、複数の機能を優先的に実装しました。パイプラインでは、YAML式で文字列の分割機能をサポートしました。また、パイプライン実行時の最後のコミットメッセージを表示しないように設定できるようになりました。Delivery Plansでは、チーム数の上限を15から20に引き上げました。

詳しくはリリースノートをご覧ください。

Delivery Plansでは、組織内の複数のバックログと複数のチームの表示が可能です。以前は、異なるプロジェクトのバックログやチームが混在する場合など、15チームのバックログを表示することができました。このスプリントでは、上限を15から20に増やしました。

Reporting Work Item Links Get API のバグを修正し、System.LinkTypes.Remote.Relatedリンクタイプに対して正しい remoteUrl 値を返せるようにしました。この修正前は、間違った組織名とプロジェクトIDが欠落した値を返していました。

このスプリントでは、New Boards Hub の複数のバグを修正しました。バグ修正の一覧は、New Boards Hub, Sprint 209 updateというブログでご覧いただけます。

今までパイプラインの実行を表示する際、パイプラインUIは最後のコミットメッセージを表示していました。

Example of last commit message

このメッセージは、たとえば YAML パイプラインのコードがビルドするコードとは別のリポジトリにある場合において混乱することがあります。Developer Communityから、パイプラインを実行するたびに最新のコミットメッセージをタイトルに追加する方法を有効/無効にすることを求める声がありました。

今回の更新では、appendCommitMessageToRunNameという新しい YAML プロパティを追加し、まさにそれを実行できるようにしました。デフォルトでは、このプロパティはtrueに設定されています。falseに設定すると、パイプラインの実行では、BuildNumberのみが表示されます。

Example of pipeline run with build number

Example of pipeline run with last commit message

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

以下は、新しいレスポンスボディの例です。

"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 パイプラインでリストやオブジェクトのプロパティの各値をループするような、コードの重複を減らす便利な方法を提供します。

ときどき、反復処理するアイテムのセットは文字列として表されます。たとえば、デプロイ先の環境のリストが integration1, integration2 という文字列で定義されている場合です。

Developer Communityからのフィードバックに耳を傾けたところ、YAML テンプレート式にsplit(訳注:文字列の分割機能)が欲しいという声がありました。

以下のようにsplitを使うことで文字列を分割し、eachでその部分文字列をそれぞれ反復処理できるようになりました。

variables:
  environments: integration1, integration2

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

checkout taskは、Gitリポジトリの内容を取得する際に--tagsオプションを使用します。これにより、サーバーはすべてのタグと、そのタグが指すすべてのオブジェクトを取得することになります。これでは、パイプラインでタスクを実行する時間が増加してしまいます。特に、多数のタグを含む大きなリポジトリを持っている場合です。さらに、shallow fetchオプションを有効にしても、チェックアウトタスクはタグを同期させるので、その目的が達成されない可能性があります。Git リポジトリから取得したりプルしたりするデータの量を減らすために、タグを同期させる動作を制御する新しいオプションをタスクに追加しました。このオプションは、クラシックパイプラインとYAMLパイプラインの両方で利用可能です。

この動作は、YAML ファイルから制御するか、UI から制御するかのどちらかになります。

# Classic
steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  noTags: boolean # whether to prevent sync of 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ファイルによるタグの同期を行わないようにするには、チェックアウトステップにnoTags: trueを追加してください。noTagsオプションが指定されていない場合は、noTags: falseが使用されている場合と同じです。

既存の YAML パイプラインの動作を変更したい場合、YAML ファイルを更新するのではなく、UI でこのオプションを設定する方が便利な場合があります。UI に移動するには、パイプラインの YAML エディタを開き、[Triggers]、[Process]、[Checkout] の順に選択します。

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

Sync Tags check

作成したすべての新しいパイプライン(YAMLまたはクラシック)については、デフォルトでタグは同期されません。このオプションは、既存のパイプラインの動作を変更するものではありません。上記のように明示的にオプションを変更しない限り、それらのパイプラインではタグが引き続き同期されます。

Azure Pipelines は、Microsoft hosted上の Ubuntu 18.04 イメージ (ubuntu-18.04)を非推奨とします。このイメージは12月1日に廃止される予定です。このため、キューにかかる時間が長くなる可能性があります。

どのパイプラインがubuntu-18.04イメージを使用しているかをよりよく識別するために、ブラウンアウト(訳注:意図的に失敗させること)を計画しています。ブラウンアウト期間中はジョブが失敗します。

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

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

  • 10/7 10:00 UTC - 10/7 16:00 UTC
  • 10/14 12:00 UTC - 10/14 18:00 UTC
  • 10/21 14:00 UTC - 10/21 20:00 UTC
  • 10/28 16:00 UTC - 10/28 22:00 UTC
  • 11/4 22:00 UTC - 11/5 04:00 UTC
  • 11/11 04:00 UTC - 11/11 10:00 UTC
  • 11/18 06:00 UTC - 11/18 12:00 UTC
  • 11/25 08:00 UTC - 11/25 14:00 UTC

注意事項

ここで議論されている機能は今後二~三週にわたって順次展開されます。

次のリンクからAzure DevOpsサービスを体験してみてください。

Go to Azure DevOps Services

これらの機能についてどう思っているかお聞きしたいと思います。 フィードバックメニューを使用して問題を報告するか、提案を提出してください。

Make a suggestion

アドバイスや回答を必要とする質問がある場合、Stack Overflowコミュニティで聞いてください。

ありがとうございました。

Aaron Hallberg

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment