I am trying to assign value to built-in release notes variable in "Run a Script" step.
$OctopusParameters["Octopus.Release.Notes"] = "Some release notes"
In the next step "Send an Email" I am using this variable in email body, but unfortunately it is empty.
<p>#{Octopus.Release.Notes}</p>
Is it possible to set Octopus Deploy system variable value from PowerShell and use it in the next step?
I am using Octopus Deploy 3.7.11.
EDIT:
I have also tried the cmdlet Set-OctopusVariable and it did not work.
Set-OctopusVariable -name "Octopus.Release.Notes" -value "Something"
I don't think it is possible to overwrite values of the built-in variables provided by Octopus Deploy. But you could define your own output variable and refer to that in the following steps. For example in your 'Run a script'-step use:
Set-OctopusVariable -name "MyReleaseNote" -value "Some text here"
Then the "Send an Email"-step can refer to this text by using the following (assuming the first step is called 'FirstStep'):
#{Octopus.Action[FirstStep].Output.MyReleaseNote}
The variable can also be used from a script in other steps, then use the syntax:
$relnote = $OctopusParameters["Octopus.Action[FirstStep].Output.MyReleaseNote"]
(If you want to save the generated releasenote perhaps you could save it as an 'artifact' in the project).
I tried this using Octoposh. Modifying an existing variable is covered in the Octoposh wiki at Modifying Variables - Edit a variable of a Project/Library variable set.
I wasn't able to get this to work because of timeouts on our network, but it looks like it should work - just not as straight-forward as I expected.
Related
I have created a GitLab pipeline and predefined variable (type file). That file contains a variable ${myVar} that should not has to be applied before some steps of the job.
I found that when I open that file using cat, the ${myVar} disappeared. Looks like it was applied but with an empty string since its content has not yet been generated.
Question: how to tell GitLab CI to ignore variables in the variable file
The issue is fixed. All you need to do is to add one more $ sign before the variable. Hence instead of ${myVar} you need to specify $${myVar} in this case GitLab CI will not apply the variable
As of Gitlab 13.7 you can disable variable expansion for the variable (enabled by default). See:
https://gitlab.nposervices.com/help/ci/variables/index#expand-cicd-variables
I am using Octopus for getting my environment ready with all prerequisites. In one of the octopus step I want some varaibles values to be set dynamically for which I have used the octopus output variables.
If I want to declare the output variable in form of an array, its value not getting read in other step where I want to read that.
Below are few code snippets which I have used (Note : both the steps are having inline powershell script code written):
/*Step A code : Set output variable of step code*/
$market= "RO" /*Dynamically identify market depends on machine name */
write-host $market
Set-OctopusVariable -name "TestResult_Domain_['+%market%+']" -value
"DomainNameOfMachine"
/*Another step code*/
$market= "RO" /*Dynamically identify market depends on machine name */
write-host $market
$filterDomain = "Octopus.Action[StepA].Output.TestResult_Domain_['$market']"
I have a TeamCity build that passes some arguments to an .exe and runs it daily. One argument is for a date parameter, currently set to a static date. It now needs to be dynamic, passing in the current date.
I tried setting the value to %env.BUILD_START_DATE% but this makes all my agents incompatible because of an implicit requirement for that env variable. I also tried setting the date in the DOS command line script, skipping TC params altogether, but it still ends up with that implicit requirement.
The top answer here: TeamCity Current Date variable in MMdd format
indicated need for a TC plugin, the second answer, however, did not require a plugin and is mostly complete. How I made it work on a variation of that second answer:
1.) Add a powershell build step to run the following:
echo "##teamcity[setParameter name='env.BUILD_START_DATE' value='$([DateTime]::Now)']"
2.) Give env.BUILD_START_DATE a default value in the Environment Variables section. Without the default value TC thinks having this value is an implicit requirement of a build agent, rendering all of them incompatible.
If you are unfamiliar with PowerShell, here is a Bash approach.
You can set a parameter with script and retrieve the value from the next build step.
echo "##teamcity[setParameter name='env.BUILD_START_DATE' value='$(date +%%Y-%%m-%%dT%%H:%%M:%%S%%z)']"
The doubled %% is because TeamCity considers % as its own parameter in build script.
The parameter will have ISO8601 format timestamp. For other formats, please see various Bash date format at here; https://www.tutorialkart.com/bash-shell-scripting/bash-date-format-options-examples/
You can set the variable in the config, which should be overridden during runtime. I don't see env.BUILD_START_DATE in my TC parameters, but I do see system.buildStartTime. I set it to a dummy value (I use "[Filled Automatically]"), and everything works fine. Build gets run and system.buildStartTime gets overridden at build time.
we have Octopus-2.0.
We stored the service credentials (they are per machine) in octopus user variable.
I need to create these login in SQL server as well.
For Example service login name "machine1_service1" stored as variable name. and password of that login is stored under column Variable Value in octopus.
so far i know that to any variable value from octopus we need to provide exact variable name. but in this case I actually need to get list of all these variables.
Is there a way to accomplish this?
Yes.
Octopus variables are accessible from a dictionary object that can be enumerated. If you follow a naming convention you could query the dictionary using powershell with something like the following. This would be called from within a custom step or somewhere where you can write your own powershell e.g. a PostDeploy.ps1 script in the .nuget file
Let's say the variables are defined like this
You can use this powershell to get to them and enumerate round them
# Get service accounts
$serviceAccounts = $OctopusParameters.keys | ? {$_ -like "service-*"}
write-host "Accounts found:" $serviceAccounts.count
foreach($account in $serviceAccounts)
{
write-host "Account: $account"
$password = $OctopusParameters[$account]
write-host "Password: $password"
}
Hope this helps.
Okay I've been having an issue with writing results to folders in JMeter.
I have set 2 variables, one for the name of the test and one for the submit date. I want the reports to be written to the folder named with these two variables.
Here's the variables:
TestRun = "Name of test"
DateRun = $__{time(dd-MMM-yyyy HH.mm.ss)}
The path of the folder to be written to looks like this:
C:\Tests\TestEnvironment\Results\\${TestRun}${DateRun}\file.csv
When I run it on the master machine, it's fine. It saves to the correct file and folder path, and ends up looking something like this:
C:\Tests\TestEnvironment\Results\Test Run 1 - 08-May-2014 08.55.47\file.csv
However, when I run it on remote machines, it saves it literally as below:
C:\Tests\TestEnvironment\Results\${TestRun}${DateRun}\file.csv
So I end up with a folder named "${TestRun}${DateRun}"
Am I missing something blindingly obvious, or is this an actual JMeter issue?
Thanks!
As per JMeter help:
-G, --globalproperty <argument>=<value>
Define Global properties (sent to servers)
e.g. -Gport=123
or -Gglobal.properties
You need to use -G key so your variables could be distributed across remote clients.
so something like:
jmeter -r -n GTestRun=SomeName -GDateRun=SomeTime -t /path/to/your/plan
should help.
Alternatively you can create a .properties file and pass it to remote JMeter Engines via the same "-G" option.
I expect that if you want to use JMeter __time() function you'll need to wrap it with __eval, elsewise it will be treated as a string. Alternatively you can use operating system commands to retrieve current date and time.
See Apache JMeter Properties Customization Guide for more information on dealing with JMeter Properties.