I got fed up of assert errors in tests that looked like:
```
Expected nil, but got: &result.simpleResult{err:(*errors.fundamental)(0xc0002fa5d0)}
```
It was very hard to work out at a glance what had gone wrong and I kept
having to hook a debugger just to look at what the error was.
With GoString these now print something like:
```
Expected nil, but got: &simpleResult{err: Unexpected diag message: <{%reset%}>resource violates plan: properties changed: -zed, -baz, -foo<{%reset%}>
}
```
Which is much more useful.
* Allow specifying a branch with url#branch
* Probe for master and main
* Update CHANGELOG
* Fix linter errors
* Remove unnecessary feature
* Fix lint
* Update changelog to reflect new limited scope.
We only talk about the master -> main probing, because that is all the
PR does. It used to duplicate another feature.
We have seen cases where a lot of errors like this are reported:
```
UnboundLocalError: local variable 'resources' referenced before assignment
```
This change prevents this failure mode, which might be a symptom of some
other issue, but currently obscures it in the error path.
- [sdk/nodejs] - Allow returning failures from Call in the provider without setting result outputs.
- [sdk/go] - Allow specifying Call failures from the provider.
- Add tests that return failures from Call.
* Added a buildkite detector for detecting the correct env vars in CI
* adding pending changelog entry
* fixed PR logic to actually match the Buildkite Docs and simplified if statement, Fixed a few typos in comments and added PR to CHANGELOG_PENDING.md
* made PR number fetch easier to read
* fixing typo in comment
* Improve corrupt workspace settings experience
This improvement comes in two parts.
1. The error message for a corrupt workspace settings file now clearly
indicates both the file and the parsing error.
2. Writing the workspace settings is now atomic. This prevents
corruption from multiple concurrent calls.
* Use builtin atomic write
* Use builtin ioutil.TempFile
* Change tmp file dir
* Run make ensure on devcontainer creation
Added an ensure target to the dotnet makefile to run `dotnet restore`.
* Add dotnet test explorer and set default vscode settings for it
* Ensure PULUMI_LOCAL_NUGET exists
* Add missing mkdirs
* Validate python version
Note: we do this at the language plugin level because extremely old
version of python (python2) have different syntax, and we don't want
parse errors to occlude our version message. Similarly, if we rely on a
3.7 feature during an import, we will have the same problem.
* Set minimum python version to 3.7.0
* Fix displayed recommended version
Fixes two bugs in how padding was calculated in PrintTable.
Firstly we remove all ANSI escape codes from the string before measuring
how wide it is. Secondly we measure glyph count (using rivo/uniseg) not
byte or rune count of the string.
Together these fix the padding/alignment issues I saw when using
PrintTable with plan output. They also slightly change the layout of
"pulumi stack", for example the below is printed with current master and
has 6 characters of space for padding between SecurityGroup and
web-secgrp:
```
Current stack resources (4):
TYPE NAME
pulumi:pulumi:Stack aws-cs-webserver-test
├─ aws:ec2/securityGroup:SecurityGroup web-secgrp
├─ aws:ec2/instance:Instance web-server-www
└─ pulumi:providers:aws default_4_25_0
```
While printed with this commit you only get 2 characters of space for
padding (which is correct, the column gap is set to " "):
```
Current stack resources (4):
TYPE NAME
pulumi:pulumi:Stack aws-cs-webserver-test
├─ aws:ec2/securityGroup:SecurityGroup web-secgrp
├─ aws:ec2/instance:Instance web-server-www
└─ pulumi:providers:aws default_4_25_0
```
* Don't throw on type mismatches in the dotnet sdk
Fixes#7329
The converter will no longer throw if resource providers return data
that does not match the expected type declared in the dotnet sdk.
Instead a warning will be logged for the resource and the value will be
set to `default(T)`.
While our CI seems happy with this line of code on master, my machine
with the 3.1 sdk is resolving it to non-nullable type and complaining
about the "= null" line later.
```
LocalWorkspace.cs(389,27): error CS8600: Converting null literal or
possible null value to non-nullable type.
[/workspaces/pulumi/sdk/dotnet/Pulumi.Automation/Pulumi.Automation.csproj]
```
Quick fix to just not use "var" here.
* .NET & python SDKs parity for bad pulumi versions
They handle invalid Pulumi CLI version gracefully.
* Make python version property lazy
* Clarify .NET logic
* Add python test for validate_pulumi_version
* Add tests for invalid versions
* Fix python test
* Fix typo
* Fix tests
* Have _validate_pulumi_version handle parsing
* Modify python and .NET to parseAndValidate
* Modify typescript and go to parseAndValidate
* fix name
This change fixes a regression marshaling assets/archives that was introduced after adding support for marshaling output values.
For example, when setting an `Asset` on a field typed as `AssetOrAchiveInput`, in `marshalInput`, the input was being converted into an `AssetOrArchiveOutput` via the `ToAssetOrArchiveOutputWithContext`. Awaiting the output returns an `*asset` struct, which is itself an `AssetInput`, which causes infinite recursion when passed recursively to `marshalInput`.
The fix is to skip the `Input` checks in recursive calls, which is equivalent to the previous behavior before the regression was introduced.
Another issue was that when the input is converted to an output, this would result in `marshalInput` always returning an output value, even if the original passed-in value was not an output. To address this, if the output's value is known, not a secret, and has no dependencies, we can return the value itself rather than wrapping it as an output.
* Fix race condition in TaskMonitoringHelper
Fixes#8163
TaskMonitoringHelper was using two seperate trackers for Idle and
FirstException and then calling WhenAny on both to see which state
happened first. This was racy as you could end up completing a task with
an exception but getting the idle tracker fire first, resulting in
TaskMonitoringHelper thinking no exception had happened.
I've combined the two trackers into TaskMonitoringHelper now. At each
task completion we check for exceptions and then idleness.
* Add changelog