* Make `async:true` the default for `invoke` calls (#3750)
* Switch away from native grpc impl. (#3728)
* Remove usage of the 'deasync' library from @pulumi/pulumi. (#3752)
* Only retry as long as we get unavailable back. Anything else continues. (#3769)
* Handle all errors for now. (#3781)
* Do not assume --yes was present when using pulumi in non-interactive mode (#3793)
* Upgrade all paths for sdk and pkg to v2
* Backport C# invoke classes and other recent gen changes (#4288)
Adjust C# generation
* Replace IDeployment with a sealed class (#4318)
Replace IDeployment with a sealed class
* .NET: default to args subtype rather than Args.Empty (#4320)
* Adding system namespace for Dotnet code gen
This is required for using Obsolute attributes for deprecations
```
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'ObsoleteAttribute' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
Iam/InstanceProfile.cs(142,10): error CS0246: The type or namespace name 'Obsolete' could not be found (are you missing a using directive or an assembly reference?) [/Users/stack72/code/go/src/github.com/pulumi/pulumi-aws/sdk/dotnet/Pulumi.Aws.csproj]
```
* Fix the nullability of config type properties in C# codegen (#4379)
The windows release was appveyor calling a specific build target when
a tag was present. This is now called on a push to any of the branches
in the push category
This means it will not trigger on the pushes to the PR builds
Fixes: #3874
As part of #3656, the build.proj was changed around to support
building and running our tests on windows. The work in that PR added
a lot to get Python, Go and DotNet included in our master and PR runs
for those tests
This PR restores the work to allow the original work for non-PRs (i.e.
tagged builds) to work along side this. It adds a `Release` target which
targets the same build targets as before. It is wrapped in a condition that
will mean it can run when AppVeyor is dealing with a tag (i.e a release)
This means that the existing work to allow all of the master and pr builds
to continue running all of our integration tests will still work as
expected
From the AppVeyor docs (https://www.appveyor.com/docs/branches/):
> Despite the option name, `only` and `except` is applied to tag names
> too, so the above example using only would cause tags not trigger
> the build. For example to enable builds for a tag version scheme
> like v1.0.0 you would need...
We had previously been getting lucky here since our workflow for
releasing was more or less always push master and the tag at the same
time, so the fact that the tag did not also kick off a build was not a
problem.
When releasing 0.17.22, we just pushed a tag for an older commit and
we had to do some gymnastics to get AppVeyor to build it.
Now we won't anymore.
This commit switches from dep to Go 1.12 modules for tracking Pulumi
dependencies. Rather than _building_ using Go modules, we instead use the `go
mod vendor` command to populate a vendor tree in the same way as `dep ensure`
was previously doing.
In order to prevent checksum mismatches, it was necessary to also update CI to
use Go 1.12 instead of 1.11 - which also necessitated fixing some linting errors
which appeared with the upgraded golangci-lint for 1.12.
Pick up a newer version of ssh-agent which has
https://github.com/xanzy/ssh-agent/pull/3 to fix go 1.11 build issues.
Also, lock AppVeyor back to go 1.9, like we use on Travis.
Stop cloning pulumi/home. This doesn't work in Travis because public
repositories can not have private SSH keys, which we'd need to clone
this repository. All the scripts we consume from there are now in
pulumi/scripts and so we'll just consume them from there.
This change eliminates our dependencies on the SDK repo. Now that
SDKs are comprised solely of pulumi/pulumi artifacts, a separate repo
isn't required. This allows us to simplify some of the distribution.
The install.sh script is modified slightly, to permit overriding the
default install location using $PULUMI_INSTALL_PATH.
After the move to stop including packages in the SDK, we no longer
published an SDK per build. This corrects this. Since the only things
in the SDK today are the language plugins and the CLI itself, we can
publish an SDK per build from pulumi/pulumi.
This change re-uses the existing infrastructure we have in
pulumi/sdk.
Fixes#1076
Tests now target managed stacks instead of local stacks.
The existing logged in user and target backend API are used unless PULUMI_ACCES_TOKEN is defined, in which case tests are run under that access token and against the PULUMI_API backend.
For developer machines, we will now need to be logged in to Pulumi to run tests, and whichever default API backend is logged in (the one listed as current in ~/.pulumi/credentials.json) will be used. If you need to override these, provide PULUMI_ACCESS_TOKEN and possibly PULUMI_API.
For Travis, we currently target the staging service using the Pulumi Bot user.
We have decided to run tests in the pulumi organization. This can be overridden for local testing (or in Travis in the future) by defining PULUMI_API_OWNER_ORGANIZATION and using an access token with access to that organization.
Part of pulumi/home#195.
We need to support the current version of the nodejs language host
running programs that use older version of @pulumi/pulumi where the
runtime expected config keys to look like
`<package>:config:<name>`. In the language host we actually did the
transformation from the new format to the old one, for compatability
reasons but we then droped the transfomed value on the floor.
The windows build was still on the old plan from way back when where
we had binaries littered in the build tree and you had to add parts of
your build-tree to the `%PATH%` for the integration tests to work.
This cleans that up and moves all of our scripts that invoke
javascript to be on the same plan. They invoke our specially named
node with a relative path to the JS code we want to run.
We only have one AppVeyor worker and building topic branches causes us
to build large backups in our queues. This is made worse when folks
are iterating on a PR because each push queues not only a PR
build (which we want) but also the topic branch build (which we don't
care about so much).