Previous logic had assumed arrays were treated like objects
in the runtime (like in ECMAScript), but they are a unique
value kind in current Lumi runtime, so must be handled separately.
At the moment, we permit resources to carry a name, which the
engine uses as part of URN creation. Unfortunately, the property
"name" has a very high chance of conflicting with meaningful
user-authored properties. And furthermore this sort of name,
although key to creating URNs which are core to how the overall
system performs deployments and manages resources, are seldom
used programmatically in Lumi programs. As a result, it's a real
nuisance that we stole the good name.
This change renames that property from "name" to "urnName". This
not only has a lower likelihood of conflicting, but it also looks
reasonable sitting alongside the "urn" property. In fact, in some
future universe, after some of the upcoming runtime changes, we
may not even need the name property on the objects whatsoever.
I had originally toyed with the idea of eliminating the Resource
versus NamedResource distinction. This is certainly simpler and
remains a possibility. I didn't do that right now, however, because
the flexibility of letting resource providers name resources however
they see fit still seems possibly useful. For example, we keep
talking about whether functions can be auto-named based on hashes.
Until we've run those conversations to ground, I'd hate to do some
work that just needs to be undone in order to enable a scenario that
has a non-trivial likelihood of us wanting to explore.
We are renaming Lumi to Pulumi Fabric. This change simply renames the
pulumi/lumi repo to pulumi/pulumi-fabric, without the CLI tools and other
changes that will follow soon afterwards.
Report an error when Lumi runtime compilation fails.
Also adds a reusable install_release.sh script to use
for installing Lumi package releases, plus expansion
of symlinks in package Makefiles.
This change copies the NPM package files to the installation directory
so that the result is a valid NPM package. This is a temporary workaround
until (😨) the day that we actually publish/consume real NPM packages...
Until we support output-conditional code (pulumi/lumi#170), we
run into cases where we want to make a decision based on a computed
property if it is available, but can't possible know the value. In
such cases, we get an error ("Unexpected computed value").
In fact, our generated code currently includes client side validation
of properties, since it leads to a(n admittedly only slightly) better
developer experience. But that triggers the error for required
properties that are computed, basically hosing our ability to plan.
This change introduces a defaultIfComputed intrinsic to the lumirt
library that can be used to work around this. It takes two arguments,
obj and def, and returns the actual property value obj if it is NOT
computed; if it is computed, def will be substituted in its stead.
The generated code changes to use this. It's possible it will miss
validation, of course, if a computed property turns out not to match
the precondition. But this is strictly better than the alternative
of not trying to validate any of them to begin with.
This reverts commit c3db70849d.
I've opted to take a new strategy to ensure the bridge properties
don't conflict (with manual renames), similar to the name property.
This change recognizes assets and archives as 1st class resource
property values. This is necessary to support them in the new bridge
work, and lays the foundation for fixing pulumi/lumi#153.
I also took the opportunity to clean up some old cruft in the
resource properties area.
This renames the basemost resource properties, id and urn, to
names that are less likely to conflict with properties that real
resources will want to use, pid and upn (provider ID and Universal
Pulumi Name, respectively).
I actually ran into this with the current bridge work. An alternative
solution would be to require derived resources to pick different names,
however this is unfortunate because usually they are more "user-facing"
than ours. Another alternative is to not hijack the object properties
at all, but that too is problematic because we use these properties
during the evaluation of plans and deployments.
This seems like a reasonable middle ground.
Remove duplicative call to UpdateFunctionConfiguration.
Also ensure that free variables returns stable variable order
to avoid unnecessary lambda updates.
Lumi returns references to the `this` variable as
`.this`, so we need to rewrite these when emitting
into Lambdas. In addition, the TypeScript compilation
of lambda functions requires that we create an environment
for executing the generated code where `this` has the
right value, which requires some subtle changes to our code
generation.
Adds support for serializing lambdas which are
properties of captured objects.
For example:
```
let o = {
f: () => 12
};
let func = new aws.serverless.Function("func", {policies: [aws.iam.AWSLambdaFullAccess]}, (ev, ctx, cb) => {
console.log(o.f());
cb(null, null);
});
```
Generate names for serialized functions as hashes of the function text, and
bind these to the actual referenced names locally to each serialized closure.
This avoids potential conflicts between different functions which are referenced
with the same name.
For example:
```
function __8c176d768f95567f8c3acd08e486a1da7299fbc1() {
with({ f: __e61452ceb9d53f3611ed543f3822a85ad29345dd}) {
return (() => {
return function (cb) { cb(null, f(7)); };
})().apply(this, arguments);
}
}
```
Also fixes the stack overflows when there are cycles in the Closure graph by
adding caches of serialized functions.
Fixes#238.
We need to provide higher level abstractions with the
ability to set additional properties on a Lambda Function
even when using the closure serialization support of
aws.serverless.Function.
Note that this is an API breaking change, and may require
updates in any other libraries dependent on this API.
We would like to allow developers to use async/await
on the inside (Node.js) of Lumi programs.
We now support (don't error on) usage of async/await
inside runtime callbacks in Lumi programs. If await is
used during deployment, it will trigger an error.
Also adds support for try/catch in LumiJS, as these are
used more heavily in async/await code.
Since we target Node.js environments without native support
for async/await, we also emit runtime helpers to support TS
transpilation of async/await for Node.js pre-7.6.
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.
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.
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 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).
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.
