Our previous strategy of just using `git describe --tags --dirty` to
compute a version caused issues. The major one was that since version
sort lexigrapically, git's strategy of having a commit count without
leading zeros lead to cases where 0.11.0-dev-9 was "newer than"
0.11.0-dev-10 which is not what you want at all.
With this change, we compute a version by first seeing if the commit
is tagged, and if so, we use that tag. Otherwise, we take the closest
tag and to it append the unix timestamp of the commit and then append
a git hash.
Because we use the commit timestamp, things will sort correctly again.
Part of pulumi/home#174
This change uses virtualenv to insulate us from platform differences
in our building of the Python SDK, and to create an isolated Python 2
environment. This includes meaning we don't need to worry about the
specific location and behavior of Pylint. I *think* this will work
no matter whether it's Mac, Ubuntu, ArchLinux, Windows, and so on.
We do install to the --user directory in the install target using
`pip install -e`, however, which enables the machine-wide symlinking
that we need to support various workflows.
This fixespulumi/pulumi#1007.
While it's safe to publish the tgz that we use internally for other
repositories that are on "the link plan" after the build completes, we
shouldn't publish packages to NPM and PyPi at that point. There are
two reasons for doing this:
1. Publishing packages before they are tested, which means we could
end up publishing packages that don't work.
2. NPM prevents publishing the same package more than once, so if we
had to re-run the job (due to tests failing for transient issues), the
publish step will start failing, preventing us from running the tests
at all.
Make many fixes to closure serialization
Primary things that i've done as part of this change:
Added support for cyclic objects.
Properly serialize objects that are shared across different function. previously you would get multiple copies, now you properly reference the same copy.
Remove the usages of 'hashes' for functions. Because we track identity of objects, we no longer need them.
Serialize properties of functions (if they have any).
Handle Objects/Functions with different __proto__s than normal. i.e. classes/constructors. but also anything the user may have done themselves to the object.
Handle generator functions.
Handle functions with 'computed' names.
Handle functions with 'symbol' names.
Handle serializing Promises as Promises.
Removed the dual Closure/AsyncClosure tree. One existed solely so we could have a tree without promises (for use in testing maybe?). Because this all exists in a part of our codebase that is entirely async, it's fine to have promises in the tree, and to await them when serializing the Closure to a string.
Handle serializing class-constructors and methods. Including properly handling 'super' calls.
We now publish the Pulumi Python SDK package to our private PyPI
server at the same time we also publish the NPM package. For now,
we use the test Pulumi.com service, and will switch to staging as
soon as it becomes available.
This change refactors the way we do ${VERSION} substitution in both
the Node.js SDK's version.js and package.json, so that it can work on
Windows. This is required now that we are actually parsing semvers.
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.
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.
