Currently this is just setting go.buildTags to "all" so the language
specific tests are included in build and test commands by default.
Missing this leads to the confusing (at least to new people) behavior
of clicking run test on a test method and vscode then saying there is no
test to run.
* Move program tests into folders
* update package schema
* Enabled tests pass
* Fix lints and begin to update test cases
* Re-enable tests
* Update aws version to v4
* Refactor language specific parts
* Hook up dotnet and nodejs
* Update tests from master
* SSOT for schema/version
* Name blocking errors. Leave tests in valid state
* Give each language its own folder
* Remove SkipCompile for azure-sa (bug was fixed)
* Fix nits + changes asserts to require
* Remove unused import
* One last assert => require
* Multi-pass, in-place checks for SDK codegen tests; toward working Python checks
* Remove temp debug output
* Upgrade Node
* Update dotnet; need to follow up on version.txt quirks
* WIP
* Sounds like we can use non-github package names to ensure things are local
* Fix simple-enum-schema
* Fix dash-named-schema
* Fix nested-module
* Start building a test-running pass
* Infer skipping tests from skipping compiles
* Move tree schma tests to a proper place
* Address lint issues on Go code
* Build against local Go SDK
* Update pkg/codegen/internal/test/sdk_driver.go
Co-authored-by: Ian Wahbe <ian@wahbe.com>
* Make go tests work by copying them into the tree from go-extras
* Fix lint
* Fix bad merge
* Manifest-based file discovery
* Remove version-related TODO from dotnet codegen
* Add doc comment
* Do not overwrite go.mod if found from mixins
* Accept python codegen change
* Accept node codegen
* Ignore lint issue
* Accept docs changes
Co-authored-by: Ian Wahbe <ian@wahbe.com>
We run the best static check we can on generated code, ensuring that it is valid.
* Run type checker against all languages (not docs)
* Fix package location, add some deps for schemas
* More tests passing
* These tests finally work
* Make linter happy
* Fix tests for merge from master
* Opt out of input-collision(nodejs) test
* Get more visibility into testing nodejs
* Fix type assumption
* Specify ts-node version
* Retrofit typescript dependencies for node14
* Give each go instance it's own module
* Attempt to diagnose remote go mod init failure
* Provide root for go mod init
* Make linter happy
Resources are serialized as their URN, ID, and package version. Each
Pulumi package is expected to register itself with the SDK. The package
will be invoked to construct appropriate instances of rehydrated
resources. Packages are distinguished by their name and their version.
This is the foundation of cross-process resources.
Related to #2430.
Co-authored-by: Mikhail Shilkov <github@mikhail.io>
Co-authored-by: Luke Hoban <luke@pulumi.com>
Co-authored-by: Levi Blackstone <levi@pulumi.com>
* fix pulumi bot token and env var
* use commit hash non-marketplace actions
* fix goreleaser binaries
foo
* fix goreleaser archive format
* update workflows to use repo-dispatch
* fixing tag naming
* add support for beta tags
* add prerelease workflow
* remove windows builds
* only use travis for tags
* remove prerelease steps
* fix container build indentation
* check the policy tempdir exists
The original version of this code caused inconsistencies in the event
loop associated with a given thread. These changes elimintate the event
loop shenanigans the mocks were trying to play by updating _sync_await
to create an event loop if none exists in the current thread.
It's possible that this will cause problems if the tests run on a
different thread than the original program, as the tests are likely to
end up waiting on outputs created by the program, which is not supported
in Python.
Also adds test coverage of the mocking/testing support in Python.
This change lets us set runtime specific options in Pulumi.yaml, which
will flow as arguments to the language hosts. We then teach the nodejs
host that when the `typescript` is set to `true` that it should load
ts-node before calling into user code. This allows using typescript
natively without an explicit compile step outside of Pulumi.
This works even when a tsconfig.json file is not present in the
application and should provide a nicer inner loop for folks writing
typescript (I'm pretty sure everyone has run into the "but I fixed
that bug! Why isn't it getting picked up? Oh, I forgot to run tsc"
problem.
Fixes#958
Because we run our golang integration tests "in tree" (due to
the need to be under $GOPATH and have a vendor folder around), the
"command-output" folder was getting left behind, dirtying the worktree
after building.
This change does two things:
1. On a succecssful run, remove the folder.
2. Ignore the folder via .gitignore (this way if a test fails and you
do `git add .` you don't end up commiting this folder).
* Fix a few issues with the Python language host
1. Fix an issue where the UNKNOWN sentinel was leaking into user
programs
2. Fix an issue where Protobuf types were leaking into user programs
In fixing this issues I also added a framework for writing tests against
the Python SDK.
* License headers, and adopt a more idiomatic testing pattern
* Additional idiomatic Python
* That's what I get for trying to be fancy (Travis CI python version is very old and does not respect this form)
* CR feedback: use more comprehensions, typo fix
* Break a circular dependency between resource, runtime.resource, and runtime.rpc
* Don't check in .vscode
* CR: sort inputs, rename global variable, add a test for CustomResource serialization
* Remove accidental code duplication
In an effort to improve performance and overall reliability, this PR moves the responsibility of uploading the Pulumi program from the Pulumi Service to the CLI. (Part of fixing https://github.com/pulumi/pulumi-service/issues/313.)
Previously the CLI would send (the dozens of MiB) program archive to the Service, which would then upload the data to S3. Now the CLI sends the data to S3 directly, avoiding the unnecessary copying of data around.
The Service-side API changes are in https://github.com/pulumi/pulumi-service/pull/323. I tested previews, updates, and destroys running the service and PPC on localhost.
The PR refactors how we handle the three kinds of program updates, and just unifies them into a single method. This makes the diff look crazy, but the code should be much simpler. I'm not sure what to do about supporting all the engine options for the Cloud-variants of Pulumi commands; I suspect that's something that should be handled at a later time.
We are now on our fourth vendoring tool: Govendor. This appears to
be about 10X faster than Dep, fails less frequently, and has a rich,
well documented set of commands (that make far more intuitive sense
to me, particularly when compared to Dep). I could never really get
Godep to work with vendor/ correctly, whereas Govendor did the trick
right away. Lastly, Terraform uses it, so we'll probably have fewer
headaches in that department also.
Adds a make task to generate code coverage for all Go sources.
That make task re-runs the tests, and can be fairly expensive,
so it is enabled only in the nightly tests for now.
Part of #206.
We were not propagating the error from `deployLatest` through
to the CLI error result. Despite out recent efforts to integrate
gometalinter, there were also several additional similar cases of
ignored error results reported by `errcheck`. Not yet clear why
these are not being reported via gometalinter.
Fixes#262.
In the old system, the core runtime/toolset understood that we are targeting
specific cloud providers at a very deep level. In fact, the whole code-generation
phase of the compiler was based on it.
In the new system, this difference is less of a "special" concern, and more of
a general one of mapping MuIL objects to resource providers, and letting *them*
gather up any configuration they need in a more general purpose way.
Therefore, most of this stuff can go. I've merged in a small amount of it to
the mu/x MuPackage, since that has to switch on cloud IaaS and CaaS providers in
order to decide what kind of resources to provision. For example, it has a
mu.x.Cluster stack type that itself provisions a lot of the barebone essential
resources, like a virtual private cloud and its associated networking components.
I suspect *some* knowledge of this will surface again as we implement more
runtime presence (discovery, etc). But for the time being, it's a distraction
getting the core model running. I've retained some of the old AWS code in the
new pkg/resource/providers/aws package, in case I want to reuse some of it when
implementing our first AWS resource providers. (Although we won't be using
CloudFormation, some of the name generation code might be useful.) So, the
ships aren't completely burned to the ground, but they are certainly on 🔥.
This adds a bunch of general scaffolding and the beginning of a `build` command.
The general engineering scaffolding includes:
* Glide for dependency management.
* A Makefile that runs govet and golint during builds.
* Google's Glog library for logging.
* Cobra for command line functionality.
The Mu-specific scaffolding includes some packages:
* mu/pkg/diag: A package for compiler-like diagnostics. It's fairly barebones
at the moment, however we can embellish this over time.
* mu/pkg/errors: A package containing Mu's predefined set of errors.
* mu/pkg/workspace: A package containing workspace-related convenience helpers.
in addition to a main entrypoint that simply wires up and invokes the CLI. From
there, the mu/cmd package takes over, with the Cobra-defined CLI commands.
Finally, the mu/pkg/compiler package actually implements the compiler behavior.
Or, it will. For now, it simply parses a JSON or YAML Mufile into the core
mu/pkg/api types, and prints out the result.
