This change rearranges some of the code generator logic in LumIDL
in such a way that we can use it from other code generators (like
the ongoing bridge work).
This adds a ReadLocations RPC function to the engine interface, alongside
the singular ReadLocation. The plural function takes a single token that
represents a module or class and we will then return all of the module
or class (static) properties that are currently known.
This adds a handy MapReplace function on pkg/resource's PropertyMap and
PropertyValue types. This is just like the existing Mappable function,
except that it permits easy replacement of elements as the map transformation
occurs. We need this to perform float64=>int transformations.
Disable invocation of `lumi plan` during examples
integration testing, pending resolution of #276 to
support planning in the face of output properties.
We fail very late in the process of plan application, should a duplicate
URN arise. This change fails as early in the process as possible and
ensures that it does so with good line number information.
This properly unwinds the interpreter should something happen that
results in cancellation. This occurs, for example, when the planning
engine encounters an error and decides that it doesn't need to proceed
further with evaluation before it simply goes ahead and exits.
The old contract library tried to be glog-friendly in its failfast behavior.
It turns out glog seldom does the right thing when goroutines are involved
(which, as of last sprint, they now are). We already had issues with stacks
not getting printed when --logtostderr was turned on, and the code tried
to work around this; but this still didn't work for the goroutines case.
All of this seems like way too much cleverness. Let's just use Go panics.
It appears Gometalinter updated to a more recent version of staticcheck,
which is more aggressive in some of its checking. This turned up a break
warning (which was a false positive but I find the code easier to follow
this new way anyhow).
This change starts running Check with a "" property for cases where
global validation must take place (such as ensuring that required
configuration variables were set). It may be safely ignored if per-
property validation is preferred by a given resource.
Adds the `Content*` properties on S3 Objects to the
Object resource. Allow update of Objects with new
sources and/or content properties.
Also adds AWS provider test support for validating
resource output properties.
Contributes to #218.
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.
Instead of cleaning up all resources that might have been
created by the test suite, we now only cleanup resources
created by this specific run of the tests. That makes
concurrent test execution safer, and the tests more self-
contained. However, it does increase the chances of
accidentially leaving behind resources when tests fail.
Fixes#265.
This change enables VM-based builds in Travis, versus the default of
container-based builds. This will give us more memory (7.5GB rather
than 4GB max), and more compute (~2, bursted rather than 2). This
may help to fix some of the build/test speed time issues we are seeing.
Address several issues with running the Beanstalk
example in newer AWS regions with different requirements.
Ensures S3 bucket names adhere to required naming patterns
outside of us-east-1.
Also add InstanceProfile and ServiceRole configuration to the
beanstalk example as required in newer regions.
This adds a few missing closes for the plugin host/context. This
should fixpulumi/lumi#261. Eventually when we have more robust
nightly test options, and want to spend the time, we should think
about doing more rigorous stress testing that kills processes at
inopportune times and guarantees we don't leak. I've filed
pulumi/lumi#263 to do that.
This should fix the issues with escaping in Travis (fingers crossed).
Also specifies the -e flag for echo, since switching the shell to
bash led to ANSI escape codes being uninterpreted by default.
Apparently because Travis is using containers with a small number
of processors, 2m isn't long enough a deadline. (I have never seen
us exceed this on my own machine). Increasing to 5m.
This change fixes a few things:
* Most importantly, we need to place a leading "." in the paths
to Gometalinter, otherwise some sub-linters just silently skip
the directory altogether. errcheck is one such linter, which
is a very important one!
* Use an explicit Gometalinter.json file to configure the various
settings. This flips on a few additional linters that aren't
on by default (line line length checking). Sadly, a few that
I'd like to enable take waaaay too much time, so in the future
we may consider a nightly job (this includes code similarity,
unused parameters, unused functions, and others that generally
require global analysis).
* Now that we're running more, however, linting takes a while!
The core Lumi project now takes 26 seconds to lint on my laptop.
That's not terrible, but it's long enough that we don't want to
do the silly "run them twice" thing our Makefiles were previously
doing. Instead, we shall deploy some $$($${PIPESTATUS[1]}-1))-fu
to rely on the fact that grep returns 1 on "zero lines".
* Finally, fix the many issues that this turned up.
I think(?) we are done, except, of course, for needing to drive
down some of the cyclomatic complexity issues (which I'm possibly
going to punt on; see pulumi/lumi#259 for more details).
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.
Make RestAPI more robust to TooManyRequestsException.
Fix imports in minimal example.
Make printing for examples test more explicit to help with diagnostics during parallel test execution.
This disables gotype as a linter, since it depends on object files
in an annoying way (and doesn't add much beyond go build anyway).
From alecthomas/gometalinter#206, it sounds like the current plan
is to remove gotype entirely from the set of linters GML runs.
After 233c5a8 landed, I noticed there are a few things to be fixed up:
* Run gometalinter in all the right places. We need to run both in
lint and lint_quiet targets. I've also cleaned up some of the logic
around what to suppress so there's less repetition.
* We currently @ meaningful commands, which is unfortunate, since it
makes debugging Makefiles tough (especially when looking at CI build
logs). Going forward, we should only use @ for meaningless commands,
like @echo.
* The AWS project wasn't actually running tslint, because it needs to
say `tslint './pack/**/*.ts' --exclude='./pack/node_modules/**'`.
The current script of `tslint lib/aws/pack/...` wasn't actually
running lint, hence we missed a lot of AWS lint issues.
* Fix up the issues that these fixes uncovered. Mostly err shadowing.
