問題タブ [azure-pipelines]

私は完全なCIソリューションを達成しようとしています.PRから始まります.->ビルド->ビルドはnugetパッケージをoctopusにプッシュします->octopusは新しいパッケージを認識してデプロイします. 自動ビルド プル リクエストに対してプル リクエスト ポリシーがどのように機能するかについて、いくつか明確にしたいと思いました。「チーム メンバーが "dev" ブランチにプル リクエストを作成または更新するとき、このビルドをキューに入れる: MyCoolBuilDefinition」を選択しました。

PR が作成されると、ビルドがすぐに起動することに気付きました。一時的な git ブランチ「refs/pull/123/merge」を作成します。ビルドを行うために、このブランチに事前マージが作成されると思います。これはデプロイしてテストできるビルドですか? それとも、これはビルド ポリシーを満たすためだけですか?

3 つのプル リクエストが作成された場合....PR1 と PR2 が既にビルドされているが、完了とマークされていない場合。PR3 のビルドには PR1 と PR2 のコードが含まれますか? PR が Completed としてマークされている場合にのみ、コードが「dev」ブランチにマージされるため、そうではないと思います。事前マージを行うには、最新の「dev」ブランチからプルする必要があります。また、P1 と p2 が完了としてマークされていない場合、P3 には P1 と P2 のコードがありません。

背景: 複数のプロジェクトを含む単一の .NET ソリューションがあります。そのうちのいくつかは .NET Framework に対してコンパイルされ、一部は .NET Core (UWP) に対してコンパイルされます。Visual Studio Team Services (旧 Visual Studio Online) を使用して、ソリューションを継続的に構築しています。

課題: UWP プロジェクトには、異なる MSBuild 引数とプラットフォーム設定が必要です。以下のスクリーンショットのようにビルド定義を作成しました。ソリューションは最初に .NET 引数を使用してビルドされます。次に、すべての UWP プロジェクトに MSBuild ステップがあります。

問題: UWP プロジェクトを追加、削除、または名前変更するたびに、ビルド定義を更新する必要があります。理想的には Visual Studio ビルド ステップを使用し、カスタム スクリプトを使用せずに、UWP プロジェクトを自動的に選択したいと考えています。何か案は？

代替案: もともと、ソリューションを 2 つ (プラットフォームごとに 1 つのソリューション) に分割し、各ソリューションに対して 2 つの異なる Visual Studio Build イベントを実行していました。ただし、1 つのソリューションで作業することを好みます。

特定のビルド セットを既存の Visual Studio Team Service プロジェクトから新しいプロジェクトに移動しています。残念ながら、あるプロジェクトから別のプロジェクトにビルド定義を移行する方法が見つかりません。インポート/エクスポート機能やその他のメカニズムはないようです。

新しいプロジェクトでビルドを手動で再作成せずにこれらを移動する方法はありますか?

プロジェクト全体を処理するために VSTS (以前は VSO) を使用しており、Azure でホストされていない Web サイトの自動リリース (ビルドは既に配置されています) を行いたいと考えています。したがって、FTP を使用する必要があります。

私が理解しているように、cURLを使用してこれを達成できるはずですが、必要なファイル構造を維持せずに必要なすべてのファイルを転送することしかできませんでした。

FTP を使用してファイル構造内のファイルを転送する方法を見つけた人はいますか? もしそうなら、どのように？

このドキュメントに従って、Visual Studio Team Services で Service Fabric アプリケーションの CI ビルドを構成しました: https://azure.microsoft.com/en-us/documentation/articles/service-fabric-set-up-continuous -統合

ただし、CI ビルドで公開する代わりに、ビルドとパッケージ化のタスクのみを実行し、pkg フォルダー、スクリプト、公開プロファイル、アプリケーション パラメーターなど、Service Fabric 関連のすべての出力をドロップに含めます。このようにして、新しいリリース パイプライン (エージェント ベースのリリース) に渡して、サービス ファブリック アプリケーションの実際のデプロイを行うことができます。

私のリリース定義には、(適切なサービス プリンシパルが構成された) ARM エンドポイントを使用する単一の Azure Powershell タスクがあります。

アプリを既存の Service Fabric クラスターにデプロイするときは、既定の Deploy-FabricApplication コマンドレットを使用して、pkg フォルダーと、既存のクラスターへの接続で構成された発行プロファイルを渡します。

「クラスター接続インスタンスがヌルです」というエラー メッセージが表示され、解放に失敗します。そして、私はなぜ理解できないのですか？

Debug-FabricApplication コマンドレットは Connect-ServiceFabricCluster コマンドレットを正常に実行しますが、Publish-NewServiceFabricApplication コマンドレットが実行を引き継ぐとすぐに、クラスター接続が失われます。

Service Fabric コマンドレットを使用するとこのシナリオが可能になると思いますが、デプロイ中にクラスター接続を開いたままにしておく方法がわかりません。

更新: ドキュメントへのリンクは Service Fabric PowerShell スクリプトを参照しなくなったため、この質問の前提条件はドキュメント化されなくなりました。この記事では、VSTS のビルド タスクとリリース タスクについて言及しています。これは、私が使用しようとした PowerShell コマンドレットよりも優先される可能性があります。

git lfs を使用して、git リポジトリの大きなファイルを保存します。次に、ホストされたエージェントでこのレポを構築しようとします。私のビルドはとてもシンプルです。これには、PowerShell を実行するという 1 つのタスクがあります。呼び出されたスクリプトで最初にやりたいことは、lfs の依存関係を取得することです。したがって、スクリプトには次のものがあります。

残念ながら、私のビルドは次のエラーで失敗します:

ホストされたエージェントには何もインストールできないので、git lfs を利用できるようにするにはどうすればよいですか?

EDITこの問題では、ここで 説明されている git lfs 認証の問題については話していません。私は厳密に を呼び出す問題について話していgit lfsます。

を呼び出すことができたらgit lfs、この回答を見て認証の問題を解決してください。

ホストされているビルド エージェント イメージが、MS 自体のリリース サイクルに遅れないようにする方法はありますか?

リリース 1.2.0 に含まれている特定のコマンドレットが必要でした。Azure PowerShell モジュールは既にバージョン 1.2.2 になっています

ホストされているビルド エージェントで実行されているモジュールの現在のバージョンは何ですか?