We are using TFS 2015 Update 1.
We can delete a build or it will roll off (based on retention policy), however, nothing from the build gets deleted.
Symbols on symbol server
Build artifacts
Test Results
Source
Is there anything that needs to be specially configured to enable this, is this a known issue?
This stackoverflow mentions it here, but mostly talks about drop locations: Should artifacts associated with a build record be deleted when the build record is deleted?
Microsoft's documentation says that The build record, Logs, Published artifacts, Automated test results, Published artifacts, and Published symbols. However, unsure if this is a VSTS thing as we are using TFS 2015 on premise: https://msdn.microsoft.com/en-us/library/vs/alm/build/define/retention
I'm afraid there is a misunderstanding. I assume what you are seeing is the resources in your build workspace, not the build details. If you delete the resources in the build workspace, all build details still can be seen on web access.
Actually, when you delete a build manually, everything about build will be deleted, check the screenshot below:
If you specify build retention policies, Retention policies will delete the items below:
The build record
Logs
Published artifacts
Automated test results
Published artifacts
Published symbols
You can set Policy options for Delete build record, Delete source label, Delete test results, but you can't turn off deletion of artifacts or logs (note that, for artifacts, only server drops are deleted when a build is deleted but drops to UNC shares are not):
Related
I wanted to created a demo app that does automatic deployment. In other words once I check-in my code changes, the changes can be seen on the published website. I did the following steps:
I created an .NET project on Visual Studio 2017, published the project with IIS instructions from here and here. I published my project to a local file on my machine;
The I did Continuous Delivery and Release Management using TFS 2015 and created a build and release definitions from here;
The final step was to use the Copy File to and Publish Artifacts tasks, using file share option to drop the contents to the publish folder I've created. So when I check-in my changes using TFS, the changes will be seen online.
Here is the configuration for the build definition:
The folder in the file share path is shared to everyone, and the path is correct (when I type it in the browser, I can see the folder's contents).
The error I keep getting is the following:
Publishing build artifacts failed with an error: Unable to create
directory '{p}'. Unable to verify the directory exists: '{testDir}'.
If directory is a file share, please verify the share name is correct,
the share is online, and the current process has permission to access
the share. \localhost\builddrop\drop \localhost\builddrop\drop
I've been trying to solve this for 2 days with no luck, but I could not find similar issues... I would like to know what is causing this error, or if you have any hints or tips that will get me closer to the solution.
Thanks to #Maxsur answer I realized that I did not install a build agent, which is needed for in case you want to publish your code into a file share.
I did that by going to the team foundation server web portal clicked on the gear sign, and chose Agent Queues and followed the steps. Additionally you will also need to acquire a token by clicking on your profile icon then choosing security and add new token.
Reference: https://learn.microsoft.com/en-us/vsts/pipelines/agents/v2-windows?view=vsts
Try to check (and change) an account for your build agent service.
It can be found at Windows Services -> VSTS Agent on build machine (or TFS server if it used as build machine).
This service can run under "local service" account, which cannot access network shares (even on local machine!).
Try to change this account to Administrator (for example) or setup one by guidelines of MSDN
In your Publish Artifacts Task, you've specified //localhost/builddrop/ in File share path, which is not correct. You need to specify the File share path as below:
\\servername\builddrop
I know little about this, but it has fallen to be at work to look into. I know a really tiny bit about TFS, and a little less than that about Team City, but do have access to both.
I have a Team City project that watches for commits to a TFS repo. When someone checks in files, TeamCity fetches them, then builds the project and publishes it via web deploy to our 'Dev' environment. This process is much less automated for higher grade environments like UAT etc.
Now, suddenly about two weeks ago, someone changed something, and when do a build in TeamCity I get two error messages. The first seems more introductory, that there has been a problem:
Failed to collect changes, error: Failed to get current version of TFS
root. TF400324: Team Foundation services are not available from server
applogix-projects.visualstudio.com\DefaultCollection. Technical
information (for administrator): The remote name could not be
resolved: 'applogix-projects.visualstudio.com'
The second error message, displayed on the same screen as the first, is slightly more technical, and even includes a fairly verbose stack trace, which I will omit until clearly necessary. The 2nd message:
Failed for the root '"Hollard - MLAM - Web" {instance id=4, parent
internal id=1, parent id=HollardMlamWeb_HollardMlamWeb, description:
"tfs: https://applogix-projects.visualstudio.com/DefaultCollection
$/Hollard - MLAM/HollardMLAM/Hollard.MLAM"}: Failed to get current
version of TFS root. TF400324: Team Foundation services are not
available from server
applogix-projects.visualstudio.com\DefaultCollection. Technical
information (for administrator): The remote name could not be
resolved: 'applogix-projects.visualstudio.com'
Those remove names that cannot be resolved within Team City, e.g. applogix-projects.visualstudio.com\DefaultCollection resolves fine when I paste it into a browser, and it directs me to our Visual Studio Online location for the project.
What I would appreciate as an answer here is an overview how the TFS fetch and TC build basically occur, and then some settings in TeamCity and or VS Online TFS that could be causing something like this.
It might be worth noting that if I pull the 'official' publish profile for Dev, and manually straight from VS Publish wizard, the app builds OK is well deployed to the Dev environment.
You need to check VCS settings in your teamcity build. Follow below steps:
Go to Edit Configuraton settings
Click on Version Control Settings
Check TFS URL and other settings
Check Configuring VCS Roots for more details.
If the credentials are incorrect then Visual Studio Online will report that it does not exists to prevent hackers.
Tge most likely issue is that the credentials are invalid. You should check that the user still exists and has the correct permission. You may have to use the "alternative credentials" from a users profile.
You can use the TFS Credential Viewer to get master unattended credentials for your VSO account, however these are the keys to the kingdom, so protect them.
I do have a project in TeamCity, that has a build configuration for the master release branch. This is compiled, every time a new version of our product is released.
In order to be able to pinpoint the introduction of errors, I do need a big retention time for some artifacts on this build configuration. As some other artifacts are rather big (full cd installation packages), my server's hard drive gets pretty full when simply upping the cleanup interval of this configuration.
Is it possible to configure two different cleanup intervals somehow? I would love to have a big retention time for the really important artifacts, while throwing the big ones away early.
I currently use TeamCity 9.0.3
Let's say for example, that my project has two artifacs:
smallupdatepack.zip (32 mb)
reallybigupdatecd.iso (700 mb)
I would like to configure TeamCity in a way that has the .iso kept for e.g. the last 10 builds, but the .zip is kept for the last 150 builds.
What I do not want, is a solution where all the .zip files are kept forever, while only the .iso files are deleted by an interval, which is all that seemed possible to me by using the build configuration's setting's artifact patterns alone.
You can specify custom cleanup rules for porjects/targets in Build History Clean-up page.
In your case, you can have a aggressive cleanup for all builds and a lenient cleanup for the Project/target for the master build
I have uploaded an example via an image below , if it helps
If you edit any of the settings, you can set individual period for artefacts. You can setup artefacts cleanup per target. However, for the same target you cannot setup different cleanup rules for multiple artefacts.
The answer by #Biswajit_86 looks like it's the only thing available for setting special clean up rules. I looked at it and it seems like the configuration specific settings should override the project settings and give you what you need, but maybe it doesn't work that way. Try it out and see if it works. If not, file a bug/suggestion with JetBrains.
The only other thing I could think of was to create a separate build configuration that only publishes the artifacts that you want to keep longer than your default rule. Give it a snapshot dependency on the configuration that creates the files and check the box to run on the same build agent. That way it doesn't need to rebuild them and can just publish what was already created. Set up a build trigger so that this new configuration runs whenever the other one finishes. Then set the clean up rules for this configuration to the longer retention setting.
A noob question, but googling and stack overflow search didn't seem to yield an answer.
Can someone explain what exactly are teamcity artifacts?
From the documentation
"Typically these include distribution packages, WAR files, reports,
log files, etc. When creating a build configuration, you specify artifacts
of your build at the General Settings page.
It doesn't really explain to me what an artifact is. A .Net oriented answer will be very helpful. I have a couple of builds already working on teamcity, but I'm not sure what exactly I would need an artifact for ?
thank you
Artifacts are the files you want the TeamCity server to store so that they can be downloaded after the build has finished. They will be downloadable from the TeamCity dashboard from each build.
For a .NET project you might choose the store the output of the compiler (i.e. .exe and .dll files), and the log files from running unit tests. You might just have a Windows Installer package (i.e. .msi).
It is completely up to you what gets stored for your specific needs. Just note that build artifacts do take up disk space on the TeamCity server, so if yours are large you'll want to configure the Build History Clean-up rules.
I am setting up the security for our team city build server. I would like all users to be able to view all builds, some of these builds produce artifacts with sensitive data in (connection strings and the like). Is it possible to prevent a particular role from viewing build artifacts?
Possibly a bit of a workaround, but what about if you had two builds in a build chain? The first produces the artifacts but doesn't publish them and would be visible to all users; the second doesn't have any build steps and just publishes your sensitive artifacts.
Would that work in your case?