Is there some way to use logical "or" and "and" operators in variable substitution syntax like the following?
#{if Octopus.Action[Smoke Test] && Octopus.Action[Smoke Test].Output.FailedSmokeTestMessage}
<h3 style="color: red">Failed Smoke Tests</h3>
#{Octopus.Action[Smoke Test].Output.FailedSmokeTestMessage}
#{/if}
No. See the documentation on variable substitution syntax. Instead you could try nesting your if blocks.
#{if Octopus.Action[Smoke Test]}
#{Octopus.Action[Smoke Test].Output.FailedSmokeTestMessage}
<h3 style="color: red">Failed Smoke Tests</h3>
#{Octopus.Action[Smoke Test].Output.FailedSmokeTestMessage}
#{/if}
#{/if}
There is no test case for this in Octostache, the open-source templating engine, so there's no guarantee it works. It is pretty easy to set up a test project for Octostache using its Nuget package to test it out and play around with syntax.
Related
Please find the below script which I have used to fetch the running pods from openshift container
oc get pods -o template --template {{range.items}}{{if eq .status.phase "Running"}}{{.metadata.name}}{{.status.phase}}{{end}}{{end}}
I think you have multiple issues with your command, one being that you need to put a space between range .items and the main issue being that you did not put your template in quotes. This results in the template being read as {{range.items}}{{if, which will lead to the error above.
To fix this, put your template in quotes, but take care to escape all other quotes in your command as well:
oc get pods -o template --template "{{range .items}} {{if eq .status.phase \"Running\"}} {{.metadata.name}} {{.status.phase}} {{\"\\n\"}} {{end}} {{end}}"
You must use the uppercase later on go
You could not access field in lower case..
{{range .items}}
{{if .Status.Phase "Running"}}
{{.Metadata.Name}}
{{.Status.Phase}}
{{end}}
{{end}}
I'm trying to let maven-surefire-plugin only run all the tests fulfilling following conditions:
Match the pattern *Test.java, but NOT *SomeTest.java;
OR match the pattern *AnotherSomeTest.java.
Is there any way to achieve this?
I've already tried the include string:
**/*Test.java, !%regex[.*(?!Another)SomeTest.*]
however this does not work.
There are several solutions possible using a regular expression. The simplest one is having the configuration
<includes>
<include>*AnotherSomeTest.java</include>
<include>%regex[.*(?<!Some)Test\.class]</include>
</includes>
This will match tests where the class name ends either with AnotherSomeTest, or with Test but not preceded by Some (the negative lookbehind < just needs to be properly escaped with <). Note that the regular expression match is done over the .class file, while the traditional one is done over the .java file.
You could put this into a single regular expression, with
<include>%regex[.*(?<!(?<!Another)Some)Test\.class]</include>
which selects all tests ending with Test, not preceded by Some themselves not preceded by Another, although it's probably not clearer.
Another alternative is to use multiple formats into one, that works since version 2.19 of the plugin and JUnit 4 or TestNG. This is useful for the command line notably:
<include>%regex[.*(?<!Some)Test\.class], *AnotherSomeTest.java</include>
I am reading a page and trying to extract some data from it. I am interested in using bash and after going through few links, i came to know that 'Shell Parameter Expansion' might help however, i am finding difficulty using it in my script. I know that using sed might be easier but just for my knowledge i want to know how can i achieve this in bash.
shopt -s extglob
str='My work</u><br /><span style="color: rgb(34,34,34);"></span><span>abc-X7-27ABC | </span><span style="color: rgb(34,34,34);">build'
echo "${str//<.*>/|}"
I want my output to be like this: My work|abc-X7-27ABC |build
I thought of checking whether it accepts only word instead of pattern and it seems to be working with words.
For instance,
echo "${str//span style/|}" works but
echo "${str//span.*style/|}" doesn't
On the other hand, i saw in one of the link that it does accept pattern. I am confused why it's not working with the patern i am using above.
How to make sed do non-greedy match?
(User konsolebox's solution)
One mistake you're making is by mixing shell globbing and regex. In shell glob dot is taken literally as dot character not as 0 or more of any character.
If you try this code instead:
echo "${str//<*>/|}"
then it will print:
My work|build
This is not an answer, so much as a demonstration of why pattern-matching is not recommended for this kind of HTML editing. I attempted the following.
shopt -s extglob
set +H # Turn off history expansion, if necessary, to allow the !(...) pattern
echo ${str//+(<+(!(>))>)/|}
First: it didn't work, even for a simpler string like str='My work</u><br />bob<foo>build'. Second, for the string in the original question, it appeared to lock up the shell; I suspect such a complex pattern triggers exponential backtracking.
Here's how it's intended to work:
!(>) is any thing other than a single >
+(!(>)) is one or more non-> characters.
<+(!(>))> is one or more non-> characters enclosed in < and >
+(<+(!(>))>) is one or more groups of <...>-enclosed non->s.
My theory is that since !(>) can match a multi-character string as well as a single character, there is a ton of backtracking required.
Is it possible to do a string substitution/transformation in Puppet using a regular expression?
If $hostname is "web1", I want $hostname_without_number to be "web". The following isn't valid Puppet syntax, but I think I need something like this:
$hostname_without_number = $hostname.gsub(/\d+$/, '')
Yes, it is possible.
Check the puppet function reference: http://docs.puppetlabs.com/references/2.7.3/function.html
There's a regular expression substitution function built in. It probably calls the same underlying gsub function.
$hostname_without_number = regsubst($hostname, '\d+$', '')
Or if you prefer to actually call out to Ruby, you can use an inline ERB template:
$hostname_without_number = inline_template('<%= hostname.gsub(/\d+$/, "") %>')
In this page:
https://blog.kumina.nl/2010/03/puppet-tipstricks-testing-your-regsubst-replacings-2/comment-page-1/
it is quite well explained and there is a fantastic trick for testing your regular expressions with irb.
Whith this link and the answer of freiheit I could resolve my problem with substitution of '\' for '/'.
$programfiles_sinbackslash = regsubst($env_programfiles,'\','/','G')
I have just stumbled upon the bash syntax:
foo=42
bar=$[foo+1] # evaluates an arithmetic expression
When I Googled for this, I found http://tldp.org/LDP/Bash-Beginners-Guide/html/sect_03_04.html#sect_03_04_05:
3.4.6. Arithmetic expansion
Arithmetic expansion allows the evaluation of an arithmetic expression and the substitution of the result. The format for arithmetic expansion is:
$(( EXPRESSION ))
...
Wherever possible, Bash users should try to use the syntax with square brackets:
$[ EXPRESSION ]
However, this will only calculate the result of EXPRESSION, and do no tests...
In my bash man page I can only find the $(( EXPRESSION )) form such as:
foo=42
bar=$((foo+1)) # evaluates an arithmetic expression
So what tests are not performed with $[...] that do with $((...)), or is the $[...] just a legacy version of $((...))?
The manpage for bash v3.2.48 says:
[...] The format for arithmetic expansion is:
$((expression))
The old format $[expression] is deprecated and will be removed in upcoming versions
of bash.
So $[...] is old syntax that should not be used anymore.
#sth is entirely correct. And in case you are curious about why a more verbose syntax is now in favor, check out this old email from the mailing list.
http://lists.gnu.org/archive/html/bug-bash/2012-04/msg00033.html
“In early proposals, a form $[expression] was used. It was functionally
equivalent to the "$(())" of the current text, but objections were
lodged that the 1988 KornShell had already implemented "$(())" and
there was no compelling reason to invent yet another syntax.
Furthermore, the "$[]" syntax had a minor incompatibility involving
the patterns in case statements.”
I am not sure that I like the rationale “but someone has already done this more verbosely,” but there you have it—maybe the case-statement problem was more compelling than I am imagining from this obscure mention?