2017-06-26 23:46:34 +02:00
|
|
|
// Copyright 2016-2017, Pulumi Corporation. All rights reserved.
|
2017-02-19 20:41:05 +01:00
|
|
|
|
|
|
|
package errors
|
|
|
|
|
|
|
|
// Plan and apply errors are in the [2000,3000) range.
|
|
|
|
var (
|
2017-02-22 03:31:43 +01:00
|
|
|
ErrorCantCreateCompiler = newError(2000, "An error occurred during compiler construction: %v")
|
|
|
|
ErrorCantReadPackage = newError(2001, "An error occurred while reading the package '%v': %v")
|
2017-03-23 16:15:10 +01:00
|
|
|
ErrorCantCreateSnapshot = newError(2002, "A problem was found during planning: %v")
|
2017-02-22 03:31:43 +01:00
|
|
|
ErrorPlanApplyFailed = newError(2003, "Plan apply failed: %v")
|
|
|
|
ErrorIllegalMarkupExtension = newError(2004, "Resource serialization failed; illegal markup extension '%v'")
|
2017-02-26 20:20:14 +01:00
|
|
|
ErrorCantReadDeployment = newError(2005, "Could not read deployment file '%v': %v")
|
2017-03-03 02:10:10 +01:00
|
|
|
ErrorDuplicateURNNames = newError(2006, "Duplicate objects with the same URN: %v")
|
2017-10-16 21:04:35 +02:00
|
|
|
ErrorInvalidStackName = newError(2007, "Stack '%v' could not be found in the current workspace")
|
Support config maps
This change adds support for configuration maps.
This is a new feature that permits initialization code to come from markup,
after compilation, but before evaluation. There is nothing special with this
code as it could have been authored by a user. But it offers a convenient
way to specialize configuration settings per target husk, without needing
to write code to specialize each of those husks (which is needlessly complex).
For example, let's say we want to have two husks, one in AWS's us-west-1
region, and the other in us-east-2. From the same source package, we can
just create two husks, let's say "prod-west" and "prod-east":
prod-west.json:
{
"husk": "prod-west",
"config": {
"aws:config:region": "us-west-1"
}
}
prod-east.json:
{
"husk": "prod-east",
"config": {
"aws:config:region": "us-east-2"
}
}
Now when we evaluate these packages, they will automatically poke the
right configuration variables in the AWS package *before* actually
evaluating the CocoJS package contents. As a result, the static variable
"region" in the "aws:config" package will have the desired value.
This is obviously fairly general purpose, but will allow us to experiment
with different schemes and patterns. Also, I need to whip up support
for secrets, but that is a task for another day (perhaps tomorrow).
2017-02-28 04:43:54 +01:00
|
|
|
ErrorIllegalConfigToken = newError(2008,
|
2017-03-31 00:06:55 +02:00
|
|
|
"Configs may only target module properties and class static properties; '%v' is neither")
|
2017-03-03 03:15:38 +01:00
|
|
|
ErrorConfigApplyFailure = newError(2009, "One or more errors occurred while applying '%v's configuration")
|
2017-06-27 22:04:06 +02:00
|
|
|
ErrorDuplicateResourceURN = newError(2010, "Duplicate resource URN '%v'; try giving it a unique name")
|
|
|
|
ErrorResourceInvalid = newError(2012, "%v resource '%v' has a problem: %v")
|
|
|
|
ErrorResourcePropertyInvalidValue = newError(2013, "%v resource '%v's property '%v' value %v has a problem: %v")
|
|
|
|
ErrorAnalyzeFailure = newError(2014, "Analyzer '%v' reported an error: %v")
|
|
|
|
ErrorAnalyzeResourceFailure = newError(2015,
|
2017-03-11 19:07:34 +01:00
|
|
|
"Analyzer '%v' reported a resource error:\n"+
|
|
|
|
"\tResource: %v\n"+
|
|
|
|
"\tProperty: %v\n"+
|
|
|
|
"\tReason: %v")
|
2017-02-19 20:41:05 +01:00
|
|
|
)
|