mirror of https://github.com/pulumi/pulumi.git
5f75dd1b26
12574: Add more details to `pulumi stack history` to provide more context. r=dixler a=dixler <!--- Thanks so much for your contribution! If this is your first time contributing, please ensure that you have read the [CONTRIBUTING](https://github.com/pulumi/pulumi/blob/master/CONTRIBUTING.md) documentation. --> # Description After running an update, it's not necessarily clear what envvars or flags were set. This can make it unclear how an update was performed and can make reproductions of issues more difficult. As a user, I set aliases to set flags, export PULUMI envvars in my `.zshrc`, and upgrade pulumi and when looking at an updates that ran successfully a month ago on one machine and may not run successfully on my current machine, I'd like to know this context that performed the update to enable better root cause analysis of the error. To address this, this PR augments the existing Update Metadata to track the: - CLI flags set (name only) - `PULUMI_` Environment Variables set (name and truthiness `true` otherwise `set`) - Version of Pulumi used - Operating System and CPU Architecture (runtime.GOOS, runtime.GOARCH) <!--- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. --> Fixes # (issue) ## Checklist <!--- Please provide details if the checkbox below is to be left unchecked. --> - [x] I have added tests that prove my fix is effective or that my feature works <!--- User-facing changes require a CHANGELOG entry. --> - [x] I have run `make changelog` and committed the `changelog/pending/<file>` documenting my change <!-- If the change(s) in this PR is a modification of an existing call to the Pulumi Service, then the service should honor older versions of the CLI where this change would not exist. You must then bump the API version in /pkg/backend/httpstate/client/api.go, as well as add it to the service. --> - [ ] Yes, there are changes in this PR that warrants bumping the Pulumi Service API version <!-- `@Pulumi` employees: If yes, you must submit corresponding changes in the service repo. --> 12683: sdk/go: Don't drop Dependencies in ResourceOptions snapshot for MLCs r=abhinav a=abhinav We recently added a new API, NewResourceOptions to build a preview of a set of resource options. func NewResourceOptions(...ResourceOption) (*ResourceOptions, error) This currently drops the dependencies of an MLC from the snapshot. The reason for this is that it used a special type "urnSet" to represent dependencies for MLCs received over the wire. This decision was made at the time because the original Resource objects were not available for these dependencies. Turns out that that limitation isn't a blocker: we can use newDependencyResource to create dummy Resource objects that hold nothing but a URN. This allows NewResourceOptions to work on options even inside an MLC. Note that this currently only works for some of the options: those that are propagated from `construct` into the Go SDK options. Others will be added as part of #12154. Testing: The accompanying test failed for Dependencies without this change. Co-authored-by: Kyle Dixler <kyle@pulumi.com> Co-authored-by: Abhinav Gupta <abhinav@pulumi.com> |
||
|---|---|---|
| .. | ||
| pending | ||
| config.yaml | ||