Project: Pulumi (Provisioning / Automation & Configuration)
File: CONTRIBUTING.md

First, thanks for contributing to Pulumi and helping make it better. We appreciate the help! This repository is one of many across the Pulumi ecosystem and we welcome contributions to them all. Please make sure to read and observe our . You are welcome to join the for questions and a community of like-minded folks. We discuss features and file bugs on GitHub via as well as . You can read about our on the . Feel free to pick up any existing issue that looks interesting to you or fix a bug you stumble across while using Pulumi. No matter the size, we welcome all improvements. For larger features, we'd appreciate it if you open a before investing a lot of time so we can discuss the feature together. Please also be sure to browse to make sure your issue is unique, to lighten the triage burden on our maintainers. Finally, please limit your pull requests to contain only one feature at a time. Separating feature work into individual pull requests helps speed up code review and reduces the barrier to merge. You'll want to install the following on your machine: (a ) : see for editor setup instructions You can get all required dependencies with brew and npm ```bash brew install node python@3 typescript yarn go@1.21 golangci/tap/golangci-lint gofumpt pulumi/tap/pulumictl coreutils jq curl https://raw.githubusercontent.com/Homebrew/homebrew-cask/339862f79e/Casks/dotnet-sdk.rb > dotnet-sdk.rb brew install --HEAD -s dotnet-sdk.rb rm dotnet-sdk.rb ``` If you have a web browser, you can get a fully pre-configured Pulumi development environment in one click: ](https://gitpod.io/#https://github.com/pulumi/pulumi) We use `make` as our build system, so you'll want to install that as well, if you don't have it already. We have extremely limited support for doing development on Windows (the bare minimum for us to get Windows validation of `pulumi`) so if you're on windows, we recommend that you use the . We'd like to so feel free to pitch in if you can. We build Pulumi in `$PULUMIROOT`, which defaults to `$HOME/.pulumi-dev`. If you would like to build Pulumi in another location, you do so by setting `$PULUMIROOT`. ```bash export PATH=$HOME/.pulumi-dev/bin:$PATH ``` You'll also need to make sure your maximum open file descriptor limit is set to 5000 at a minimum. ```bash ulimit -n # to test ulimit -n 5000 ``` Across our projects, we try to use a regular set of make targets. The ones you'll care most about are: `make ensure`, which restores/installs any build dependencies `make dist`, which just builds and installs the Pulumi CLI `make`, which builds Pulumi and runs a quick set of tests `make all` which builds Pulumi and runs the quick tests and a larger set of tests. We make heavy use of integration level tests that invoke `pulumi` to create and then delete cloud resources. In order to run our integration tests, you will need a Pulumi account (so today if you haven't already) and log in with `pulumi login`. Additionally, before running integration tests, be sure to set the environment variable `PULUMITESTORG` to your pulumi username. The tests in this repository do not create any real cloud resources as part of testing but still uses Pulumi.com to store information about some synthetic resources the tests create. Other repositories may require additional setup before running

In most cases, this additional setup consists of setting a few environment variables to configure the provider for the cloud service we are testing. Please see the `CONTRIBUTING.md` file in the relevant repository, which will explain what additional configuration is needed before running tests. Numerous tests use baselines that need to be regenerated from time to time. For instance, `pkg/backend/display/testdata` contains the corresponding CLI output for various engine event streams. To regenerate these baselines, run the corresponding test with the `PULUMIACCEPT=true` environment variable. For instance, `PULUMIACCEPT=true make testall` from the root. Alternatively, you can generate them individually, for example, running `PULUMIACCEPT=true go test ./...` from the `pkg/backend/display` directory. 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 a fork of Google's . 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 ```sh $ pulumi preview --logtostderr -v=5 ``` is a pretty standard starting point during debugging that will show a fairly comprehensive trace log of a compilation. Since this repository contains multiple go modules, `gopls` requires a go workspace. Run `make work` to setup a suitable go workspace. For contributors we use the : Fork this repository, create a topic branch, and when ready, open a pull request from your fork. Before you open a pull request, make sure all lint checks pass: ```bash $ make lint ``` If you see formatting failures, fix them by running on your code: ```bash $ gofumpt -w path/to/file.go $ gofumpt -w path/to/dir ``` We require a changelog entry for all PR that aren't labeled `impact/no-changelog-required`. To generate a new changelog entry, run ```bash $ make changelog ```` and follow the prompts on screen. Changelog notes are written in the active imperative form. They should not end with a period. The simple rule is to pretend the message starts with "This change will ..." Good examples for changelog entries are: Exit immediately from state edit when no change was made Fix root and program paths to always be absolute Here's some examples of what we're trying to avoid: Fixes a bug Adds a feature Feature now does something Pulumi employees have write access to Pulumi repositories and should push directly to branches rather than forking the repository. Tests can run directly without approval for PRs based on branches rather than forks. Please ensure that you nest your branches under a unique identifier such as your name (e.g. `refs/heads/pulumipus/cool_feature`). We're sure there are rough edges and we appreciate you helping out. If you want to talk with other folks in the Pulumi community (including members of the Pulumi team) come hang out in the `#contribute` channel on the .