Change vars in JS file with grunt task - gruntjs

Let's say you have a file that contains these 2 vars, but also other content
//Other code above
var endpoint='...';
var redirectUrl='...';
//Other code below
Now, is there a way for Grunt to change the value of those vars depending on build params?
Thanks.

If you enclose your line with something easily matchable. (Or if the original values are unique enough, it can be fine as well.)
You can use this plugin:
https://github.com/outaTiME/grunt-replace
To replace it with something else.

Related

how to get list of Auto-IVC component output names

I'm switching over to using the Auto-IVC component as opposed to the IndepVar component. I'd like to be able to get a list of the promoted output names of the Auto-IVC component, so I can then use them to go and pull the appropriate value out of a configuration file and set the values that way. This will get rid of some boilerplate.
p.model._auto_ivc.list_outputs()
returns an empty list. It seems that p.model__dict__ has this information encoded in it, but I don't know exactly what is going on there so I am wondering if there is an easier way to do it.
To avoid confusion from future readers, I assume you meant that you wanted the promoted input names for the variables connected to the auto_ivc outputs.
We don't have a built-in function to do this, but you could do it with a bit of code like this:
seen = set()
for n in p.model._inputs:
src = p.model.get_source(n)
if src.startswith('_auto_ivc.') and src not in seen:
print(src, p.model._var_allprocs_abs2prom['input'][n])
seen.add(src)
assuming 'p' is the name of your Problem instance.
The code above just prints each auto_ivc output name followed by the promoted input it's connected to.
Here's an example of the output when run on one of our simple test cases:
_auto_ivc.v0 par.x

Identing a map from a yaml template in terraform

I am in Terraform 14 and I am trying to add labels to my template file which should generate a YAML:
Template File:
labels:
${labels}
Code:
locals {
labels = merge(
var.labels,
map(
"module", basename(abspath(path.module)),
"module_version", var.module_version
)
)
prometheus_config = templatefile("${path.module}/prometheus.tmpl", {
labels = indent(8, yamlencode(local.labels))
})
When I try to add the labels indenting with 8 this outputs in the template file causing YAML errors:
Error Output:
labels:
"module": "my_module"
"module_version": "1.0"
As you can see the module_version has indent 8 which is correct but the module line is not indented.
I tried many things like moving ${labels} everywhere in the beginning, with multiple indentations but nothing seems to work.
It is for this reason that the templatefile documentation recommends using yamlencode for the entire data structure, rather than trying to concantenate bits of YAML together using just string templates. That way the yamlencode function can guarantee you a correctly-formatted result and you only have to produce a suitable data structure:
In your case, that would involve replacing the template contents with the following:
${yamlencode({
labels = labels
})}
...and then replacing the prometheus_config definition with the following:
locals {
prometheus_config = templatefile("${path.module}/prometheus.tmpl", {
labels = local.labels
})
}
Notice that the yamlencode call is now inside the template, and it covers the entire YAML document rather than just a fragment of it.
With a simple test configuration I put together with some hard-coded values for the variables you didn't show, I got the following value for local.prometheus_config:
"labels":
"module": "example"
"module_version": "1.0"
If this was a full example of the YAML you are aiming to generate then I might also consider simplifying but just inlining the yamlencode call directly inside the local value definition, and not have the separate template file at all:
locals {
prometheus_config = yamlencode({
labels = local.labels
})
}
If the real YAML is much larger or is likely to grow larger later then I'd probably still keep that templatefile call, but I just wanted to note this for completeness, since there's more than one way to get this done.
So using terraform 14 I was not able to transform lists or maps into yaml with yamlencode. Every option I tried using the suggested answer produced results with the wrong indentation. Maybe due to the many indentation levels in the file... I am not sure. So I dropped the use of yamlencode in the solution.
Solution:
I decided to use inline solution so for lists I transform then with string with join and for maps I use jsonencode so:
# var.list is a list in terraform
# local.abels is a map in terraform
thanos_config = templatefile("${path.module}/thanos.tmpl", {
urls = join(",", var.list),
labels = jsonencode(local.labels)
})
The resulting plan output is a bit ugly but it works.

Yocto: Is there a way to remove items of SRC_URI in local.conf?

We are using custom kernel, so I override variables defined in linux-imx_xxx.bb:
KERNEL_SRC_pn-linux-imx = "our_url"
SRCBRANCH_pn-linux-imx = "our_branch"
SRCREV_pn-linux-imx = "${AUTOREV}"
It works. But many patch files added in linux-imx_xxx.bb and out custom kernel have patched.
So I want to just remove patch files in local.conf, and not touch any .bb files defined in official meta-fsl-* layers.
SRC_URI_remove_pn-linux-imx = " file://*.patch"
But this doesn't work. So is there a way to do this in local.conf?
BTW I know the .bbappend should works, but again, I don't want change any meta-fsl-* layers.
You can't use a wildcard because _remove is literal string removal. Spell out the files you want to remove, and you'll be fine.
However if you're using a custom kernel then just write a new recipe for it, no point taking linux-imx and editing it from local.conf.

Set CSS for dynamic element CoffeeScript

I am trying to write a code that set CSS for some dynamic elements added on click on a link.
As per the example code in CoffeeScript tutorial it should be working with the following code.
temp = temp+1
$ '.box_'+temp
.css 'background', 'white'
Here temp is a variable integer.
I tried with static values like
$ '.box_1'
.css 'background', 'white'
but it returns something like this with .css not a function error
$('.box_1'.css('left', 100));
Just add parens to remove ambiguity and save yourself the headache.
temp = temp+1
$('.box_'+temp)
.css('background', 'white')
Sexy function calls are optional syntactic sugar, not required. You should not be using language features if doing so makes your code less clear for humans or machines (or in this case, both!)

Cucumber: In which order the feature tags are followed in a cucumber script?

I am facing an issue where I need to run script with three features. Let's say we have 3 feature files with tag names as #smoke1, #smoke2 and #smoke3. And I want these to be executed in that sequence.
Issue is that smoke3 is executing first and rest of them afterwards.
This is my script:
#Cucumber.Options(
glue = { "com.abc", "cucumber.runtime.java.spring.hooks" },
features = "classpath:",
format = { "json", "json:target/cucumber.json" },
tags = "#smoke1, #smoke2, #smoke3"
)
public class ex_Test extends AbstractTest { }
Warning: This only works in older versions of Cucumber.
Cucumber feature files are executed in alphabetical order by path and filename. The execution order is not based on tags.
However, if you specifically specify features, they should be run in the order declared.
For example:
#Cucumber.Options(features={"first_smoke.feature", "another_smoke.feature"})
Should run first_smoke and then another_smoke (compared to the default which is to run in the other order.
Ok we got it , We can have multiple tags for a single scenario like this #tag1 #tag2 #tag3.
You can not define the order in way below.
#Cucumber.Options(features={"first_smoke.feature", "another_smoke.feature"})
Cucumber determines the only alphabetical order and even only first letter of the word.
You can have how many tags you want in feature file, if you want to trigger feature file more times, it's not working like you will add tag more time or more tags from feature like:
tags = {"#Reports,#Reports"}
And tests are triggered in alphabetical order, it's checking tags not feature file name.

Resources