TFS check if file exists in build directory - tfs

Is there a way to check if a specific .xml file exists in build directory when TFS build runs?
I'm trying to get a Boolean result true/false based on the result found/not found
I tried creating a variable that would store this result (I'm guessing that is the way to do it). However I get an error when trying to use it.

You can try writing a script to check if the specific file exist, then check in the script and run as Pre-build script in your build process:
e.g.:
$Source = $Env:TF_BUILD_BUILDDIRECTORY
$filename = "*.xml"
if (!(Test-Path "$Source\$filename"))
{
Write-Warning "$filename absent from build directory"
# Write-Error "$filename absent from build directory"
#exit 1
}
Reference Using Environment Variables in Visual Studio 2013 and TFS 2013

The expression editor uses standard VB.NET, so you can call into System.IO.File.Exists(path) to detect whether a file already exists.

Found the solution. I added a new variable "dcMatchedFile" - which is a IEnumerable type. Use this dcMatchedFile as "Result" option for FindMatchingFiles" item (see images below)
Then you can simply use "If" statement to check Any().

Related

new File(...).eachFileRecurse() fails on existing files and folders

Currently I'm refactoring our Jenkins build pipeline. In the stage of gathering our unittests I'm trying to enumerate all '**/.test.dll' files, or '.test.dll' at least. Read somewhere that this could be achieved using eachFileRecurse from the File-object.
But... all calls failed reporting FileNotFoundException.
Using the Scriptconsole on the specific slave I tried the same code and it works as expected. Adding some addition debug lines in our jenkins-file shows that the pipeline always returns false.
def TestFile(path)
{
def file = new File(path)
echo "File '${file}' exists: ${file.exists()}"
}
TestFile(WORKSPACE)
TestFile(pwd())
TestFile(BUILDPATH)
All result a 'exists: false', even though all these paths are already used during the build.
(How) can I use the File-object in a pipeline or how can I get the files I need?
Use fileExists together otherwise it will not work.
For example in your case it will be like this
echo "fileExists '${file}' exists: '${file}'"

Is possible to change the value of a variable during execution of a release in TFS 2017

In TFS 2017, when a release definition is created a set of custom variables can be created too.
In the scope of an Agent, Is possible to change the value of one variable?
I tried with an inline powershell script:
$env:MyVariable = "changed value"
also try with :
[Environment]::SetEnvironmentVariable("MyVariable ", "changed value.", "User")
without success.
You could use the Logging command to change the custom variable's value.
In your PowerShell script file(script1.ps1), write:
$NewVersion = "NewValue"
Write-Host ("##vso[task.setvariable variable=customVariable;]$NewVersion")
Then add a Powershell script to run this file.
And you could add another Powershell script file(script2.ps1) to output the custom value. Run this file after script1 to check if the value has been changed successfully.
Here is a similar question: How to change a tfs build variable in script
Did you try Write-Host?
Write-host $env:OutputVar
Can't check myself now, but you can take a look here for detail.

Add BuildNumber in GitTemplate.12.xaml

In the related TfvcTemplate.12.xaml the solution is to add the build number like so:
<mtbwa:MSBuild CommandLineArguments="[String.Format("/p:SkipInvalidConfigurations=true
/p:BuildNumber={1} {0}", MSBuildArguments, BuildDetail.BuildNumber)]"
In the Git template the arguments have slightly changed, but doing the same results in the following error
Compiler error(s) encountered processing expression
"String.Format("/p:SkipInvalidConfigurations=true /p:BuildNumber={1} {0}",
AdvancedBuildSettings.GetValue(Of String)("MSBuildArguments", String.Empty),
BuildDetail.BuildNumber)".
'Microsoft.TeamFoundation.Build.Client.BuildDetail' is not accessible in
this context because it is 'Friend'.
What is the correct way to expose the BuildNumber in this template?
There's two steps I had to go through to make this work.
https://social.msdn.microsoft.com/Forums/vstudio/en-US/49f11ed9-9fa8-4c20-952a-d39ee7e71051/can-no-longer-user-builddetaildroplocation-for-copydirectory-with-tfs-2013-using-build-process?forum=tfsbuild
Within the same template you modified in step 1 click on the "Run MSBuild" activity, view properties and open "CommandLineArguments". I'm using OctoPack for Octopus Deploy so here's what my arguments look like:
String.Format("/p:SkipInvalidConfigurations=true /p:BuildNumber={1} {0}
/p:OctoPackPackageVersion={1}", AdvancedBuildSettings.GetValue(Of
String)("MSBuildArguments", String.Empty), BuildDetail.BuildNumber)
As you can see, BuildNumber is specified there so you can just remove the Octopus property I added. Finally within your msbuild file (.csproj for example) you'd use build number like so $(BuildNumber)

