I’m setting up an automated build in VSTS that will FTP the published files to my server.
I have this working but the way I’ve achieved it, I feel is hacky and non-sustainable.
the process as you can see from the screenshots will publish the artefact which consists of a readme, cmd file and a zip containing all my publish files and then I extract the ZIP with the very explicit location below.
$(Build.ArtifactStagingDirectory)\temp\Content\d_C\a\1\s\IntermittentBug\IntermittentBug\obj\Release_EukHosts\Package\PackageTmp
I’m using a hosted build server in VSTS but as the path contains
d_C\a\1\s\
I assume this will change in time. What I need is a variable to cater for this path so it will always succeed.
How can I update this to make it more efficient and sustainable?
First, as jessehouwing said that the variable is called Build.SourcesDirectory.
Regarding the path structure, the simple way is specifying /p:PackageTempRootDir="" msbuild argument in Visual Studio Build task to remove the source path structure, then the path will be like Content\D_C\PackageTmp.
On the other hand, you also can publish the web app through File System mode.
This variable is caught in a predefined variable called Build.SourcesDirectory. see the complete list of predefined variables here.
In your batch or powershell scripts this variable is available as a environment variable called %BUILD_SOURCESDIRECTORY% / $env:BUILD_SOURCESDIRECTORY.
Related
I'm trying to write a powershell script to allow a user to specify a tfs build id (or alternately a changeset id) and download the build output to the current directory. I have the build configured to copy the output to the server, which means only the most recent build output will be accessible in that directory. However from Visual Studio, or from the TFS Web Access, I can download the drop as a .zip file.
How can I access this .zip file programmatically (either in powershell, or even if I could figure out VB code to do this I can convert it to a powershell script)? Am I thinking about build output wrong, and there's a easier, more obvious way to handle this? Is the build output of the older builds being stored somewhere else on the server, or is it store in the database? Should I be configuring the build differently to store each build in a separate folder rather than overwriting each build in a single folder?
You can access the download zip via a properly constructed URL. For example:
https://{AccountName}.visualstudio.com/DefaultCollection/{TeamProject}/_apis/build/builds/{BuildId}/artifacts/drop?%24format=zip
I am trying to zip the contents of a Folder in SSIS, there are files and folders in the source folder and I need to zip them all individually. I can get the files to zip fine my problem is the folders.
I have to use 7.zip to create the zipped packages.
Can anyone point me to a good tutorial. I haven't been able to implement any of the samples that I have found.
Thanks
This is how I have configured it.
Its easy to configure but the trick is in constructing the Arguments. Though you see the Arguments as static in the screenshot, its actually coming from a variable and that variable is set in the Arguments expression of Execute Process Task.
I presume you will have this Execute Process task in a For Each File Ennumerator with Traverse SubFolders checked.
Once you have this basic setup in place, all you need to do is work on building the arguments to do the zipping, how you want them. A good place to find all the command line arguments is here.
Finally, the only issue I ran into was not providing a working directory in the command line arguments for 7zip. The package used to run fine on my dev environment but used to fail when running on the server via a SQL job. This was because 7zip didn't have access to the 'Temp' folder on the SQL Server, which it uses by default as the 'working directory'. I got round this problem by specifying the 'working directory as follows at the end of the command line arguments, using the -ws switch:
For e.g:
a -t7z DestinationFile.7z SourceFile -wS:YourTempDirectoryToWhichTheSQLAgentHasRights
I am trying to use Nuget to distribute a ms build .targets file. I need to modify some elements of the file to include the installed path of a few assemblies. For that I would like to use the tools folder. I am having a hard time finding the token (if it exists) to do the replacement. Has anyone encountered this problem or know of a workaround?
http://docs.nuget.org/docs/creating-packages/configuration-file-and-source-code-transformations
You'll have to go the PowerShell route to get this done, as no transform exists AFAIK. The init.ps1 file can process some parameters provided by the NuGet VSIX.
Simply add the following to the top of the init.ps1 file and use the $installPath variable in your scripts that modify the file content.
param($installPath, $toolsPath, $package, $project)
Check here for an example usage.
I am writing an application in VB.NET. In the app, I have a function which calls a Powershell script and places the resulting information in a text box.
I have two issues:
How to I ensure that when my app is published, the powershell script is included?
How do I reference the script in my code?
Currently, I simply give my function the full path to the script, which is in a folder on my Desktop. Obviously, this will not work once I deploy the app to other computers.
You will need to create a Setup project to get your script in place on your target system.
A first step is to change the Build Action to Content and Copy to Output Directory to Copy always.
Your Setup project can pick up the script from the VB app build result and put it in place when installing your app.
As for your question concerning the user configurable install path: The easiest way to handle this would be to add registry entry containing the selected program file path and have your app read the path from there.
I have two teamcity configurations one becoming my common helpers and reuseable components and my other a website which uses the common project.
I use a third configuration to publish to a test environment.
When the third configuration is run i would like it to get the artifacts from the common project and merge them with the website output and deploy. Am i asking for two much?
This ought to be pretty straightforward.
On ThirdConfig add two artifact dependencies. One whose source is CommonProject, and another whose source is WebProject. When configuring an artifact dependency it will allow you to specify which artifact files are are actually pulled from CommonProject and WebProject into ThirdConfig via the 'Artifact paths'. The artifact files can then be placed into some new folder hierarchy specific to ThirdConfig by using the 'Destination path'. These two options ought to be enough to create the directory structure that is the merging of CommonProject and WebProject. That takes care of the merge part.
The deploy is a bit more tricky. To my knowledge TeamCity does not support any sort of 'copy or upload to external location' function out of the box. For this bit you'll need to create an msbuild script (or batch file, or anything that can be run from the command line). Said script can expect the file/directory structure you've created via artifact dependencies where the root of the structure is the initial working directory of the script, and need only push these files out to your specific deploy location. That 'push' of course is going to be specific to your environment. Ftp, unc share, etc.