I am trying to pass some data to a remote powershell script within the TFS2015 build step.
My step is calling a remote Powershell script on a target machine. I am passing data as script parameters. The following script parameters are what I have defined.
This parameter list works:
-buildVersion $(Build.BuildNumber) -queuedBy $env:USERNAME (but the name is the account running the script)
,but I really want the Build.QueuedBy username to get passed so I have tried:
-queuedBy $(Build.QueuedBy)
….or
-queuedBy $env:BUILD_QUEUEDBY
This does not work. Am I specifying something incorrectly or is there a better way?
I would also like to get some of the Build definition Variables to the remote script as well.
I have displayed the variables available to me with a Command line step running: cmd /k set
In order to get the correct value you need something like this:
$a = Get-Item -Path "Env:BUILD_QUEUEDBY"
$a = $a.Value
Related
I have pipeline on GitLab and there the variable - ENV_VAR. This variable is changing based on branch for pipeline.
In the same yml file I have script with newman, where I want to pass this variable like this -> newman run ... -e test/apis/$ENV_VAR_environment.json
But the issue I have right now is that it seems the variable is not being passed as i want. The pipeline shows error - cannot read the test/apis/here_should_be_the_variable_name.json
Is there a way to pass this variable into the file source?
It looks like you only need to enclose the variable name in braces:
-e test/apis/${ENV_VAR}_environment.json
because test/apis/$ENV_VAR_environment.json means that it looks for $ENV_VAR_environment variable which obviously does not exist.
When I define a custom variable in the new TFS 2015 team build as follows:
Name: SomeOutput
Value: $(System.DefaultWorkingDirectory)\Some
...it doesn't seems to expand $(System.DefaultWorkingDirectory).
Is there a way around this?
EDIT:
At least it seems it's not expanded everywhere.
For example, in MSBuild-Arguments, /p:OUTPUT="$(SomeOutput)" is expanded to /p:OUTPUT="C:\TfsData\BuildAgents\_work\3\s\Some" but when i add a cmd line build task with tool set to cmd and parameter set to /k set, it prints
SOMEOUTPUT=$(System.DefaultWorkingDirectory)\Some
EDIT 2:
Here are my variables
This is my workflow step
And this is what the build prints
You can use the VSTS Variable Tasks extension from the Visual Studio Marketplace.
When you define a variable in the Variables screen and use other variables as value, they won't be expanded (as you may have expected). Instead the literal text is passed to the tasks in the workflow. Without this little task the following configuration won't work:
Variable Value
Build.DropLocation \\share\drops\$(Build.DefinitionName)\$(Build.BuildNumber)
By adding the Expand variable(s) task to the top of your workflow, it will take care of the expansion, so any task below it will receive the value you're after.
https://github.com/jessehouwing/vsts-variable-tasks/wiki/Expand-Variable
PS: The new agent (version 2.x) auto-expands variables now.
It can be achieved.
You may need use % % instead of $ to call the variables in cmd to print the result. It is also necessary to add call in the front of the command. Here is a simple example:
Note: System.DefaultWorkingDirectory is not available in cmd (not sure why); you need use System_DefaultWorkingDirectory instead. Details can be viewed in the logs.
I had the same problem - wanted to piece together a path made up of several built-in variables and pass it to a PS script.
Workaround:
I ended up combining the variables in the actual script through the corresponding generated environment variables (for example $env:BUILD_SOURCESDIRECTORY).
Not what I had in mind originally, but it works at least. Drawback - if I need to change the path, I always have to change the PS script instead of a build variable.
I am running the following SQL query through a powershell script and need to run the script multiple times against different files. So what I am trying to figure out is how to specify a file path as a variable when I run the script?
update [$Db_name].[dbo].[$BatchTable]
set [$Db_name].[dbo].[$BatchTable].Wave = 'Wave1.1'
from [$Db_name].[dbo].[$BatchTable]
inner join OPENROWSET(BULK 'FilePath\file.csv',
FORMATFILE= 'E:\import.xml') AS a
on ([$Db_name].[dbo].[$BatchTable].Name= a.Name) and
([$Db_name].[dbo].[$BatchTable].Domain = a.Domain)
The 'FilePath\file.csv' is the file path I need to define as a variable so that my code would instead look like this:
inner join OPENROWSET(BULK '$INPUTFILEPATH',
FORMATFILE= 'E:\import.xml') AS a
Any help or potentially better methods to accomplish this would help very much.
From the command like I want to be able to run the script like this:
CMD: updatescript.ps1 $INPUTFILEPATH = C:\Documents\myfile.csv
Again, I'm not sure this is the best way to go about this?
You're nearly there.
You will need to add a parameter block at the very start of your script e.g.
Param(
[Parameter(Mandatory=$true)]
[ValidateScript({Test-Path $_ -PathType 'leaf'})]
[string] $InputFilePath
)
This creates a mandatory (not optional) string parameter, called InputFilePath, and the ValidateScript is code used to validate the parameter, in this case checking the file exists using the Test-Path cmdlet and pathtype of leaf (if checking existence of a directory use 'container').
When running your script use the syntax below:
updatescript.ps1 -INPUTFILEPATH "C:\Documents\myfile.csv"
and in the script use the variable as the path exactly as in your question:
inner join OPENROWSET(BULK '$INPUTFILEPATH',
FORMATFILE= 'E:\import.xml') AS a
NOTE: in powershell when using parameters when running a script you only need to use the least amount of characters that uniquely identify that parameter from all the others in your param block - in this case -I works just as well as -InputFilePath.
You can pass command line parameters to the powershell script using param.
Example:
param(
[string]$INPUTFILEPATH
)
And then call the script as follows:
updatescript.ps1 -INPUTFILEPATH C:\Documents\myfile.csv
More details about cmd line parameters can be found here
The Visual Studio (2010) gui provides options for specifying second command variable file for target. I however cant find this option for the command line implementation - vsdbcmd.exe.
Running vsdbcmd deploy for dbschema to dbschema with only source model command variables given results that objects that implement the variables are treated as having changes. Resulting in incorrect(improper) update script.
The command i use currently:
vsdbcmd.exe /a:deploy /dd:- /dsp:sql /model:Source.dbschema /targetmodelfile:Target.dbschema /p:SqlCommandVariablesFile=Database.sqlcmdvars /manifest:Database.deploymanifest /DeploymentScriptFile:UpdateScript.sql /p:TargetDatabase="DatabaseName"
What im looking for is the /p:TargetSqlCommandVariablesFile, if such thing exists ...
The result script is the same as running so GUI compare without specifying the sqlcmd vars for target
I found what looks like full documentation for VSDBCMD.EXE at this link.
I think you may be looking for something like:
/p:SqlCommandVariablesFile=Filepath
In the end i found no info on the possibility to do what I required - checked vsdbcmd libs with IL spy for hidden parameters - didn't find any.
Reached my goal by parsing the dbschema files for both target and current and parsing the cmd variable values directly into them - then doing the compare on modified dbschemas. This approach no longer allows to change sql cmd vars in resulting script (as the values are already baked into code), however this was deemed as acceptable loss.
Not the most beautiful solution but so far i have had no issues with it.
I have a script that runs Invoke-SQLCmd against a SQLServer called Server1. Data that is collected from that is passed along to another script that is fired off against Server2 and the results are inserted back into a table on Server 1. On every Invoke-SQLCmd I have used the -user -password with an account that has sa permissions on both systems.
When i run the script from the command shell or from the Poershell ISE my data is inserted into the table and every thing works fine; When i run it from within SQL nothing happens. I get no outputs ("null" is returned) when i use xp_cmdshell as below.
xp_cmdshell 'powershell.exe -file c:\script.ps1 -ExecutionPolicy Unrestricted'
I have put it into a SQLjob and used a proxy account that links to my domain account that has admin rights on both boxes yet still no results recorded in the job history and no data in my table on Server1.
What am i doing wrong? surely this should work if it works from the ISE?
I haven't had any problem doing this and even created a couple of blog posts:
http://sev17.com/2009/04/05/executing-powershell-in-sql-server (mirror)
http://sev17.com/2010/11/29/executing-powershell-in-sql-server-redux (mirror)
The one thing that I'm doing differently is using the -command parameter with a file name instead of -file, but that shouldn't make a difference. I'm also enclosing the file name in double quotes but this shouldn't make a difference either if the script file has not spaces in the file path.
Outside of that I would need to see what your script is doing. For instance is it connecting to other machines? Can you run a simple command in powershell like 'powershell -command get-command'?
It would seem that i was not loading the snapins correctly. Although my SQLsnapins were loaded for the first session it wasnt passing it to the second PS script that was running invoke-SQLcmd. My second script did add the cmdlet snapin but that may not have been enough.
It should have worked but for whatever reason, adding the script block from here fixed it. :/
http://msdn.microsoft.com/en-us/library/cc281962.aspx
Thanks to those that responded.
What am i doing wrong?
I think there is an error in the example provided. I would have expected:
xp_cmdshell 'powershell.exe -ExecutionPolicy Unrestricted -file c:\script.ps1'
Because: "File must be the last parameter in the command, because all characters typed after the File parameter name are interpreted as the script file path followed by the script parameters and their values."
Source: PowerShell.exe Command-Line Help