TFS checkin policy with ReSharper Cleanup Code

We are trying to have ReSharper's cleanup code run on TFS Checkin. Ideally, when you right click on the solution / project and select Source Control > Check in all the files in the "Included Changes" should run cleanup code. I've got the custom checkin policy to work to some extent, works fine if you select a single file to check in but when you select the solution or project, it tries to run cleanup code on the entire solution / project and not just the files selected in TFS Pending Changes "Include Changes".
I'm running VS 2013 with R# 8.2. My policy evaluate code:
public override PolicyFailure[] Evaluate()
{
if (PendingCheckin.Policies.EvaluationState == PolicyEvaluationState.Unevaluated)
{
DTE2 dte = PendingCheckin.GetService(typeof (DTE)) as DTE2;
foreach (EnvDTE.Document doc in dte.Documents)
{
doc.DTE.ExecuteCommand("ReSharper_SilentCleanupCode");
}
}
return new PolicyFailure[0];
}
I don't think this only applies to ReSharper, executing "Edit.FormatDocument" here would most likely run on all files as well.
Is there a way to run ExecuteCommand on only 1 file / document?
It seems like
PendingCheckin.GetService(typeof (DTE))
only gets files that are open in the Visual Studio editor not all the files that are in the "Include Changes" list. I can get a list of PendingChange through
PendingCheckin.PendingChanges.CheckedPendingChanges
But I don't know how to execute a command on PendingChange. Recommendations here would help
PS: I've read that the check in policy is meant to be used for checking documents only, however this workflow is what we need.

result from /proc/self/exe is unfriendly in a clearcase view

If I execute a binary in a clearcase view, and look at /proc/self/exe for that on Linux, I see something like the following:
$ cd /proc/19220
$ ls -l exe
lrwxrwxrwx 1 peeterj pdxdb2 0 2012-11-30 13:04 exe -> /home/peeterj/views/peeterj_clang-7.vws/.s/00024/8000028250b8f1d1llvm-config
The clang llvm-config program, not unreasonably, uses this output to try to figure out the absolute fully qualified path that it is located in (I assume in case argv[0] isn't fully qualified).
Is there a way to find the location within the view that this corresponds to. For example, in this case, the llvm-config exe is actually in:
/vbs/bldsupp/linuxamd64/clang/debug/bin
(I'm wondering if it's feasible to modify clang's GetExecutablePath() function to figure this out.)
No trivial solution here (for an old version of ClearCase though):
The technote "PK27447: WITHIN A CLEARCASE DYNAMIC VIEW, THE READLINK() CALL ON LINUX RETURNS THE WRONG PATH FOR THE EXECUTABLE'S /PROC/SELF/EXE VALUE" suggests:
Local fix
Use getcwd(), get_current_dir_name(), getwd() in applications slated for a VOB/View context
Create an interposer library to intercept the readlink() call, and modify to use any of the above calls to return the proper data
The cause:
/proc/self/exe returns the improper path while getcwd succeeds.
Unfortunately, for /proc/self/exe to return the proper value [from within a VOB/View context] would require a change within the Linux kernel to allow MVFS to "override" the present setting.
IBM LTC has been working on having the Linux community adopt this change so that we can then incorporate the new features within MVFS.
Related: Bug Sun 6189256.

Resources