We have incorporated an automatic check-in from a TFS build that is throwing an error with regards to a policy failure, even though the check-in does get committed.
The command we are using is as follows;
C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe checkin FileSpec1.. FileSpec2.. /bypass /override:"Check-in from automated build" /comment:"Check-in from automated build D-BuildName-M_20141013.6
The error that we are getting in the TFS build log is;
Handle Error from TF
TF10139: The following check-in policies have not been satisfied:
Inputs
Condition: True
You must associate this check-in with one or more work items.
However, from the documentation that I can find, setting the /override flag should stop this from ocurring.
Checkin Command
The file do get checked in, but the build is a partial success due to this error.
Related
I have a TFS Release definition that runs several tests as part of the deployment:
When I check the "Rerun Failed Tests" Option in my "Visual Studio Test" step in:
My unit tests no longer run as part of my release. The release fails with the following error in the "Visual Studio Test" step:
2019-02-22T16:21:33.0983821Z ##[error]Error opening response file
'C:\TFS' 2019-02-22T16:21:33.1413767Z ##[error]The test source file
"C:\TFS Agent\ _work\r6\a\Agent_work_temp\ea14a091-36bd-11e9-99f5-51895cf3942e.txt" provided was not found.
I figured since the error started with the following statement:
Error opening response file 'C:\TFS'
That there is some sort of bug with the TFS test runner where the call to the task to execute the tests is not putting the path in quotes. I changed all my TFS build agents to using the following "type" of paths for all builds(I removed all spaces from the folder the TFS agents lived in):
C:\TFSAgent\ _work
And it seems to work now...
I have a TFS 2013 build that I'm trying to get to publish to a folder on the build server. I've installed WebDeploy, but I always get the error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (4274): Web deployment task failed. (Could not connect to the remote computer ("localhost"). On the remote computer, make sure that Web Deploy is installed and that the required process ("Web Management Service") is started. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DESTINATION_NOT_REACHABLE.)
I've set up a website on the build server and that's where I'm trying to publish the website. Actually I don't even care about publishing it per se - I just need my build output to go to a folder locally automatically. Right now we have to manually open the solution and choose Publish... to get the output that subsequent InstallShield builds need for input. Here are my MSBuild arguments. Does anyone have any idea what could be missing?
/p:SrcDir=C:\Builds\TFS\WebApps\Src
/p:RevKeyname=WebAppsRevNr
/p:DeployOnBuild=true
/p:DeployTarget=MsDeployPublish
/p:MSDeployServiceURL=https://127.0.0.1:8172/msdeploy.axd
/p:CreatePackageOnPublish=True
/p:DeployIisAppPath="WebApp"
/p:MsDeployPublishMethod=WMSVC
/p:AllowUntrustedCertificate=True
/p:AutoParameterizationWebConfigConnectionStrings=False
/p:Authtype=NTLM /p:username=""
I've checked both net start wmsvc and net start msdepsvc and both are running. Any ideas?
Thanks!
UPDATE
I've tried everything that Andy suggested and now when I run this from the command line I get this bizarre error message:
"C:\Workspace\VS2013\WebApps\Main\Src\webapps.sln" (default target) (1) ->
"C:\Workspace\VS2013\WebApps\Main\Src\CoreWebApps\CoreWebApps.csproj"
(default
target) (7) ->
(AutoParameterizationWebConfigConnectionStringsCore target) ->
C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web\Microsoft.Web
.Publishing.targets(2295,5): error : Could not open Source file: Could not
find
a part of the path
'C:\Workspace\VS2013\WebApps\Main\Src\CoreWebApps\Areas\Adm
in\Views\Web.config;Areas\Admin\Views\Web.config'.
[C:\Workspace\VS2013\WebApps
\Main\Src\CoreWebApps\CoreWebApps.csproj]
Any idea why it's looking for Web.config;Areas\Admin\Views\Web.config'.? That makes no sense.
Please try below items to narrow down the issue:
Try to use IP or Machine Name instead of "localhost"
Logon your build agent machine, then manually execute the same
MSBuild command within the same arguments(which you provided in build
definition) to build and deploy your solution, then check result. You
need to ensure you can manually run the same MSBuild command within
deploy argument to build and deploy your solution successfully from
build agent machine. Then use the same deploy arguments in TFS Build
definition.
Double check Web Deploy settings to make sure that the name of the
website is exactly that of what's in IIS.
Install Web Management Tools before Web
Deploy : Install the Web Management Services (Roles -> Web Server >
Management Tools > Management Services). Then uninstall Web Deploy, and then install Web Deploy again.
You can also reference this thread for your troubleshooting.
Update:
For the issue "Could not open Source file: Could not find a part of the path" you can reference below similar articles for the troubleshooting.
https://social.msdn.microsoft.com/Forums/en-US/8f959964-c951-4f9a-8486-8283a925c9f6/build-error-could-not-open-source-file-though-i-know-it-exists?forum=windowsazurewebsitespreview
https://our.umbraco.org/forum/getting-started/installing-umbraco/60222-Umbraco-721-Build-fails-after-deploy-to-Azure-WebSite (See the last two answers)
I'm trying to install the 3.10.2 version of the Wix Toolset Installer but when I launch the installer nothing happens. Pulling up the log file reveals the following errors:
[15A4:1580][2016-03-04T07:54:57]e000: Error 0x80070005: Failed to launch clean room process: C:\Users\MALLAR~1\AppData\Local\Temp\1\{BA709DF5-6D54-418B-9760-DD363E3FE5DD}\.cr\wix310.exe
[15A4:1580][2016-03-04T07:54:57]e000: Error 0x80070005: Failed to run untrusted mode.
I am unable to find anything related to this error.
3.10.2 introduced the clean room concept to mitigate dll hijacking attacks. This involves copying itself to a clean folder in the user's temp directory and then doing most of the work from that new process. Aggressive AV products might interfere with this. For more information about clean room see http://wixtoolset.org/development/wips/5184-burn-clean-room/ and https://www.firegiant.com/blog/2016/1/20/wix-v3.10.2-released/.
Is there any way to activate a test related log at our TFS build server?
If a tests fails, I can't find any information about it (besides the name of the test).
I checked:
The drop folder. There is the normal log, but this log ends after the compilation, so before the tests are checked
The compilation folder at the build server (C:\Builds\8...). There is a folder "Test Results" next to the "bin" and the "src" folder, but the "Test Results" folder is always empty.
The build definition. Couldn't find any option to activate a log regarding tests.
When i check the build in the web view, all I see is:
x/y test(s) passed, z failed, 0 inconclusive
No Code Coverage Results
Other Errors and Warnings
z+1 error(s), 0 warning(s)
Failed z1
Failed z2
...
Failed zn
Test Run Failed.
How can I find further information, why the tests are failing?
We are using:
TFS 2012 + a TFS 2012 build server
Rolling builds
Visual Studio 2013 + Resharper at our local machines
NUnit + MOQ
Rolling builds (no more than 30 minutes) build definition
We got rid of the problem after we upgraded to TFS 2015.
Now I just have to check the web interface, if a build is broken because of a unit test I click at the specific build to open the detail view of it. At the right side there is an area named Test result, where I can click at a link to get to the Test Run page. Under Attachments (1) I got a file of the type Visual Studio Test Results File, which shows me exactly what the problem was.
I have 2 build definitions set up for a solution, 1 is a nightly build that is triggered every night and the other is a Gated Check-In build that will trigger when developers try to check new changes into source control. The nightly build is using a custom template that increases assembly versions using method that has been slightly modified from the Ewald Hoffman method. When a file is checked in via the custom activity to check files in, i get the build error:
Your check-in could not be completed because it affects the following
gated build definitions \Project\GatedBuld. To complete your check-in
you will need to queue a build of the shelveset
Gated_2011-11-08_09.31.42.6934;DOMAIN\TFSBuildAccount.
At present I have not been able to find a way to bypass this gated check-in build (CI builds are prevented using the *NO_CI* check in comment).
I have tried setting the "Override check-in validation by build" permission for the build service account (via Security for the gated build), but as far as I know this will only prevent the gated build when checking code in manually (via a check box presented in the Gated Check-in dialog). What I'm looking for is a way to bypass a gated build when checking changes in automatically
Any suggestions?
As always, thanks for any help in advance
When you checkin your changes programmatically, you can create a WorkspaceCheckInParameters object and set its OverrideGatedCheckIn property to true. The following code would bypass gated checkin (and also CI):
var pendingChanges = workspace.GetPendingChanges();
if (pendingChanges.Any())
{
WorkspaceCheckInParameters parameters = new WorkspaceCheckInParameters(pendingChanges, BuildCommonUtil.NoCICheckInComment)
{
OverrideGatedCheckIn = true,
};
workspace.CheckIn(parameters);
}
Note that you need to grant the permission to bypass gated checkin on the account that performs the checkin for all affected build definitions. In this case, it is the build service account of the Nightly build.
I had written the Assembly Version update code in Powershell and could not find the slimier code "OverrideGatedCheckIn = true" for Powershell and all I did was moving assembly version files (SharedAssembly.vb & SharedAssembly.cs) to a folder called SharedAssembly and excluding them to considering for the GatedCheck-In process.