New-Item produces a new object on success, which ultimately gets
output by the make_release.ps1 cmdlet and consumed by the release.ps1
script. This messes up the release script that is expecting exactly
one object to come out of the pipeline from make_release.ps1.
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.
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.
In order to begin publishing our core SDK package to NPM, we will
need it to be underneath the @pulumi scope so that it may remain
private. Eventually, we can alias pulumi back to it.
This is part of pulumi/pulumi#915.
* 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
Ideally we would just use `make build` and `make install` in favor of
having yet another way to build the product, but before we can do that
in general we need to come up with a better story for cross
building. For now, just ensure we pass the correct version string to
go build when building.
We need to take the package.json from the folder (which will have been
rewritten by the build to include the version number) instead of the
version we have checked into the tree (which has ${VERSION} as a version)
Windows didn't have this issue, but it did include some stuff we did
not include in the unified release, so I cleaned that up as well.
- `go build` handles appending .exe to the built binary, so we need not do
it ourselves. In fact, when we did we generated a binary called
`pulumi.exe.exe` which is not what we wanted.
- Remove the development versions of the langhost and dynamic provider,
from the `<root>/node_modules/pulumi` folder. The `dist` version gets
copied into bin.
- Add the dummy_argument workaround to the dist version of the langhost.
Unlike go binaries (where we can cross compile) the node module that
we publish needs to be built on the platform we publish for. Update
our `.travis.yml` file to also build on macOS and fix the publishing
script so we don't don't cross publish Darwin from Linux. Once we have
CI working for Windows, we'll remove the loop over PUBLISH_GOOS and
each build will publish just the artifacts for the host OS.
This includes a few changes:
* The repo name -- and hence the Go modules -- changes from pulumi-fabric to pulumi.
* The Node.js SDK package changes from @pulumi/pulumi-fabric to just pulumi.
* The CLI is renamed from lumi to pulumi.
Report an error when Lumi runtime compilation fails.
Also adds a reusable install_release.sh script to use
for installing Lumi package releases, plus expansion
of symlinks in package Makefiles.
This change creates a scripts/ folder, moves our existing shell
script, gocover.sh, underneath it, and factors the publish logic
out of the Makefile and into the publish.sh file.
The syntax for sed differs between Mac OS X and GNU versions of
the tool, which is rather annoying. This fixes it by leveraging
the fact that `sed -i.bak ...` works, although we now need to
clean up the *.bak file left behind. (No big deal and way better
than maintaining OS-dependent logic.)