The Go template Sprig function kindIs is used to test the type of a value:
kindIs "string" "hello" returns true.
What if the string is actually "true", not the boolean true. Is there a special character or any other mean?
(I can add a space after: "true " but it's not exactly a solution).
Should have put more background in the question: this came about when executing a Bake stage in a Spinnaker pipeline, with Key Overrides. One key (let's call it my-key) was overridden with value true . Bake stage failed at execution. Reproduced the error by doing a helm template command with --set my-key=true, outside spinnaker. The error had to do with kindIs checking for string but getting boolean (true). Changing to "true" didn't help.
Solution was to use helm option --set-string instead of --set.
My Spinnaker pipeline had the Raw Overrides checked hence the Overrides were done with --set iso --set-string.
Here's the Help pop up for Raw Overrides:
Use --set instead of --set-string when injecting override values. Values injected using --set will be converted to primitive types by Helm.
Just had to remove the Raw Override.
Related
I've seen different ways of setting / using Cache variables in Cmake.
What is the standard?
What's the point of setting an empty string ("") to the cache variable?
Example
set(NVTX_ROOT_DIR "" CACHE PATH "Folder contains NVIDIA NVTX")
What's the point of setting an empty string ("") to the cache variable?
It is not just setting a value for a CACHE variable.
Command flow set(CACHE) normally performs two things:
Declares the parameter (assigns description and possibly the type)
Sets the parameter's default value. (That is, if the parameter is already set, its value isn't changed).
Empty value for CACHE variable could mean that a parameter denoted by this variable is not set. Depending on the project which uses it, this could be interpreted as:
Do not use functionality described by the parameter.
Emit an error telling the parameter should be set by a user.
In CMake code checking the parameter could be implemented with simple if(VAR):
if(NVTX_ROOT_DIR)
# The parameter is set
else()
# The parameter is not set
endif()
While if(NVTX_ROOT_DIR) is false even if the variable is not set, declaring the parameter is impossible without setting its value. So empty string as a default value is a logical choice for being able to use simple if(NVTX_ROOT_DIR) for check absence of the parameter's setting.
I have environmental variable called ENV, which holds the DEV,QA OR PROD region as value. When the server.xml loaded it includes the corresponding db configuration using this variable. For ex: db-config-${env.GAH_ENV}.xml
I would like to pass the same value to the batch job xml as a job parameter or properties to any of the class. How Can I do that.
below code snippet not working
<property name="environment" value="${env.GAH_ENV}"/>
The short answer is that using a batch property may not be a good solution and you might consider something else like MicroProfile's #ConfigProperty.
The reason is there's not a built-in way to access environmental variables through JSL substitution. There is also not a convenient way for one artifact to set a property value to be used by a second artifact running later within the job execution.
In the special case that you are starting the job from within the same JVM it will execute, of course, you could pass the env var value as a job parameter.
But in the general case, if you can change the Java code and you don't really need a batch property I would use a MicroProfile Config property instead, injected via #Inject #ConfigProperty.
By doing so you lose the batch-specific substitution precedence, including the override available via job parameters passed with the submit/start. You also give up the ability to use this property in other JSL substitutions (to "compose" its value into other batch properties via other substitutions).
But you at least get a property with its own various levels of precedence/override (e.g. server config, env var, microprofile-config.properties), which is more flexible than just always reading the env var via System.getenv( ).
This is certainly an area to consider for the next version of the (now-Jakarta) Batch spec.
I'm using map variables and the lookup function to configure aws differently depending on the workspace selected. It works fine when the variable contains string but I can't get it to work with arrays and I'm not sure if it's possible
I've poured over the terraform documentation but can't see to sort it out. It looks like it can't be down with a map of arrays. Maybe someone has sorted through this issue
variable "cidr" {
type = "map"
default = {
"prod" = ["10.7.3.0/24","10.7.4.0/24"]
"test" = ["10.8.3.0/24","10.8.4.0/24"]
}
}
cidr = ${lookup(var.cidr, terraform.workspace)}"
lookup() can only be used with maps of
primitive types.
If you are using Terraform v0.12.0 or later, the idiomatic way to access one of the lists from your map of lists is to use the index syntax:
cidr = var.cidr[terraform.workspace]
You can also use the index syntax in Terraform v0.11 or earlier, but it must be wrapped in a template string because that is how we indicate to Terraform that we intend to use an expression in those older versions:
cidr = "${var.cidr[terraform.workspace]}"
The lookup function is for situations where you don't know if the given key is present and want to provide a default value to use instead if it is not. Although lookup with only two arguments is still supported for backward-compatibillity, it should generally be used only in its three-argument form in modern Terraform:
# (this particular default is likely not a good idea, but this
# is just to illustrate the syntax.)
cidr = lookup(var.cidr, terraform.workspace, ["0.0.0.0/0"])
Until Terraform 0.12.7, the lookup function is indeed restricted to only work with maps of primitive types. In Terraform 0.12.7 it was generalized to behave the same way as the index operator, but with the extra rule of returning the default value if the requested key isn't present.
As a side note, if you are using Terraform v0.12.0 or later then you can provide a more specific type constraint on that variable:
variable "cidr" {
type = map(list(string))
default = {
"prod" = ["10.7.3.0/24","10.7.4.0/24"]
"test" = ["10.8.3.0/24","10.8.4.0/24"]
}
}
By telling Terraform exactly what element types are expected for the list and map type, Terraform can automatically check the value provided by the caller to make sure it conforms, and report a type error if not. If you just write "map" then that's a legacy shorthand for map(any), in which case Terraform can only check that it's a map of any single type, not specifically what the element type must be. I'd recommend always using exact type constraints in Terraform 0.12.0 or later.
I have configured a Modeshape workspace on my dev box using XML, pointing to:
workspaceRootPath="C:/jcr/modeshape/dev/..."
I will deploy to Linux with a workspace mounted on a different volume:
workspaceRootPath="/jcr/modeshape/prod/..."
Is it possible to use an environment variable to configure this or do I need to resort to programmatic configuration? Is there an approach recommended by the Modeshape team?
Thanks
If you're using later versions of ModeShape, you can use a variable in the configuration file that will be replaced at configuration load time with the value of the System property of the same name. For example, if you use the following:
workspaceRootPath="${myWorkspaceDirectory}"
and have a System property "myWorkspaceDirectory" set to "/foo/bar", then when ModeShape loads the configuration it will resolve the variable into the equivalent:
workspaceRootPath="/foo/bar"
Of course, the variable can be just a part of the attribute value, and you can even use multiple variables (as long as they're not nested). For example, this is valid, too:
workspaceRootPath="${my.system.root.path}/modeshape/${my.system.deploymentType}"
Finally, the grammar of each variable is:
"${" systemPropName { "," systemPropName } [ ":" defaultValue ] "}"
This allows 1 or more System property names and an optional default value to be specified within a single variable. The System property names are evaluated from left to right, and the first to have a corresponding real system property will be used. Here's another contrived example:
workspaceRootPath="${my.system.path1,my.system.path2,my.system.path3:/default/path}/modeshape/${my.system.deploymentType}"
In an SSIS package I have a For..Each container that enumerates all (.) the files in a folder.
In that For..Each container I have a component-level variable 'fileComments' of DataType 'String'.
In that For..Each container I have a script task. With a ReadWrite entry for 'filecomments' (amongst others)
In that script task, I have some code :-
Dim Comments As String = Dts.Variables("User::fileComments").ToString
which allows me to read the value of that variable, but if I try to allocate a value back to that variable, I get a Property 'Item' is 'ReadOnly' blue squiggly underline.
How do I change the vlaue of that variable (or get the value out of the script task so I can use it later in the flow) ?
Thanks in advance.
your problem is a common trap check this article out:
http://www.programmersedge.com/?p=1350
you basically need to use the Dts.VariableDispenser object to lock or declare the variable as read / write in the script task.