In my TFS release i added a script to create a label when a certain environment succeeds.
This label is apply on a given server item and for a specific Changeset.
The TF.exe command looks like this:
tf.exe label Main-Approved $/MyProject/Main /recursive /version:C124730 /comment:"Approved by Main Release" /collection:http://tfsserver:port/tfs/MyCollection
However when run from the release i get the following error message return by TF.exe:
Error: There is no working folder mapping for D:\Agent-Default_work\r144\a\by.
Running this exact command localy works fine and creates the label.
I don't understand why i would need to create a workspace and some folder mapping in order to apply a label on a Server item (using $/...) for a specific changeset?
Any help would be appreciated.
Thanks!
So i was using a Python script to run the command.
I tried changing it to a powershell script and it works.
My guess is that in python the strings were passed incorrectly someone. I feel like the workspace 'by' was in fact my command wrongly parsed by the intepreter and considered an argument in tf.exe.
Related
I currently use TFS build for my Azure cloud service project.
as a output of that .cspkg and .cscfg file is created after the successful build.
is there any way to add the $(Build.BuildNumber) to my .cspkg file
say for eg: currently my output file looks like
SchoolWebPortalAzure.cspkg
is it possible to rename like SchoolWebPortal_1.0.0.1.cspkg in the tfs build definition.
thanks,
kind regards,
Snegha
You could use the Run Command Line task or do it in a PowerShell script in build.
1). Add the Inline Powershell task from the marketplace before the copy task in build definition.
2).Enter the following Powershell in the text area
Param (
[string]$pathToFileToRename
)
Rename-Item $pathToFileToRename Helloworld_$(Build.BuildNumber).exe
3). Enter any required arguments in the arguments text box (you could
use environment variables) e.g. -pathToFileToRename $(Build.SourcesDirectory)\somepath\CurrentName.exe
Then you will get the renamed file in the drop folder.
In TFS2013 I'm having the following dilemma, a build has always been dropped to a custom folder defined in the Build Definition. Suddenly, it is now needed to have it available online, so the "Copy build output to server" is the logic option.
However, I can't lose the "normal config", so I was wondering if it was a way to execute both Staging Locations. Tried with the .proj configuration file but I can't see a way to do it.
Any suggestions?
Thanks!
You can add a CopyDirectory activity in XAML build process template, or you can program a script to copy the outputs to a custom location in pre-build/post-build.
http://geekswithblogs.net/jakob/archive/2010/09/01/tfs-team-build-2010-how-to-place-the-build-output.aspx
https://msdn.microsoft.com/en-us/library/dn376353.aspx
What I'd like to do is to be able to add a tag to commits which Jenkins is building from. Right now I tag commits with the Jenkins build number but I want to also add in the app version as listed in the Info.plist CFBundleVersion in front of that.
What I want to know is, how I can grab that value using Jenkins or otherwise and be able to use that as a parameter/variable within Jenkins?
I've seen references to using plistbuddy to set this value so I would assume there's a way to use that to get the same value. Though how and how to get that to where I can use it in Jenkins I don't know.
For further clarification I am using Git Publisher in Jenkins to create a tag and push it with this format
jenkinsbuild-$BUILD_NUMBER
This results in a tag on the commit in git like this - jenkinsbuild-303
What I want, assuming my app is currently at version 3.5 is a tag that reads - jenkinsbuild-3.5-303
I managed to piece together a solution from the answer which #agy linked to. Here's what I did:
In the Build section for the Jenkins configuration, I added the following two lines to an 'Execute Shell' step after the Xcode step:
APP_VERSION=$(/usr/libexec/PlistBuddy -c "Print :CFBundleShortVersionString" "path to your plist")
echo APP_VERSION=$APP_VERSION > appversion.properties;
After that, I added an 'Inject Environment Variables' step (I think this is part of the EnvInject plugin), to which I added "appversion.properties" to the Properties File Path field.
After this is done, APP_VERSION is now available as an environment variable in subsequent shell command steps.
I'm trying to run a Powershell script during my build process, but I can't figure out how to access the ps1 file which is checked into source control (TFS 2010). There is a similar SO question that exists, but I'm actually not sure if it's correct:
TFS 2010: run powershell script stored in source control
My TFS source control is setup as such:
=Project
==BuildScripts
===MyScript.ps1
==Code
===Dir1
====MySolution.sln
I thought passing something like SourcesDirectory + "\..\..\MyScript.ps1" (to tell Powershell where the script is) would work, but I think I'm off somewhere.
Can someone help me figure out how to reference the ps1 file, and run it?
You will need to have a Workspace setup in your Build Definition that includes the directory with the Powershell script.
So your mapping might be like:
*Server* *Workspace*
$/Project/Code/Dir - $(SourcesDir)
You will need to add:
*Server* *Workspace*
$/Project/Code/Dir - $(SourcesDir)
$/Project/BuildScripts - $(SourcesDir)/BuildScripts
Your InvokeProcess can then pass Path.Combine(SourceDirectory, "BuildScripts", "MyScript.ps1") to the Powershell command line.
N.B. You could also set the $/Project/Code/Dir workspace to $(SourcesDir)/Code.
I have set my workspace directory to C:\jenkins_builds\workspace and I want to build ProjA and ProjB, each having a local workfolder (same as project name).
When fetching the source code from my repository, the first two things the TFS plugin does are:
tf workspace -new %workspace-name-A%;%user-name% -server:%my-server%
tf workfold -map $%branch% ProjA -workspace:%workspace-name-A% -server:%my-server%
Which goes fine when building ProjA. The problem is, the first command maps the root directory from the repository directly to my C:\jenkins_builds\workspace directory. The second command does what I actually want, i.e. mapping %branch% to the ProjA subfolder. Later on, when building ProjB, the first command fails (and consequently the build) with the following error message:
The path C:\jenkins_builds\workspace is already mapped in workspace %workspace-name-A%;%user-name%.
OK, it seems like a bad idea to map the root directory to the work directory. But why does this automatically happen when the TFS plugin runs the workspace new line? Currently I have to clean things up between building ProjA and ProjB by running the -unmap command.
My team is using Team Foundation 3.0.
We have the same situation and there are 2 ways to solve this:
use different workspace-root-directories for the two builds
This results in the need for two checkouts => double the space and slower, but better isolation between the two builds
"hardcode" the workspace name to the same for both builds
By default jenkins creates a workspace containing the build name, which can be changed in the "advanced" section of the TFS config, and then you can use the same workspace-/workfolder-mapping for several builds - in our case we called them ProjectName_${NODE_NAME} so it even works on several nodes