The Deploy test agent task in TFS release definition fails with the below exception:
Unhandled Exception:
System.Management.Automation.PSInvalidOperationException: The
WriteObject and WriteError methods cannot be called from outside the
overrides of the BeginProcessing, ProcessRecord, and EndProcessing
methods, and they can only be called from within the same thread.
Validate that the cmdlet makes these calls correctly, or contact
Microsoft Customer Support Services. 2017-06-16T08:49:49.9634068Z
at
System.Management.Automation.MshCommandRuntime.ThrowIfWriteNotPermitted(Boolean
needsToWriteToPipeline) 2017-06-16T08:49:49.9634068Z at
System.Management.Automation.MshCommandRuntime.WriteHelper_ShouldWrite(ActionPreference
preference, ContinueStatus lastContinueStatus)
2017-06-16T08:49:49.9634068Z at
System.Management.Automation.MshCommandRuntime.WriteWarning(WarningRecord
record, Boolean overrideInquire) 2017-06-16T08:49:49.9634068Z at
System.Management.Automation.Cmdlet.WriteWarning(String text)
2017-06-16T08:49:49.9634068Z at
Microsoft.TeamFoundation.DistributedTask.Task.DistributedTestAutomation.Logger.WriteWarning(String
message) 2017-06-16T08:49:49.9634068Z at
Microsoft.TeamFoundation.DistributedTask.Task.DistributedTestAutomation.TestAgentDownloader.wc_DownloadFileCompleted(Object
sender, AsyncCompletedEventArgs e) 2017-06-16T08:49:49.9634068Z at
System.Net.WebClient.OnDownloadFileCompleted(AsyncCompletedEventArgs
e) 2017-06-16T08:49:49.9634068Z at
System.Threading.ExecutionContext.RunInternal(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx) 2017-06-16T08:49:49.9634068Z at
System.Threading.ExecutionContext.Run(ExecutionContext
executionContext, ContextCallback callback, Object state, Boolean
preserveSyncCtx) 2017-06-16T08:49:49.9634068Z at
System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
2017-06-16T08:49:49.9634068Z at
System.Threading.ThreadPoolWorkQueue.Dispatch()
2017-06-16T08:49:55.4477257Z ##[error]PowerShell script completed with
255 errors.
The task executes successfully if the Update test agent check box is not checked.
Solution mentioned here https://github.com/Microsoft/vsts-tasks/issues/2964 and https://social.msdn.microsoft.com/Forums/sqlserver/en-US/dae4c62d-cd23-40ad-83cf-2555d37c0bb9/test-agent-deployment-failing?forum=tfsbuild does not seems to work either
Advanced - Update test agent
If set, and the test agent is already installed on the test
machines, the task will check if a new version of the test agent is
available.
First, check if the test agent is already intalled on the machines,
if not this maybe the root cause.
Try to do the deploy test agent with same settings in the build
definition instead of release. This will narrow down if the issue is
only related to release or not.
Check the Even Log in the test agent machine if there are some useful
info.
Try to deploy the test agent to another machine with old test agent
installed and "update test agent" checked.
Besides, if you are using TFS2017 update2Rc and want to deploy latest test agent, suggest you to use Version 2. instead of 1. for the Visual Studio Test Agent Deployment task and try again.
The issue was resolved by downloading the testagent exe and copying the same to a share folder that has access to the build agents. This is configured under the advanced section and provide the share path under Test Agent Location.
Related
First off the setup in question:
A Jenkins Instance with several build nodes and on prem Azure-Devops server containing the Git Repositories.
The Repo in question is too large to always build on push for all branches and all devs, so a small workaround was done:
The production branches have a polling enabled twice a day (because of testing duration which is handled downstream more builds would not help with quality)
All other branches have their automated building suppressed. They still can start it manually for Builds/Deployments/Unittests if they so choose.
The jenkinsfile has parameterization for which platforms to build, on prod* all the platforms are true, on all other branches false.
This helps because else the initial build of a feature branch would always build/deploy locally all platforms which would take too much of a load on the server infrastructure.
I added a service endpoint for Jenkins in the Azure Devops, added a Buildvalidation .yml - this basically works because when I call the sourcebranch of the pull request with the merge commitID i added a parameter
isPullRequestBuild which contains the ID of the PR.
snippet of the yml:
- task: JenkinsQueueJob#2
inputs:
serverEndpoint: 'MyServerEndpoint'
jobName: 'MyJob'
isMultibranchJob: true
captureConsole: true
capturePipeline: true
isParameterizedJob: true
multibranchPipelineBranch: $(System.PullRequest.SourceBranch)
jobParameters: |
stepsToPerform=Build
runUnittest=true
pullRequestID=$(System.PullRequest.PullRequestId)
Snippet of the Jenkinsfile:
def isPullRequest = false
if ( params.pullRequestID?.trim() )
{
isPullRequest = true
//do stuff to change how the pipeline should react.
}
In the jenkinsfile I look whether the parameter is not empty and reset the platforms to build to basically all and to run the unittests.
The problem is: if the branch has never run, Jenkins does not already know the parameter in the first run, so it is ignored, building nothing, and returning with 0 because "nothing had to be done".
Is there any way to only run the jenkins build if it hasnt run already?
Or is it possible to get information from the remote call if this was the build with ID 1?
The only other thing would be to Call the Jenkins via web api and check for the last successful build, but in that case I would have have the token somewhere stored in source control.
Am I missing something obvious here? I dont want to trigger the feature branch builds to do nothing more than once, because Devs could lose useful information about their started builds/deployments.
Any ideas appreciated
To whom it may concern with similar problems:
In the end I used the following workaround:
The Jenkins Endpoint is called via a user that only is used for automated builds. So, in case that this user triggered the build, I set everything to run a Pull Request Validation, even if it is the first build. Along the lines of
def causes = currentBuild.getBuildCauses('hudson.model.Cause$UserIdCause')
if (causes != null)
{
def buildCauses= readJSON text: currentBuild.getBuildCauses('hudson.model.Cause$UserIdCause').toString()
buildCauses.each
{
buildCause ->
if (buildCause['userId'] == "theNameOfMyBuildUser")
{
triggeredByAzureDevops = true
}
}
}
getBuildcauses must be allowed to run by a Jenkins Admin for that to work.
I'm getting this error when trying to run unit tests against my ASP.NET MVC project using a project called MvcIntegrationTestFramework in Visual Studio 2015. As I've searched around most of the solutions suggest switching to use IIS Express. But I'm already using IIS Express. I could also set up IIS but I'd rather not since multiple developers would have to do the same in their environments.
Other people are suggesting that modifying the Response.Headers collection directly could be causing this error, but I'm not seeing any code in the project that could be doing that.
Is there anything else you can think of that I might be overlooking that could cause this error?
Here is the full error and stack trace...
[PlatformNotSupportedException: This operation requires IIS integrated
pipeline mode.] System.Web.HttpResponse.get_Headers() +242
Microsoft.Owin.Host.SystemWeb.OwinCallContext.CreateEnvironment() +532
Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContext.GetInitialEnvironment(HttpApplication
application) +372
Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContext.PrepareInitialContext(HttpApplication
application) +19
Microsoft.Owin.Host.SystemWeb.IntegratedPipeline.IntegratedPipelineContextStage.BeginEvent(Object
sender, EventArgs e, AsyncCallback cb, Object extradata) +354
System.Web.AsyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()
+673 System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +146
I'm looking into this myself currently. So far I've learned:
HttpRuntime.UsingIntegratedPipeline can be used to verify whether or not the Http application is running in an integrated pipeline (as the name suggests)
The Microsoft.Web.Administration.ApplicationPool.ManagedPipelineMode property can be used to set the pipeline mode, but this only works when running in an IIS application
IntegratedPipelineMode is only available if an HttpApplication runs via IIS
MvcIntegrationTestFramework starts an HttpApplication, but does not use IIS, so it cannot use IntegratedPipelineMode
Check the reference sources for HttpRuntime:
https://referencesource.microsoft.com/#system.web/HttpRuntime.cs
This bit of code indicates UseIntegratedPipeline is only set to true when running in some kind of IIS context. It also indicates the _iisVersion is only filled in in that case.
internal static void PopulateIISVersionInformation() {
if (IsEngineLoaded) {
uint dwVersion;
bool fIsIntegratedMode;
UnsafeIISMethods.MgdGetIISVersionInformation(out dwVersion, out fIsIntegratedMode);
if (dwVersion != 0) {
// High word is the major version; low word is the minor version (this is MAKELONG format)
_iisVersion = new Version((int)(dwVersion >> 16), (int)(dwVersion & 0xffff));
_useIntegratedPipeline = fIsIntegratedMode;
}
}
}
I debugged into the BrowsingSession class of MvcIntegrationTestFramework. The ProcessRequest method will throw an exception. In that method it is possible to view the properties of HttpRuntime:
The fact that the _iisVersion is null seems to prove this.
I would assume the MvcIntegrationTestFramework "should be edited" to run the HttpApplication in IIS. But the whole point of the framework is to simulate the application, so doing that would probably defeat the purpose.
I'm trying to convert xaml builds to TFS 2015 builds and running into a problem where the build seems to almost complete but then trows the following error:
And just in case you can't see the image, the error is:
Finishing task: VSBuild
System.NotSupportedException: The given path's format is not supported.
at System.Security.Permissions.FileIOPermission.QuickDemand(FileIOPermissionAccess access, String fullPath, Boolean checkForDuplicates, Boolean needFullPath)
at Microsoft.TeamFoundation.DistributedTask.Agent.Common.ContextExtensions.GetExpandedPath(ILogServiceContext context, String path, String defaultPathRoot)
at Microsoft.TeamFoundation.DistributedTask.Worker.JobRunner.ResolveInputs(IJobContext context, IJobExtension jobExtension, TaskWrapper task, IDictionary`2 variables)
at Microsoft.TeamFoundation.DistributedTask.Worker.JobRunner.Run(IJobContext jobContext, IJobRequest job, IJobExtension jobExtension, CancellationTokenSource tokenSource)
Worker Worker-44f37a2f-ff1b-43a7-b619-88373a8687c0 finished running job 44f37a2f-ff1b-43a7-b619-88373a8687c0
Finishing Build
It doesn't give me any clues as to where the code is that's causing this error so I really don't know where to look. When I look in the c:\Agent_work\5\a folder it looks like the project is building just fine (although I have no way of verifying that). But all of the files seem to be there including a subdirectory created by an .exe called in the Post-build event on the last .csproj file in the solution which I never even expected to be called and run in TFS 2015! Who knew - that's great! Now if I could just get my build to start working...
I figured it out. It was simply the trailing backslash on the source folder. I had $(build.artifactstagingdirectory)_PublishedWebsites\BOTWSitecoreWeb\ when it should have been $(build.artifactstagingdirectory)_PublishedWebsites\BOTWSitecoreWeb. I just happened to guess this was it - there was no help from the logs.
I installed Service Control(V1.20.0) recently to my QA server, I install it using ServiceControl Management Utility , I didn’t change the default values, I didn’t move DB location.
I was able to browse to the RavenDB when I am in maintenance mode.
The particular endpoints are created, I also have non-expired license.
This is what i found in the db log file
Microsoft.Isam.Esent.Interop.EsentInvalidInstanceException: Invalid
instance handle at Microsoft.Isam.Esent.Interop.Api.Check(Int32
err) in
C:\Work\ravendb\SharedLibs\Sources\managedesent-61618\EsentInterop\Api.cs:line
2739 at
Microsoft.Isam.Esent.Interop.Api.JetBeginSession(JET_INSTANCE
instance, JET_SESID& sesid, String username, String password) in
C:\Work\ravendb\SharedLibs\Sources\managedesent-61618\EsentInterop\Api.cs:line
823 at
Raven.Storage.Esent.StorageActions.DocumentStorageActions..ctor(JET_INSTANCE
instance, String database, TableColumnsCache tableColumnsCache,
OrderedPartCollection`1 documentCodecs, IUuidGenerator uuidGenerator,
IDocumentCacher cacher, EsentTransactionContext transactionContext,
TransactionalStorage transactionalStorage) in
c:\Builds\RavenDB-Stable-2.5\Raven.Database\Storage\Esent\StorageActions\General.cs:line
76
With the amazing help of Particular team, I was able to solve the issue. In my case the problem was I have created the Particular.ServiceControl queue manually. And it needs to be transnational, this was the error i was getting in event viewer:
Queue must be transactional if you configure your endpoint to be
transactional
Deleting the queue, and let Service Control Management tool take care of creating all necessary queues.
I have the TFS Integration tool running, performing a one-way migration (call it A) between a 2010 instance (call it X) and a 2013 instance (call it Y). This tool was also configured to do a one-way migration (call it B) from a different 2010 instance (call it Z) to Y.
Now I only need migration A, so I removed migration B. However, I now see in the logs every minute an entry like this (actual server name replaced in emphasized text):
[10/22/2015 1:42:53 PM] TfsIntegrationJobService.exe Error: 0 : [10/22/2015 1:42:53 PM] Sync Monitor Thread: SyncMonitor: ERROR: An unexpected error occurred polling migration source 'TFS instance Z (VC)': Microsoft.TeamFoundation.TeamFoundationServiceUnavailableException: Team Foundation services are not available from server TFS instance Z\DefaultCollection.
Technical information (for administrator):
HTTP code 503: Service Unavailable ---> System.Net.WebException: The remote server returned an error: (503) Server Unavailable.
at System.Net.HttpWebRequest.GetResponse()
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.AsyncWebRequest.ExecRequest(Object obj)
--- End of inner exception stack trace ---
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.ProcessHttpResponse(HttpWebResponse response, Stream responseStream, WebException webException, XmlReader& xmlResponseReader)
at Microsoft.TeamFoundation.Client.TeamFoundationClientProxyBase.ExecWebServiceRequest(HttpWebRequest request, XmlWriter requestXml, String methodName, HttpWebResponse& response)
at Microsoft.TeamFoundation.VersionControl.Client.Repository.QueryChangeset(Int32 changesetId, Boolean includeChanges, Boolean generateDownloadUrls, Boolean includeSourceRenames)
at Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.GetChangeset(Int32 changesetId, Boolean includeChanges, Boolean includeDownloadInfo, Boolean includeSourceRenames)
at Microsoft.TeamFoundation.VersionControl.Client.VersionControlServer.GetChangeset(Int32 changesetId, Boolean includeChanges, Boolean includeDownloadInfo)
at Microsoft.TeamFoundation.Migration.Tfs2010VCAdapter.TfsVCSyncMonitorProvider.GetSummaryOfChangesSince(String lastProcessedChangeItemId, List`1 filterStrings)
at Microsoft.TeamFoundation.Migration.Toolkit.SyncMonitor.Endpoint.Poll()
at Microsoft.TeamFoundation.Migration.Toolkit.SyncMonitor.MonitorWatcher.Worker()
The question is, how can I get it to stop polling instance Z? Restoring connectivity to that server is not an option. And letting it continue polling is not an option because it polls every minute and waits nearly a minute to time out - leaving basically no time to do anything else.
You need to delete these configurations which are used to migrate Instance Z. On the TFS Integration -> Open Existing -> select that configuration and click Delete.
Or, you can create a fresh new configuration to migrate from Instance X to Instance Y.