a2ae4accf4
This change switches from child lists to parent pointers, in the way resource ancestries are represented. This cleans up a fair bit of the old parenting logic, including all notion of ambient parent scopes (and will notably address pulumi/pulumi#435). This lets us show a more parent/child display in the output when doing planning and updating. For instance, here is an update of a lambda's text, which is logically part of a cloud timer: * cloud:timer:Timer: (same) [urn=urn:pulumi:malta::lm-cloud:☁️timer:Timer::lm-cts-malta-job-CleanSnapshots] * cloud:function:Function: (same) [urn=urn:pulumi:malta::lm-cloud:☁️function:Function::lm-cts-malta-job-CleanSnapshots] * aws:serverless:Function: (same) [urn=urn:pulumi:malta::lm-cloud::aws:serverless:Function::lm-cts-malta-job-CleanSnapshots] ~ aws:lambda/function:Function: (modify) [id=lm-cts-malta-job-CleanSnapshots-fee4f3bf41280741] [urn=urn:pulumi:malta::lm-cloud::aws:lambda/function:Function::lm-cts-malta-job-CleanSnapshots] - code : archive(assets:2092f44) { // etc etc etc Note that we still get walls of text, but this will be actually quite nice when combined with pulumi/pulumi#454. I've also suppressed printing properties that didn't change during updates when --detailed was not passed, and also suppressed empty strings and zero-length arrays (since TF uses these as defaults in many places and it just makes creation and deletion quite verbose). Note that this is a far cry from everything we can possibly do here as part of pulumi/pulumi#340 (and even pulumi/pulumi#417). But it's a good start towards taming some of our output spew. |
||
|---|---|---|
| build | ||
| cmd | ||
| dist/sdk/nodejs | ||
| examples | ||
| pkg | ||
| scripts | ||
| sdk | ||
| tests | ||
| .appveyor.yml | ||
| .gitignore | ||
| .gitmodules | ||
| .travis.yml | ||
| .yarnrc | ||
| build.proj | ||
| CONTRIBUTING.md | ||
| Gometalinter.json | ||
| Gopkg.lock | ||
| Gopkg.toml | ||
| LICENSE | ||
| main.go | ||
| Makefile | ||
| README.md | ||
| tslint.json | ||
Pulumi Fabric
The Pulumi Fabric ("Pulumi") is a framework and toolset for creating reusable cloud services.
If you are learning about Pulumi for the first time, please visit our docs website.
Build Status
| Architecture | Build Status |
|---|---|
| Linux x64 |  |
| Windows x64 |
Installing
To install Pulumi from source, simply run:
$ go get -u github.com/pulumi/pulumi
A GOPATH must be set. A good default value is ~/go. In fact, this is the default in Go 1.8.
This installs the pulumi binary to $GOPATH/bin.
To do anything interesting with Pulumi, you will need an SDK for your language of choice. Please see sdk/README.md for information about how to obtain, install, and use such an SDK.
Development
This section is for Pulumi developers.
Prerequisites
Pulumi is written in Go, uses Dep for dependency management, and GoMetaLinter for linting:
- Go: https://golang.org/dl
- Dep:
$ go get -u github.com/golang/dep/cmd/dep - GoMetaLinter:
$ go get -u github.com/alecthomas/gometalinter$ gometalinter --install
Building and Testing
To build Pulumi, ensure $GOPATH is set, and clone into a standard Go workspace:
$ git clone git@github.com:pulumi/pulumi $GOPATH/src/github.com/pulumi/pulumi
$ cd $GOPATH/src/github.com/pulumi/pulumi
The first time you build, you must make configure to install dependencies and perform other machine setup:
$ make configure
In the future, you can synch dependencies simply by running dep ensure explicitly:
$ dep ensure
At this point you can run make to build and run tests:
$ make
This installs the pulumi binary into $GOPATH/bin, which may now be run provided make exited successfully.
The Makefile also supports just running tests (make test), just running the linter (make lint), just running Govet
(make vet), and so on. Please just refer to the Makefile for the full list of targets.
Debugging
The Pulumi tools have extensive logging built in. In fact, we encourage liberal logging in new code, and adding new logging when debugging problems. This helps to ensure future debugging endeavors benefit from your sleuthing.
All logging is done using Google's Glog library. It is relatively bare-bones, and adds basic leveled logging, stack dumping, and other capabilities beyond what Go's built-in logging routines offer.
The pulumi command line has two flags that control this logging and that can come in handy when debugging problems.
The --logtostderr flag spews directly to stderr, rather than the default of logging to files in your temp directory.
And the --verbose=n flag (-v=n for short) sets the logging level to n. Anything greater than 3 is reserved for
debug-level logging, greater than 5 is going to be quite verbose, and anything beyond 7 is extremely noisy.
For example, the command
$ pulumi eval --logtostderr -v=5
is a pretty standard starting point during debugging that will show a fairly comprehensive trace log of a compilation.