I would like to know if there is a way to run certain step in Octopus from one version onward.
I see this may be achieved by defining different channels and some "Version Rules", but I think there must be a way to do this by a "Run Condition" on the step.
I saw here that you can compare versions on Octopus.
I would like to define something like this in my "Run Condition":
#{if Octopus.Release.Number > 2.3.15}True{/if}
But I don't know exactly how to write this condition. Please let me know if you can help me.
This is necessary because sometimes we add new packages (+ step) to an existing deployment, but deployments for old releases are still being creating.
Thanks in advance.
Based on benPearce answer I solved my situation like this:
In a powershell step called "Check Version" I wrote:
$IsOver2315 = $OctopusParameters["Octopus.Release.Number"] -gt [version]"2.3.15"
Set-OctopusVariable -name "IsOver2315" -value (&{If($IsOver2315) {"True"} Else {"False"}})
And in the "Run Condition" I wrote:
#{Octopus.Action[Check version].Output.IsOver2315}
Thanks benPearce
The Octostache expressions don't allow logic like this, but you can put that calculation into a script step which outputs a boolean variable that Octostache can evaluat.e
Related
I know I can define a secret value like this in kotlin DSL on teamcity:
params {
password(
"env.MY_SECRET_VALUE",
"credentialsJSON:faf2d7c8-3565-452a-8cfe-a7a55a4f0f4c",
display = ParameterDisplay.HIDDEN
)
}
How do I achieve the same with build script interaction? I mean a command of the kind
##teamcity[setParameter name='env.MY_SECRET_VALUE' value='1234']
Is it possible at all? I was unable to find this use-case in this documentation, which is the most complete I've found until now on the topic.
The way I understand it, making this happen with build script interaction makes no sense, because I'd need to write a command like
echo "##teamcity[setParameter password='env.MY_SECRET_VALUE' value='1234']"
assuming such a command existed. That means TeamCity will display that line in the logs with the value not hidden, making it therefore pointless.
Sorry I'm a little new to Ansible and don't quite understand playbooks completely, and was wondering if someone would be able to help me identify and fix my issue. I want to run a command which checks if a service is enabled, and returns "true" in stdout, and this is what I have so far.
Side note (incase the command seems confusing): The first parameter is the location of a binary that I must use, followed by the parameters I must provide the binary to receive my result.
command:
/opt/tableau/tableau_server/packages/customer-bin.123/tsm configuration get -k service.jmx_enabled:
exit-status: 0
stdout:
- "True"
Unfortunately this test case seems to be failing and produces the result: "stdout: patterns not found: [true]" and I have no idea what I'm doing wrong. If someone could look this over for me that would be awesome!
EDIT: The default_test.yml playbook is run by molecule when testing roles.
take a look here
https://linuxhint.com/print-command-output-ansible/
perhaps you want debug to output the result
Having investigated the issue further, I was able to uncover that Ansible STDOUT comparisons – using the method highlighted in the original question – is a case-sensitive process, and does not account for differences in capitalisation and casing. Instead it expects an exact match when aiming to identify the "pattern" that was being used. In my case, the execution of the command returned "true" and not "True", and so by simply modifying the expected-pattern I was able to resolve the issue. If the execution of this step is not dependent on a testing suite or CI/CD pipeline such as Atlassian Bamboo (or others), I do suggest taking a look into Andylondon's answer, which recommends registering the output of STDOUT to a variable, which can then be used to debug any issues.
I want to add a choice parameter to a Jenkins job. The list is fixed, but I want the dropbox to display custom value, and not the actual ones (analogous to name of a web page and not its URL).
In the certain case this is the path of the pom.xml file, however, I want to display the module name instead of the full path. An example:
Actual value | What I want to be displayed
-------------------------------------|----------------------------
full/path/to/my/modules/pom.xml | All modules
full/path/to/my/modules/util/pom.xml | Utilities
full/path/to/my/modules/data/pom.xml | Data handling
Thanks for the help in advance!
You can do this with the Extended Choice Parameter plugin.
To set it the way you want, under "This build is parameterized", choose Extended Choice Parameter, and set it up like this:
Note it may look a little different depending on what version of Jenkins you have but it shouldn't be too different (this screenshot was on 2.0-beta-2).
With the Active Choices plugin, you can set this up with a groovy map:
Set a "Active Choices Parameter" with the following groovy script:
return['full/path/to/my/modules/pom.xml' : 'All modules',
'full/path/to/my/modules/util/pom.xml' : 'Utilities',
'full/path/to/my/modules/data/pom.xml' : 'Data handling']
The "value" of the map will be displayed in the build parameters choices:
And "key" of the map will be set in the variable:
> echo "$URL"
full/path/to/my/modules/pom.xml
I found it painful that there were no easy solution to this problem for so many years, like writing a display|value line with the choice plugin, so I finally wrote my own plugin: https://github.com/Avalancs/ChoiceWithDisplay
You can get the .hpi file from the release tab, and if you don't know how to install .hpi files check this SO post: https://stackoverflow.com/a/19588907/7216760
I have two cucumber feature ( DeleteAccountingYear.feature and AddAccountingYear.feature).
How can i do to make that the second feature(AddAccountingYear.feature) run before the first one (AddAccountingYear.feature).
I concur with #alannichols about tests being independent of each other. Thats a fundamental aspect of automation suite. Otherwise we will end up with a unmaintainable, flaky test suite.
To run a certain feature file before running another feature appears to me like a test design issue.
Cucumber provides few options to solve issues like this:
a) Is DeleteAccountingYear.feature really a feature of its own? If not you can use the cucumber Background: option. The steps provided in the background will be run for each scenario in that feature file. So your AddAccountingYear.feature will look like this:
Feature: AddingAccountingYear
Background:
Given I have deleted accounting year
Scenario Outline: add new accounting year
Then I add new account year
b) If DeleteAccountingYear.feature is indeed a feature of its own and needs to be in its own feature file, then you can use setup and teardown functions. In cucumber this can be achieved using hooks. You can tag AddDeleteAccountingYear.feature with a certain tag say #doAfterDeleteAccountYear. Now from the Before hooks you can do the required setup for this specific tag. The before hooks(for ruby) will look like:
Before('#doAfterDeleteAccountYear') do
#Call the function to delete the account year
end
If the delete account year is written as a function, then the only thing required is to call this method in the before hook. This way the code will be DRY compliant as well.
If these options doesn't work for you, one another way of forcing the order of execution is by using a batch/shell script. You can add individual cucumber commands for each feature in the order you would like to execute and then just execute the script. The downside of it is different reports will be generated for each feature file. But this is something that I wouldn't recommend for the reasons mentioned above.
From Justin Ko's website - https://jkotests.wordpress.com/2013/08/22/specify-execution-order-of-cucumber-features/ the run order is determined in the following way:
Alphabetically by feature file directory
Alphabetically by feature file name
Order of scenarios within the feature file
So to run one feature before the other you could change the name of the feature file or put it in a separate feature folder with a name that alphabetically first.
However, it is good practice to make all of your tests independent of one another. One of the easiest way to do this is to use mocks to create your data (i.e. the date you want to delete), but that isn't always an option. Another way would be to create the data you want to delete in the set up of the delete tests. The downside to doing this is that it's a duplication of effort, but it won't matter what order the tests run in. This may not be an issue now, but with a larger test suite and/or multiple coders using the test repo it may be difficult to maintain the test ordering based solely on alphabetical sorting.
Another option would be to combine the add and delete tests. This goes against the general rule that one test should test one thing but is often a pragmatic approach if your tests take a long time to run and adding the add data step to the set up for delete would add a lot of time to your test suite.
Edit: After reading that link to Justin Ko's site you can specify the features that are run when you run cucumber, and it will run them in the order that you give. For any that you don't care about the order for you can just put the whole feature folder at the end and cucumber will run through them, skipping any that have already been run. Copy paste example from the link above -
cucumber features\folder2\another.feature features\folder1\some.feature features
When i run cucumber it displays the
possible steps that i should define, an example from the RSpec book:
1 scenario (1 undefined)
4 steps (4 undefined)
0m0.001s
You can implement step definitions for undefined steps with these snippets:
Given /^I am not yet playing$/ do
pending
end
When /^I start a new game$/ do
pending
end
Then /^the game should say “Welcome to CodeBreaker”$/ do
pending
end
Then /^the game should say “Enter guess:”$/ do
pending
end
Is there a way that it will automaticly create the step definitions file, so i don't have to
rewrite or copy paste by hand but i can just to customize them to be more generic?
Cucumber doesn't offer this feature. Probably because you would have to tell it where to put the step definitions file, and what to name it.
Like Kevin said, Cucumber would have to know the name of the file to put it in, and there are no good defaults to go with, other than using the same file name as the feature file. And that is something I consider an antipattern: http://wiki.github.com/aslakhellesoy/cucumber/feature-coupled-steps-antipattern
Intellij Idea or RubyIDE does exactly what you are asking for:
Detects missing step definitions
Creates missing step definitions in a new file (you choose the name of the file) or in one of the existing step definition files
Highlights matched step parameters
see http://i48.tinypic.com/10r63o4.gif for a step by step picture
Enjoy
There is a possibility this kind of feature could be useful, but as Kevin says, it doesn't exist at present. But it could also get quite messy, quite quickly.
Maybe you already do this, but there's nothing stopping you cut and pasting the output direct into your text editor, or even piping the output direct to your text editor if you're so inclined. Then at least you're getting pretty much most of the way there, bar creating the file and naming.
try this https://github.com/unxusr/kiwi it auto generate your feature file and make the step definitions file for you and you just fill in the steps with code.
In later version will write the code of the steps and run the test all of that automagically
You can use a work around way to generate steps file
all you have to do is to run the Cucumber on a feature doesn't have defined steps by identify a specific feature as the following command:
1) using path
bundle exec cucumber {PATH}
note path would start with features/....
for example
features/users/login.feature
1) using tags
bundle exec cucumber --tags=#{TAG}
note tag should be above your scenario in the steps file
for example
#TAG
Scenario:
And you will have the suggested steps in the console with pending status