2016-08-19 8 views
0

私はAppVeyorを初めて使いました。私は別のGITリポジトリに多くのプロジェクトがあるWebエージェンシーで働いています。手動配布中のAppVeyorプロジェクト環境変数へのアクセス

各プロジェクトには、私がAppVeyorで見ている開発ブランチがあります。 IISを実行する単一の内部開発サーバーがあるため、開発サーバーをAppVeyor環境として定義することができました。開発サーバーはAppVeyorエージェントを実行しています。

私が定義した環境名とカスタム環境変数をプロジェクト固有のYAMLファイル内に指定​​しています。

environment: 
    iis_site_name: project-specific-site-name.com 

deploy: 
- provider: Environment 
    name: dev-environment 

私はこのようなプロジェクトから環境変数を受け入れるようにAppVeyor環境を設定しました。

AppVeyor Environment - 注:websitebuildは、アーティファクトに関連付けられた「デプロイメント名」です。

この作業は完全にコミットされているため、プロジェクトは作成され、正しい場所にエージェントに展開されます。

これがうまくいかないのは、手動展開を開始する必要がある場合です。したがって、AppVeyorインターフェースに入り、「環境」>「開発環境」>「新規デプロイ」>「プロジェクトの選択」を選択してマニュアル配布を開始したいとします。

このデプロイメントでは、YAMLファイル(iis_site_name) 「default」という名前の新しいIISサイトが作成され、そこにサイトが展開されます。 私はまた、(YAMLとは対照的に)GUIを介してプロジェクト設定で環境変数を追加しようとしましたが、それはまったく動作しません。

答えて

0

ビルド時の環境変数が利用できない場合、予想される動作であると信じています.Appveyorは、環境レベルの変数で定義するエージェントのデフォルト値に送信します。その画面の下部にhere

を見てください、私たちは、その「デフォルト」値、あなたは環境から展開するときに使用すなわち 値を定義し、 変数はIとして

存在しない環境を構築しています異なるプロジェクトに異なるサイト名が必要なため、これがあなたのシナリオに合わないことを理解してください。あなたができることは、すべてのプロジェクト(別々のデフォルトサイト名を持つ)ごとに別々の環境を作成することですが、現在の環境で使用するものと同じ環境アクセスキーをすべて置き換えるので、エージェントはそのすべてからジョブを取得します。

更新:

これはマーティのコメントに応じて最適なソリューションではありません。その後、REST APIを使用します。

ドキュメントは、ここでは以下のhttps://www.appveyor.com/docs/api/environments-deployments/#start-deployment

チェックサンプルのPowerShell関数です。必要に応じてプロジェクト固有のパラメータで呼び出すことができます。あなたはまた、サイトがIISでホストヘッダーの代わりに、*バインディングを使用するための設定展開プロバイダに$(iis_site_name)websitebuild.hostnameを設定する必要が

、そうでない場合は、TCPポート上で戦うことになる。)について

function start-appveyorDeploy 
{ 
    param (
     [Parameter(Position=0, Mandatory=$true)] 
     [string]$projectSlug, 

     [Parameter(Position=1, Mandatory=$true)] 
     [string]$buildVersion, 

     [Parameter(Position=2, Mandatory=$true)] 
     [string]$siteName 
    ) 

    $apiUrl = 'https://ci.appveyor.com/api' 

    # Replace this with your values 
    $token = <your_token> 
    $environmentName = <your_environmentName> 
    $accountName = <your_accountName> 

    $headers = @{ 
     "Authorization" = "Bearer $token" 
     "Content-type" = "application/json" 
    } 

    $body = @{ 
     environmentName=$environmentName 
     accountName=$accountName 
     projectSlug=$projectSlug 
     buildVersion=$buildVersion 
     environmentVariables [email protected]{ 
      iis_site_name=$siteName 
     } 
    } 

    $jsonBody = $body | ConvertTo-Json -Depth 3 

    Invoke-RestMethod -Uri "$apiUrl/deployments" -Headers $headers -Body $jsonBody -Method Post 
} 
+0

感謝答えはありますが、サイトごとに別々の環境を作成することは、最初に環境を定義する目的を完全に打ち消します。私は多分ここで5-60のサイトについて話しており、新しいサイトは毎週スピンアップしています。そのため、私はできるだけシンプルにプロセスを保つように努めていました。 –

+0

これを念頭に置いて、私はこの方法で手動展開を引き起こさずに生きることができると思います。今私はそれについて考えて、最後のコミットの再ビルドを開始することで同じ結果を得ることができます。これは悪くないですが、それは一貫したビルドステップですが、それは仕事を完了させるでしょう。 –

+0

私は、REST APIを使用して環境配備を呼び出すことを提案します。私は私の答えを更新すると思う – ilyaf

関連する問題