Using set variables step in pentaho, I have defined a variable and the scope is set to "valid in the Java virtual machine", but it is not replacing in one of the sql's used in the table input step.
Table input step is checked with option "replace variables in script". But the same variable when I placed in kettle.properties file, it is working. Pentaho job available in the repository and running from Linux box
Could anyone please share your thoughts?
You can-not set the parameter and use it in the same transformation, because it executes all the steps parallelly.
Logic-wise correct approach is first set the variable and get the variable in next transformation and further use or replace in respected steps.
As Working Hard.. says, you can not use a parameter in the same transformation, you have to use another transformation after setting the variables.
Related
I have defined in my bamboo plan a variable (BAMBOO_TEST_VAR) that I'd like to reuse in a particular script but I can't seem to figure out how to make it visible to that script.
If I just reference that variable from the script it merely prints the variable as empty.
27-Oct-2020 23:34:00 TEST JOB
27-Oct-2020 23:34:00 bamboo.shortJobName =
27-Oct-2020 23:34:00 BAMBOO_TEST_VAR=
And if I provide it as input to the Environment variables field it just renders with the value I give in that field taken as a literal, not to the plan variable I was hoping it would evaluate to.
27-Oct-2020 23:36:57 TEST JOB
27-Oct-2020 23:36:57 bamboo.shortJobName =
27-Oct-2020 23:36:57 BAMBOO_TEST_VAR=$BAMBOO_TEST_VAR
How can I reference the plan's environment variable directly from a script task without passing it down through arguments or something of the sort. What aspect or bamboo detail am I ignorant of that would have informed me that what I'm attempting is not possible or not supported because of reason XYZ?
So the trouble was I didn't scope the variable appropriately. What did it in the end was
${bamboo.BAMBOO_TEST_VAR}
Turns out if I slowed down and looked at the bamboo page more carefully I would have noted the help breadcrumbs they left around. Copying that help text here, emphasis mine:
Variables substitute values in your task configuration and inline scripts. If a variable name contains any reference to a password, like "password", "sshKey", "secret", or "passphrase", its value will be masked with "********".
For tasks configuration fields, use the syntax ${bamboo.myvariablename}.
At the Manual Judgement stage we were hoping we could enter a value, continue and pass that value onto Jenkins with "${#judgment("Manual Judgment")}". We can pass the predefined option but can't enter a new one. Is there a way of getting this to work or an alternative method?
One way to achieve this is by using pipeline parameters.
In configuration stage of the pipeline, add a parameter (say Name="jenkins") and configure the parameter's options (like default value, required or not)
Before the manual judgment step, create a Evaluate Variables stage. In the stage configuration, create a variable named "jenkins" with the value ${parameters.jenkins}
In manual judgment's options, add the variable ${jenkins}
Now, during the manual judgment stage, it would show an option with the value provided to the pipeline.
You could also join Spinnaker's slack here: https://join.spinnaker.io/
How is it possible to reference a variable within a variable in the new scripting system of VSTS?
e.g:
RemoteMachineFqdn: somemachinename.somedomain
RemoteMachineUncPath: \\$(RemoteMachineFqdn)\c$\
In the aforementioned example, assume there are tasks that both use CMD and Powershell scripts with the given variables. I tried using the the variables by referencing their values from the environment but it does not work for both scenarios since %variable% works only in CMD and $env:variable - only in Powershell.
What is the standard way to do it?
What you are looking for is Logging Commands. To invoke a logging command, simply emit the command via standard output. For example, from a PowerShell task:
##vso[task.setvariable variable=testvar;]testvalue
This example sets a variable in the variable service of taskcontext. The first task can set a variable, and following tasks are able to use the variable. The variable is exposed to the following tasks as an environment variable.
We have a VNext build definition, on the Variables tab we have added a few custom variables. In one of the variable values we refer to another variable, i.e.
FileDescription = $(Build.DefinitionName)
However it appears that when we reference it in a PowerShell script the FILEDESCRIPTION environment variable exists but the value is not expanded(it contains "$(Build.DefinitionName)" ) and is treated as a string literal.
The documentation appears to suggest that we should be able to refer to it and it will be subsituted at run-time -
https://msdn.microsoft.com/en-us/library/vs/alm/build/scripts/variables
Is there a way to get TFS to automatically expand the variable at runtime?
In vNext build, it seems not expanded the variable everywhere.
For example, in MSBuild-Arguments, /p:OUTPUT="$(FileDescription)" is expanded to /p:OUTPUT="(the name of build definition)" , but in powershell it will only prints "$(Build.DefinitionName)" directly.
Try to use below Workaround: Try to use the corresponding generated environment variables (for example $env:Build.DefinitionName).
$FileDescription = $env:Build.DefinitionName
Note: If you need to change the path, you have to change the PS script instead of a build variable.
Anyone know how I can change a SSIS variable at runtime?
I have a variable User:SkipStuff
I want to set this based on a condition during a for loop container
Use Expression Task instead. In the "Expressions" pane, put the variable to set on left, then equates it to the intended value.
#[User::VariableToSet] = some expressions...
You can add a Script task. Add your SSIS variable(s) to the ReadWriteVariables property in the Script Task Editor.
You can reference the variable(s) in your script using the following format: Dts.Variables["MyCaseSensitiveVariableName"].Value
Lots of ways really, but the one I use most frequently is to use an execute SQL task and set the result set to single row and then put the results set into the variable.