We have an On-Premise version of TFS 2018. I am interested in utilizing the packages (now Azure Artifacts) feature within TFS. I am wondering where the source code of the packages that are built and deployed gets stored. For example, if I build a version of an NPM package, does that source code live on our on-premise server or somewhere in the cloud?
The answer: It depends.
If you publish it to an internal feed, it's stored in your TFS database.
If you publish it to an external feed, it's stored there.
The source code is present under Code.
The artifacts that are generated after building the code is present under Pipelines->Build
Click to the build marked red in above.
The build view will have the Artifact option to access the build artifacts.
You can download the artifacts from above by clicking the three dots.
Related
In TFS, continuous build can be triggered when changes to the repository are detected. I am looking for a feature to trigger only the build when a specific file changes.
I have a library that I want to publish to an internal nuget server. I versioned the library manually in the nuspec file. I want to trigger build and publish when the nuspec file gets updated. Is this doable in TFS?
If you are using TFVC, you can specify the file directly in CI filter.
For Git in TFS 2015 , there is no such feature or setting to specific a folder within the repo by default (it's available in VSTS), as Repository and CI filter are used for different purpose:
Repository specifies which files will be downloaded from your remote
repository into a local sources directory by build agent at the
beginning of the build process.
CI filter selects the version control paths you want to include and
exclude.
There is a User Voice submitted for using repository paths as default, which similar as TFVC. Microsoft Product Team will evaluate it carefully. You can go there and vote it up to achieve it in future.
We are using Visual Studio Team Services as our source repository and for Build and Release.
What I Want to do?
We have a Repository that contains multiple directories in its root, each folder representing an ASP.NET Web Application. I want to use the Build feature to build a single solution in that repository.
The Problem
I can see the Build Agent downloading all source files for all folders/solutions in the Repository rather than just the solution I have selected.
Can someone provide the steps I need to take in order to only build one of the Solutions?
Thanks
The source Directory wasn't mapped correctly, hence was downloading all sources from the Repository root. Set this correctly and all is working well, with the a slight amendment to the Drop directory
When I started writing this question, my problem was that after a successful VSTS Build, I wasn't able to see the files relating to my web application project for release. Only the files from certain other projects in the solution were present. However, I just came across this question, which has helped.
I can now see the compiled .dll files for my web application project, after altering the configuration of the Content setting in the Build - that is, the contents of the Bin folder under that project. But I can't see anywhere the other files I need to copy the built web application to my server - the views, the scripts, the css, etc.
I'm finding the power and flexibility of VSTS's Build and Release functionality very confusing as it's complete overkill for our requirements. Up until now, I've just right-clicked on the web app project in Visual Studio selected Publish and used the File System publish method. Easy. Now that I want to automate the building and deploying of the application, it's many times more complicated!
So, can anybody tell me how I can get the solution to build in VSTS in such a way that I can then use a Copy Files task in the Release Definition to copy the files to our web server (the server isn't visible to the Internet so I'm using a locally-hosted Agent)?
In vNext build, to publish your build artifacts with the Copy files or Publish build artifacts steps. Try to use the local path on the agent where any artifacts are copied to before being pushed to their destination. For example：
Add /p:DeployOnBuild=true
/p:OutDir="$(build.artifactstagingdirectory)\" arguments in Visual
Studio Build step；
Change "Path to Publish" of Publish Build Artifacts task to
$(build.artifactstagingdirectory)\_PublishedWebsites\ProjectName:
Details please check the screenshot of build step with this question: How do I get the the expected output from a TFS 2015 build (to match my XAML build)?
Base on your comments, you have published the web app from Visual Studio. Usually, this action will generate a publish profile under Project/Properties/PublishProfiles folder. The settings you used to publish the web app is stored in the profile. So you just need to make sure this publish profile is checked into source control. And then in the TFS build, add following MSBuild arguments:
/p:DeployOnBuild=true /p:PublishProfile="publishprofile.pubxml"
The Challenge
We have an on-prem application (RM) that cannot communicate with VSO
Our code must stay in VSO
We need to give RM access to Build Definitions that are tied to our VSO source
Attempted Solution
Install TFS locally to host build definitions only
Have those build definitions pull from VSO
Problem
It looks like we can't use a VSO project directory in the Source Control Folder mapping
Is there a workaround?
Your best bet is to start migrating to the new Release Management service in VSTS, since the existing Release Management Server application is rapidly being deprecated. There are tools available to help ease the pain of migration.
You could also use RM Server in non-integrated mode -- nothing would be tied to build definitions, and you'd have to specify the path to the build drop manually when queuing the release. It can still be automated via the ReleaseManagementBuild.exe utility in the Release Management client folder, it would just take a bit more effort to build it out.
You could also build a custom build process template to pull the code from VSTS and build it, but again, that's investing a lot of effort in RM server.
[Full disclosure: I am a contributor to the migration tool linked above]
I have a TFS server, and an older build system that produces a pile of executables, installers, WinCE images, etc.
Is there an easy way to upload build artefacts to somewhere (where?) in TFS from batch files? Or is this the wrong technology?
You should use the TF Build server and set the Build Definition to "store on server". This will upload all build output to the server in an unversioned repository that while seperate from version Control is also in the database.
You can do this manually through the TFS API but it would not be registered build output associated with a build and version.