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 Contributor Code of Conduct.
You are welcome to join the Pulumi Community Slack for questions and a community of like-minded folks. We discuss features and file bugs on GitHub via Issues as well as Discussions. You can read about our public roadmap on the Pulumi blog.
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 new issue before investing a lot of time so we can discuss the feature together. Please also be sure to browse current issues 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:
- Go (a supported version)
- NodeJS 16.X.X or later
- Python 3.6 or later
- .NET
- Golangci-lint
- gofumpt: see installation for editor setup instructions
- Yarn
- Pulumictl
- jq
You can get all required dependencies with brew and npm
brew install node python@3 typescript yarn [email protected] 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.rbWe 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 Windows Subsystem for Linux. We'd like to make this better so feel free to pitch in if you can.
We build Pulumi in $PULUMI_ROOT, which defaults to $HOME/.pulumi-dev. If you would like to build Pulumi in another location, you do so by setting $PULUMI_ROOT.
export PATH=$HOME/.pulumi-dev/bin:$PATHYou'll also need to make sure your maximum open file descriptor limit is set to 5000 at a minimum.
ulimit -n # to test
ulimit -n 5000Across 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 dependenciesmake dist, which just builds and installs the Pulumi CLImake, which builds Pulumi and runs a quick set of testsmake allwhich 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 sign up for free today if you haven't already) and log in with pulumi login. Additionally, before running integration tests, be sure to set the environment variable PULUMI_TEST_ORG 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 tests. 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 PULUMI_ACCEPT=true environment variable. For instance, PULUMI_ACCEPT=true make test_all from the root. Alternatively, you can generate them individually, for example, running PULUMI_ACCEPT=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 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=5is 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 standard fork based workflow: 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:
$ make lintIf you see formatting failures, fix them by running gofumpt on your code:
$ gofumpt -w path/to/file.go
# or
$ gofumpt -w path/to/dirWe require a changelog entry for all PR that aren't labeled impact/no-changelog-required. To generate a new changelog entry, run…
$ 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
Artifacts built during pull request workflows can be downloaded by running the following command (note that the artifacts expire 7 days after CI has been run):
curl -fsSL https://get.pulumi.com | sh -s -- --version pr#<number>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).
The Pulumi system is robust and offers many features that might seem overwhelming at first. To assist you in getting started, our team has put together the Pulumi Developer Documentation. This resource provides valuable insights into how the system is structured and can be incredibly helpful for both new contributors and maintainers alike. We encourage you to explore it and reach out if you have any questions!
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 Pulumi Community Slack.