Go to file
Matt Ellis d5e3e8fe9e Move git related warnings back to glog statements
In #1341 we promoted a class of errors in fetching git metadata from
glog messages to warnings printed by the CLI. On the asumption that
when we got warnings here they would be actionable.

The major impact here is that when you are working in a repository
which does not have a remote set to GitHub (common if you have just
`git init`'d a repository for a new project) or you don't call your
remote `origin` or you use some other code provider, we end up
printing a warning during every update.

This change does two things:

- Restructure the way we detect metadata to attempt to make progress
  when it can. We bias towards returning some metadata even when we
  can't determine the complete set of metadata.
- Use a multierror to track all the underlying failures from our
  metadata probing and move it back to a glog message.

Overall, this feels like the right balance to me. We are retaining the
rich diagnostics information for when things go wrong, but we aren't
warning about common cases.

We could, of course, try to tighten our huristics (e.g. don't warn if
we can't find a GitHub remote but do warn if we can't compute if the
worktree is dirty) but it feels like that will be a game of
whack-a-mole over time and when warnings do fire its unlikely they
will be actionable.

Fixes #1443
2018-08-07 18:10:34 -07:00
build Merge updates to install-common-toolchain.sh (#1680) 2018-07-31 23:08:19 -07:00
cmd Move git related warnings back to glog statements 2018-08-07 18:10:34 -07:00
dist Remove SDK dependencies 2018-04-30 16:39:17 -07:00
examples Implement first-class providers. (#1695) 2018-08-06 17:50:29 -07:00
pkg Report initialization errors as warnings during previews as well as updates 2018-08-07 12:02:52 -07:00
scripts Fix Windows publishing 2018-06-17 23:16:58 -07:00
sdk Strip off the node_modules prefix from our require() calls. (#1729) 2018-08-07 20:27:02 -04:00
tests Fix deletes with duplicate URNs. (#1716) 2018-08-07 11:01:08 -07:00
.appveyor.yml Lock to same version of dep as *nix builds 2018-07-30 10:21:34 -07:00
.gitignore Support TypeScript in a more first-class way 2018-08-06 14:00:58 -07:00
.travis.yml Go back to capturing *non-user* modules by 'require' reference. (#1655) 2018-07-31 11:37:46 -04:00
.yarnrc Pass --network-concurrency 1 to yarn 2018-01-29 11:49:42 -08:00
build.proj Bump windows test timeout 2018-06-25 17:31:31 -07:00
CODE-OF-CONDUCT.md Adopt Contributor Covenant code of conduct 2018-05-30 11:01:52 -07:00
CONTRIBUTING.md Added brew install instructions for macOS 2018-08-01 14:32:09 -07:00
Gometalinter.json Add additional linting (#768) 2017-12-27 17:10:12 -08:00
Gopkg.lock Implement first-class providers. (#1695) 2018-08-06 17:50:29 -07:00
Gopkg.toml Make protobuf build more reproducible 2018-07-02 13:31:39 -07:00
LICENSE Relicense under Apache 2.0 2018-05-22 13:52:41 -07:00
main.go Fix main.go copyright header 2018-05-31 08:35:39 -07:00
Makefile Remove build step from build-proto 2018-08-04 10:29:53 -07:00
README.md Make a few README tweaks 2018-06-30 11:48:39 -07:00
tslint.json Enable 'use const' linter rule. (#405) 2017-10-10 14:50:55 -07:00

Slack NPM version Python version GoDoc License

The Pulumi Cloud Development Platform is the easiest way to create and deploy cloud programs that use containers, serverless functions, hosted services, and infrastructure, on any cloud.

Simply write code in your favorite language and Pulumi automatically provisions and manages your AWS, Azure, Google Cloud, and/or Kubernetes resources, using an immutable infrastructure-as-code approach. Skip the YAML, and use standard language features like loops, functions, classes, and package management that you already know and love.

Pulumi is open source under the Apache 2.0 license, supports many languages and clouds, and is easy to extend. This repo contains the pulumi CLI, language SDKs, and core Pulumi engine, and individual libraries are in their own repos.

Welcome

  • Getting Started: get up and running quickly.

  • Tutorials: walk through end-to-end workflows for creating containers, serverless functions, and other cloud services and infrastructure.

  • Examples: browse a number of useful examples across many languages, clouds, and scenarios including containers, serverless, and infrastructure.

  • A Tour of Pulumi: interactively walk through the core Pulumi concepts, one at a time, covering the entire CLI and programming model surface area in a handful of bite-sized chunks.

  • Reference Docs: read conceptual documentation, in addition to details on how to configure Pulumi to deploy into your AWS, Azure, or Google Cloud accounts, and/or Kubernetes cluster.

  • Community Slack: join us over at our community Slack channel. Any and all discussion or questions are welcome.

Getting Started

Follow these steps to deploy your first Pulumi program, using AWS Serverless Lambdas, in minutes:

  1. Install:

    To install the latest Pulumi release, run:

    $ curl -fsSL https://get.pulumi.com/ | sh
    
  2. Configure your Cloud Provider so that Pulumi can deploy into it.

  3. Create a Project:

    After installing, you can get started with the pulumi new command:

    $ pulumi new hello-aws-javascript
    

    The new command offers templates for all languages and clouds. Run it without an argument and it'll prompt you with available projects. This command created an AWS Serverless Lambda project written in JavaScript.

  4. Deploy to the Cloud:

    Run pulumi update to get your code to the cloud:

    $ pulumi update
    

    This makes all cloud resources needed to run your code. Simply make edits to your project, and subsequent pulumi updates will compute the minimal diff to deploy your changes.

  5. Use Your Program:

    Now that your code is deployed, you can interact with it. In the above example, we can curl the endpoint:

    $ curl $(pulumi stack output url)
    
  6. Access the Logs:

    If you're using containers or functions, Pulumi's unified logging command will show all of your logs:

    $ pulumi logs -f
    
  7. Destroy your Resources:

    After you're done, you can remove all resources created by your program:

    $ pulumi destroy -y
    

Please head on over to the project website for much more information, including tutorials, examples, and an interactive tour of the core Pulumi CLI and programming model concepts.

Platform

CLI

Architecture Build Status
Linux/macOS x64 Linux x64 Build Status
Windows x64 Windows x64 Build Status

Languages

Language Status Runtime
JavaScript Stable Node.js 6.x-10.x
TypeScript Stable Node.js 6.x-10.x
Python Preview Python 2.7
Go Preview Go 1.x

Clouds

Cloud Status Docs
Amazon Web Services Stable Docs
Microsoft Azure Preview Docs
Google Cloud Platform Preview Docs
Kubernetes Preview Docs

Libraries

There are several libraries that encapsulate best practices and common patterns:

Library Status Docs Repo
AWS Serverless Preview Docs pulumi/pulumi-aws-serverless
AWS Infrastructure Preview Docs pulumi/pulumi-aws-infra
Pulumi Multi-Cloud Framework Preview Docs pulumi/pulumi-cloud

Development

If you'd like to contribute to Pulumi and/or build from source, this section is for you.

Prerequisites

Pulumi is written in Go, uses Dep for dependency management, and GoMetaLinter for linting:

Building and Testing

To install the pre-built SDK, please run curl -fsSL https://get.pulumi.com/ | sh, or see detailed installation instructions on the project page. Read on if you want to install from source.

To build a complete Pulumi SDK, 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 ensure to install dependencies and perform other machine setup:

$ make ensure

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_all or make test_fast), 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 preview --logtostderr -v=5

is a pretty standard starting point during debugging that will show a fairly comprehensive trace log of a compilation.