maxmustermann/pulumi
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
pulumi/build.proj

190 lines
8.2 KiB
Plaintext
Raw Normal View History

Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<RepoRootDirectory>$(MSBuildThisFileDirectory)</RepoRootDirectory>
<SdkDirectory>$(RepoRootDirectory)\sdk\</SdkDirectory>
<NodeJSSdkDirectory>$(SdkDirectory)\nodejs\</NodeJSSdkDirectory>
<NativeRuntimeModuleDirectory>$(NodeJSSdkDirectory)\runtime\native\</NativeRuntimeModuleDirectory>
<NodeVersion>6.10.2</NodeVersion>
<NodeArch>x64</NodeArch>
Restore TESTPARALLELISM to 10 Now that we no longer recursively call yarn via yarn run and scripts, we can use a `--mutex network` directive in a .yarnrc file at the root of the repository to prevent multiple copies of yarn running concurrently.
2017-10-14 00:45:50 +02:00
<TestParallelism>10</TestParallelism>
Use VS2017
2017-10-31 23:38:51 +01:00
<MSVSVersion>2017</MSVSVersion>
Cleanup provider launch scripts and fix some windows build oddities The windows build was still on the old plan from way back when where we had binaries littered in the build tree and you had to add parts of your build-tree to the `%PATH%` for the integration tests to work. This cleans that up and moves all of our scripts that invoke javascript to be on the same plan. They invoke our specially named node with a relative path to the JS code we want to run.
2018-02-16 01:17:47 +01:00
<PulumiRoot Condition="'$(PulumiRoot)' == ''">C:\Pulumi\</PulumiRoot>
<PulumiBin>$(PulumiRoot)\bin</PulumiBin>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
</PropertyGroup>
<Target Name="EnsureGoDependencies">
<Exec Command="dep ensure -v"
WorkingDirectory="$(RepoRootDirectory)" />
</Target>
<Target Name="EnsureNodeDependencies">
<Exec Command="yarn install"
WorkingDirectory="$(NodeJSSdkDirectory)" />
</Target>
<Target Name="EnsureCustomNode"
Revert "Revert Windows changes to unblock npm ingestion" This reverts commit d98dcaa79ce6d59a634789992578f2193bf046ad.
2018-02-14 00:07:07 +01:00
Condition="!Exists('$(NodeJSSdkDirectory)\custom_node\node\node.exe')">
Fix download_node.ps1; remove ensure_custom_v8 This gets the windows build a little further along. We actually get to the point where we run the pulumi integration tests now, but they all fail.
2018-02-14 01:00:02 +01:00
<Exec Command="&quot;$(NodeJSSdkDirectory)\scripts\download_node.cmd&quot;"
WorkingDirectory="$(NodeJSSdkDirectory)" />
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
</Target>
<Target Name="CopyNodeSdkProtos">
<ItemGroup>
<NodeSdkProtos Include="$(SdkDirectory)\proto\nodejs\**\*" />
</ItemGroup>
Consult the program for its list of plugins This change adds a GetRequiredPlugins RPC method to the language host, enabling us to query it for its list of plugin requirements. This is language-specific because it requires looking at the set of dependencies (e.g., package.json files). It also adds a call up front during any update/preview operation to compute the set of plugins and require that they are present. These plugins are populated in the cache and will be used for all subsequent plugin-related operations during the engine's activity. We now cache the language plugins, so that we may load them eagerly too, which we never did previously due to the fact that we needed to pass the monitor address at load time. This was a bit bizarre anyhow, since it's really the Run RPC function that needs this information. So, to enable caching and eager loading -- which we need in order to invoke GetRequiredPlugins -- the "phone home" monitor RPC address is passed at Run time. In a subsequent change, we will switch to faulting in the plugins that are missing -- rather than erroring -- in addition to supporting the `pulumi plugin install` CLI command.
2018-02-06 18:57:32 +01:00
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
<Copy SourceFiles="@(NodeSdkProtos)"
DestinationFolder="$(NodeJSSdkDirectory)\proto" />
</Target>
Ship `nativeruntime.node` as part of the SDK Fixes #356. Instead of downloading a node binary with our closure serialization code linked-in, this PR instead publishes the `nativeruntime.node` produced by the NodeJS SDK build as part of the SDK. This has a number of advantages. First, it is vastly more easy to develop closure.cc in this configuration. Second, we have the ability to ship different `nativeruntime.node`s side-by-side, paving the way for enabling future versions of Node. Third, we don't have to stay in the business of shipping custom builds of Node, although we do still need to ship a version of Node with minor modifications in order for Windows to still work.
2018-02-16 01:08:06 +01:00
<Target Name="ConfigureNativeRuntimeModule"
DependsOnTargets="EnsureNodeDependencies">
<Exec Command="&quot;$(NativeRuntimeModuleDirectory)\ensure_node_v8.cmd&quot;"
WorkingDirectory="$(NativeRuntimeModuleDirectory)" />
<Exec Command="&quot;$(NodeJSSdkDirectory)\node_modules\.bin\node-gyp.cmd&quot; configure --msvs_version $(MSVSVersion) --devdir &quot;$(NativeRuntimeModuleDirectory)\node_dev&quot;"
WorkingDirectory="$(NativeRuntimeModuleDirectory)" />
<Copy SourceFiles="$(NodeJSSdkDirectory)\custom_node\node\node.lib"
DestinationFiles="$(NativeRuntimeModuleDirectory)\node_dev\$(NodeVersion)\$(NodeArch)\node.lib" />
</Target>
<Target Name="BuildNativeRuntimeModule"
DependsOnTargets="ConfigureNativeRuntimeModule">
<Exec Command="&quot;$(NodeJSSdkDirectory)\node_modules\.bin\node-gyp.cmd&quot; build --msvs_version $(MSVSVersion) --devdir &quot;$(NativeRuntimeModuleDirectory)\node_dev&quot;"
WorkingDirectory="$(NativeRuntimeModuleDirectory)" />
</Target>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
<Target Name="TypeScriptCompileNodeSdk">
<Exec Command="yarn run tsc"
WorkingDirectory="$(NodeJSSdkDirectory)" />
</Target>
Move language host logic from Node to Go (#901) * experimental: separate language host from node * Remove langhost details from the NodeJS SDK runtime * Cleanup * Work around an issue where Node sometimes loads the same module twice in two different contexts, resulting in two distinct module objects. Some additional cleanup. * Add some tests * Fix up the Windows script * Fix up the install scripts and Windows build * Code review feedback * Code review feedback: error capitalization
2018-02-10 03:15:04 +01:00
<Target Name="GoCompileNodeSdk">
<ItemGroup>
Reimplement GetRequiredPlugins in Go This brings back the Node.js language plugin's GetRequiredPlugins function, reimplemented in Go now that the language host has been rewritten from JavaScript. Fairly rote translation, along with some random fixes required to get tests passing again.
2018-02-12 04:22:23 +01:00
<GoPackagesToBuild Include="github.com/pulumi/pulumi/sdk/nodejs/cmd/pulumi-language-nodejs" />
Move language host logic from Node to Go (#901) * experimental: separate language host from node * Remove langhost details from the NodeJS SDK runtime * Cleanup * Work around an issue where Node sometimes loads the same module twice in two different contexts, resulting in two distinct module objects. Some additional cleanup. * Add some tests * Fix up the Windows script * Fix up the install scripts and Windows build * Code review feedback * Code review feedback: error capitalization
2018-02-10 03:15:04 +01:00
</ItemGroup>
<Exec Command="git describe --tags 2>nul" ConsoleToMSBuild="true" Condition="'$(Version)' == ''">
<Output TaskParameter="ConsoleOutput" PropertyName="Version" />
</Exec>
Cleanup provider launch scripts and fix some windows build oddities The windows build was still on the old plan from way back when where we had binaries littered in the build tree and you had to add parts of your build-tree to the `%PATH%` for the integration tests to work. This cleans that up and moves all of our scripts that invoke javascript to be on the same plan. They invoke our specially named node with a relative path to the JS code we want to run.
2018-02-16 01:17:47 +01:00
<Exec Command="go install -ldflags &quot;-X github.com/pulumi/pulumi/pkg/version.Version=$(Version)&quot; %(GoPackagesToBuild.Identity)"
EnvironmentVariables="GOBIN=$(PulumiBin)"/>
Move language host logic from Node to Go (#901) * experimental: separate language host from node * Remove langhost details from the NodeJS SDK runtime * Cleanup * Work around an issue where Node sometimes loads the same module twice in two different contexts, resulting in two distinct module objects. Some additional cleanup. * Add some tests * Fix up the Windows script * Fix up the install scripts and Windows build * Code review feedback * Code review feedback: error capitalization
2018-02-10 03:15:04 +01:00
</Target>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
<Target Name="BinplaceNodeSdkProtos">
<ItemGroup>
<NodeSdkProtosForBinplace Include="$(NodeSdkDirectory)\proto\nodejs\**\*" />
</ItemGroup>
Delete the old IDL compiler (#801) It is moving to a new location: https://github.com/pulumi/pidlc
2018-01-14 00:11:52 +01:00
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
<Copy SourceFiles="@(NodeSdkProtos)"
DestinationFolder="$(NodeJSSdkDirectory)\bin\proto" />
</Target>
Ship `nativeruntime.node` as part of the SDK Fixes #356. Instead of downloading a node binary with our closure serialization code linked-in, this PR instead publishes the `nativeruntime.node` produced by the NodeJS SDK build as part of the SDK. This has a number of advantages. First, it is vastly more easy to develop closure.cc in this configuration. Second, we have the ability to ship different `nativeruntime.node`s side-by-side, paving the way for enabling future versions of Node. Third, we don't have to stay in the business of shipping custom builds of Node, although we do still need to ship a version of Node with minor modifications in order for Windows to still work.
2018-02-16 01:08:06 +01:00
<Target Name="BinPlaceNodeSdkNativeRuntimeModule"
DependsOnTargets="BuildNativeRuntimeModule">
<ItemGroup>
<NodeSdkNativeRuntimeModuleFiles Include="$(NativeRuntimeModuleDirectory)\build\Release\nativeruntime.node" />
<NodeSdkNativeRuntimeModuleFiles Include="$(NativeRuntimeModuleDirectory)\build\Release\nativeruntime.pdb" />
</ItemGroup>
<Copy SourceFiles="@(NodeSdkNativeRuntimeModuleFiles)"
DestinationFolder="$(NodeJSSdkDirectory)\bin\runtime\native\build\Release" />
</Target>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
<Target Name="BinPlaceNodeSdkTestData">
<ItemGroup>
<NodeSdkTestDataFiles Include="$(NodeJSSdkDirectory)\tests\runtime\langhost\cases\**\*" />
</ItemGroup>
<Copy SourceFiles="@(NodeSdkTestDataFiles)"
DestinationFolder="$(NodeJSSdkDirectory)\bin\tests\runtime\langhost\cases" />
</Target>
<Target Name="YarnLinkSdk">
<Copy SourceFiles="$(NodeJSSdkDirectory)\package.json"
DestinationFiles="$(NodeJSSdkDirectory)\bin\package.json" />
<Exec Command="yarn link"
WorkingDirectory="$(NodeJSSdkDirectory)\bin" />
</Target>
<Target Name="BinPlaceNodeSdk"
Ship `nativeruntime.node` as part of the SDK Fixes #356. Instead of downloading a node binary with our closure serialization code linked-in, this PR instead publishes the `nativeruntime.node` produced by the NodeJS SDK build as part of the SDK. This has a number of advantages. First, it is vastly more easy to develop closure.cc in this configuration. Second, we have the ability to ship different `nativeruntime.node`s side-by-side, paving the way for enabling future versions of Node. Third, we don't have to stay in the business of shipping custom builds of Node, although we do still need to ship a version of Node with minor modifications in order for Windows to still work.
2018-02-16 01:08:06 +01:00
DependsOnTargets="BinPlaceNodeSdkProtos;BinPlaceNodeSdkNativeRuntimeModule;BinPlaceNodeSdkTestData;YarnLinkSdk">
Fix some more scripts
2018-02-18 17:11:14 +01:00
<Copy SourceFiles="$(NodeJSSdkDirectory)\custom_node\node\node.exe" DestinationFiles="$(PulumiBin)\pulumi-language-nodejs-node.exe" />
Fix language script merge
2018-02-17 21:10:21 +01:00
<Copy SourceFiles="$(NodeJSSdkDirectory)\dist\pulumi-language-nodejs-exec.cmd" DestinationFolder="$(PulumiBin)" />
<Copy SourceFiles="$(NodeJSSdkDirectory)\dist\pulumi-resource-pulumi-nodejs.cmd" DestinationFolder="$(PulumiBin)" />
Ship `nativeruntime.node` as part of the SDK Fixes #356. Instead of downloading a node binary with our closure serialization code linked-in, this PR instead publishes the `nativeruntime.node` produced by the NodeJS SDK build as part of the SDK. This has a number of advantages. First, it is vastly more easy to develop closure.cc in this configuration. Second, we have the ability to ship different `nativeruntime.node`s side-by-side, paving the way for enabling future versions of Node. Third, we don't have to stay in the business of shipping custom builds of Node, although we do still need to ship a version of Node with minor modifications in order for Windows to still work.
2018-02-16 01:08:06 +01:00
<Copy SourceFiles="$(NodeJSSdkDirectory)\bin\runtime\native\build\Release\nativeruntime.node" DestinationFolder="$(PulumiBin)\v$(NodeVersion)" />
<Copy SourceFiles="$(NodeJSSdkDirectory)\bin\runtime\native\build\Release\nativeruntime.pdb" DestinationFolder="$(PulumiBin)\v$(NodeVersion)" />
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
</Target>
Cleanup provider launch scripts and fix some windows build oddities The windows build was still on the old plan from way back when where we had binaries littered in the build tree and you had to add parts of your build-tree to the `%PATH%` for the integration tests to work. This cleans that up and moves all of our scripts that invoke javascript to be on the same plan. They invoke our specially named node with a relative path to the JS code we want to run.
2018-02-16 01:17:47 +01:00
<Target Name="BuildNodeSdk"
Ship `nativeruntime.node` as part of the SDK Fixes #356. Instead of downloading a node binary with our closure serialization code linked-in, this PR instead publishes the `nativeruntime.node` produced by the NodeJS SDK build as part of the SDK. This has a number of advantages. First, it is vastly more easy to develop closure.cc in this configuration. Second, we have the ability to ship different `nativeruntime.node`s side-by-side, paving the way for enabling future versions of Node. Third, we don't have to stay in the business of shipping custom builds of Node, although we do still need to ship a version of Node with minor modifications in order for Windows to still work.
2018-02-16 01:08:06 +01:00
DependsOnTargets="CopyNodeSdkProtos;BuildNativeRuntimeModule;TypeScriptCompileNodeSdk;GoCompileNodeSdk;BinPlaceNodeSdk">
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
</Target>
<Target Name="BuildGoCmds">
<ItemGroup>
<GoCmdsToBuild Include="github.com/pulumi/pulumi" />
</ItemGroup>
Construct version based on git information We use `git describe --tags` to construct a version number based on the current version tag. The properties VERSION (when using make) and Version (when using MSBuild) can be explicitly set to use a fixed value instead. Fixes #13
2017-10-16 22:50:00 +02:00
<Exec Command="git describe --tags 2>nul" ConsoleToMSBuild="true" Condition="'$(Version)' == ''">
<Output TaskParameter="ConsoleOutput" PropertyName="Version" />
</Exec>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
Cleanup provider launch scripts and fix some windows build oddities The windows build was still on the old plan from way back when where we had binaries littered in the build tree and you had to add parts of your build-tree to the `%PATH%` for the integration tests to work. This cleans that up and moves all of our scripts that invoke javascript to be on the same plan. They invoke our specially named node with a relative path to the JS code we want to run.
2018-02-16 01:17:47 +01:00
<Exec Command="go install -ldflags &quot;-X github.com/pulumi/pulumi/pkg/version.Version=$(Version)&quot; %(GoCmdsToBuild.Identity)"
EnvironmentVariables="GOBIN=$(PulumiBin)"/>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
</Target>
<Target Name="Build"
DependsOnTargets="EnsureGoDependencies;EnsureNodeDependencies;EnsureCustomNode;BuildNodeSdk;BuildGoCmds">
</Target>
<Target Name="IntegrationTest">
Consult the program for its list of plugins This change adds a GetRequiredPlugins RPC method to the language host, enabling us to query it for its list of plugin requirements. This is language-specific because it requires looking at the set of dependencies (e.g., package.json files). It also adds a call up front during any update/preview operation to compute the set of plugins and require that they are present. These plugins are populated in the cache and will be used for all subsequent plugin-related operations during the engine's activity. We now cache the language plugins, so that we may load them eagerly too, which we never did previously due to the fact that we needed to pass the monitor address at load time. This was a bit bizarre anyhow, since it's really the Run RPC function that needs this information. So, to enable caching and eager loading -- which we need in order to invoke GetRequiredPlugins -- the "phone home" monitor RPC address is passed at Run time. In a subsequent change, we will switch to faulting in the plugins that are missing -- rather than erroring -- in addition to supporting the `pulumi plugin install` CLI command.
2018-02-06 18:57:32 +01:00
<Exec Command="where pulumi-language-nodejs-exec.cmd"
Move language host logic from Node to Go (#901) * experimental: separate language host from node * Remove langhost details from the NodeJS SDK runtime * Cleanup * Work around an issue where Node sometimes loads the same module twice in two different contexts, resulting in two distinct module objects. Some additional cleanup. * Add some tests * Fix up the Windows script * Fix up the install scripts and Windows build * Code review feedback * Code review feedback: error capitalization
2018-02-10 03:15:04 +01:00
IgnoreExitCode="true">
<Output TaskParameter="ExitCode" PropertyName="WhereLangHostExecExitCode" />
</Exec>
Consult the program for its list of plugins This change adds a GetRequiredPlugins RPC method to the language host, enabling us to query it for its list of plugin requirements. This is language-specific because it requires looking at the set of dependencies (e.g., package.json files). It also adds a call up front during any update/preview operation to compute the set of plugins and require that they are present. These plugins are populated in the cache and will be used for all subsequent plugin-related operations during the engine's activity. We now cache the language plugins, so that we may load them eagerly too, which we never did previously due to the fact that we needed to pass the monitor address at load time. This was a bit bizarre anyhow, since it's really the Run RPC function that needs this information. So, to enable caching and eager loading -- which we need in order to invoke GetRequiredPlugins -- the "phone home" monitor RPC address is passed at Run time. In a subsequent change, we will switch to faulting in the plugins that are missing -- rather than erroring -- in addition to supporting the `pulumi plugin install` CLI command.
2018-02-06 18:57:32 +01:00
<Exec Command="where pulumi-language-nodejs"
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
IgnoreExitCode="true">
<Output TaskParameter="ExitCode" PropertyName="WhereLangHostExitCode" />
</Exec>
Echo the dynamic provider's location
2018-02-20 03:59:55 +01:00
<Exec Command="where pulumi-resource-pulumi-nodejs.cmd"
IgnoreExitCode="true">
<Output TaskParameter="ExitCode" PropertyName="WhereLangHostExitCode" />
</Exec>
Cleanup provider launch scripts and fix some windows build oddities The windows build was still on the old plan from way back when where we had binaries littered in the build tree and you had to add parts of your build-tree to the `%PATH%` for the integration tests to work. This cleans that up and moves all of our scripts that invoke javascript to be on the same plan. They invoke our specially named node with a relative path to the JS code we want to run.
2018-02-16 01:17:47 +01:00
<Error Text="Please add &quot;$(PulumiRoot)\bin&quot; to your path before running integration tests."
Move language host logic from Node to Go (#901) * experimental: separate language host from node * Remove langhost details from the NodeJS SDK runtime * Cleanup * Work around an issue where Node sometimes loads the same module twice in two different contexts, resulting in two distinct module objects. Some additional cleanup. * Add some tests * Fix up the Windows script * Fix up the install scripts and Windows build * Code review feedback * Code review feedback: error capitalization
2018-02-10 03:15:04 +01:00
Condition="$(WhereLangHostExitCode) != 0 Or $(WhereLangHostExecExitCode) != 0"/>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
Ensure we always kill leaking node processes When go test fails, we would not kill any extra node processes lying around. In AppVeyor, not killing these causes the job to hang until we reach the AppVeyor timeout. Explicitly killing the jobs ensures AppVeyor ends quickly.
2017-10-28 00:34:38 +02:00
<!-- Ignore the exit code (but retain it) so we can kill all the lingering node processes even when go test
fails. Otherwise, the AppVeyor job would hang until it reached the timeout -->
Lower timeout The tests usually complete in about 15 seconds, so let's lower the timeout to fail a little faster in cases where we have hangs in `pulumi` itself.
2017-10-28 00:36:28 +02:00
<Exec Command="go test -timeout 2m -cover -parallel $(TestParallelism) .\examples"
Ensure we always kill leaking node processes When go test fails, we would not kill any extra node processes lying around. In AppVeyor, not killing these causes the job to hang until we reach the AppVeyor timeout. Explicitly killing the jobs ensures AppVeyor ends quickly.
2017-10-28 00:34:38 +02:00
IgnoreExitCode="true"
WorkingDirectory="$(RepoRootDirectory)">
<Output TaskParameter="ExitCode" PropertyName="GoTestExitCode" />
</Exec>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
<!-- Work around pulumi/pulumi#371 by killing all lingering node.exe processes. Yes, in the limit
this may kill too much, but we assume for now folks hacking on pulumi on windows are not running
additional node.exe processes -->
Don't error when no lingering node.exe processes exist
2017-10-31 01:06:57 +01:00
<Exec Command="taskkill /f /im node.exe"
IgnoreStandardErrorWarningFormat="true"
IgnoreExitCode="true" />
Ensure we always kill leaking node processes When go test fails, we would not kill any extra node processes lying around. In AppVeyor, not killing these causes the job to hang until we reach the AppVeyor timeout. Explicitly killing the jobs ensures AppVeyor ends quickly.
2017-10-28 00:34:38 +02:00
Use correct parameter name
2017-10-30 22:43:49 +01:00
<Error Text="go test failed, exit code: $(GoTestExitCode)"
Ensure we always kill leaking node processes When go test fails, we would not kill any extra node processes lying around. In AppVeyor, not killing these causes the job to hang until we reach the AppVeyor timeout. Explicitly killing the jobs ensures AppVeyor ends quickly.
2017-10-28 00:34:38 +02:00
Condition="'$(GoTestExitCode)' != '0'"/>
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
</Target>
<Target Name="Publish">
<Exec Command="&quot;$(RepoRootDirectory)\scripts\publish.cmd" />
</Target>
<Target Name="AppVeyorPush"
Publish after building in CI (before testing)
2017-12-04 03:12:20 +01:00
DependsOnTargets="Build;Publish;IntegrationTest" />
Build, integration tests and publishing on Windows
2017-09-23 02:51:59 +02:00
<Target Name="AppVeyorPullRequest"
DependsOnTargets="Build;IntegrationTest" />
</Project>
Reference in a new issue Copy permalink