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.
Related
In my project, the CMakeLists includes other cmake files from a library and those dependencies need some cache variables to be configured by user values.
It is all working well if I define those values from the command line with the cmake command:
-DTHIRDPARTY_FRAMEWORK_ROOT="$thirdpartyFrameworkPath"
But can I define (= hardcode) such values in my own CMakeLists file?
To avoid my own users to do it when they configure my project (some values of the 3d party configuration are constant in my project), and make my own cmake interface simpler.
I tried to simply set the variable with a value, but it is both defined and used in the included cmake so it gets overwritten with their default value just before being used.
Using set(... FORCE) seems to work but it does not look clean to me, and might lead to confusing errors if they rename or change the type of the variables on their side. It also forces me to add a type and a doc string because of the set(... CACHE ...) syntax.
Is there a better way to do this?
Setting CACHE INTERNAL variable is a proper way for hardcode a parameter of the inner project in the outer one:
set(THIRDPARTY_FRAMEWORK_ROOT CACHE INTERNAL "Hardcoded root for 'thirdparty'" <value>)
INTERNAL type makes sure that this setting will overwrite the option (FORCE doesn't need) and makes sure that the option won't be shown for a "normal" user.
Since the parameter is not intended to be changed by a user, its real type is meaningless, so there is no needs for it to coincide with the one set in the inner project.
As for description, you could set it to be empty (the parameter is not shown to the normal user, remember?). Alternatively, in the description you could explain why do you set the variable in the outer project. So an "advanced" user will see your description.
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.
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.
I have a simple sql query in my Execute sql task in ssis package,
SELECT MAX(binindex)
FROM dbo.myTable
I need to store this maximum index into a variable and then pass it to Script Task and display it,
I already declared a package variable, the package compiles, however it shows -1 every time, I don't know what I'm doing wrong, any help will be appreciated!
public void Main(){
//TODO: Add your code here
Dts.TaskResult = (int)ScriptResults.Success;
MessageBox.Show(Dts.Variables["User::BININDEX"].Value.ToString());
}
The good news, is that you are doing everything correctly as far as I can see. I recreated your package and I get the expected value from my query.
I can also induce your situation - the correct value is returned from my query but my package produces an "incorrect result."
The problem, I hope, is that you have two BININDEX variables defined at different scopes. My original assumption was the Package scoped one contained a value of -1 and you had a variable scoped to the "Execute SQL Task" with the same name. The default behaviour is a variable is created scoped to the object that currently has focus. This changes in the 2012 release of SQL Server by the way.
As your picture shows a design-time value of 123 for the package scoped variable, the possibility also exists that you have a variable defined on the Script Task with the same name of BININDEX. The local variable would override the globally scoped variable
Click on your Script Task and hopefully you'll see a BININDEX defined there like the above. Otherwise, I think the problem is somewhere in your package, you have conflicting BININDEX variables. You can try slogging through the Package Explorer looking for an instance where you have two variables with the same name listed.
I need to leave but if none of that is the case, add a PostExecute breakpoint on the Execute SQL Task and look at your Locals window (not Variables as that only reflects Design-time values). Expand Variables and you should be able to see the value of BININDEX. Is it correct there?
I have a simple tfs-2010 build definition using the default process template. In it I defined the Build Number Format using $(BuildID) to define part of the computed field. This works and I can see what BuildID's value is.
Now I try to pass the BuildID property to MSBuild as an argument:
/p:SomeProperty=$(BuildID)
However when I look at the build log I see SomeProperty literally equals $(BuildID) rather then the value of BuildID.
What am I missing?
Update for clarity: What I'm asking is how to reference as a Build Process Parameter in the Build Definition. For example Build Number Format has a default expression of $(BuildDefinitionName)_$(Date:yyyyMMdd)$(Rev:.r)
You need to use a VB.NET expression. For example:
String.Format("/p:SomeProperty={0}", BuildDetail.BuildNumber)
The Build Number tokens, e.g. $(BuildDefinitionName), are specific to the Build Number Format process parameter. They aren't tokens that you can use anywhere else in the build process. Most are available in the BuildDetail object or from the environment. The Build Id is a bit of a special case, however. It comes from the identity column of the builds table and isn't directly exposed in our public API. You could extract it from the BuildNumber, like this:
BuildDetail.BuildNumber.Substring(BuildDetail.BuildNumber.LastIndexOf('/') + 1)
Note that you would need to do this in the XAML directly rather than putting a VB expression into the build process parameter editor GUI. That's because those values just get passed through as literal strings.