I Have a pretty basic pipeline running on my self-hosted agent:
trigger:
- main
pool:
name: '3A'
demands:
- Produkt -equals 3A-Editor
steps:
- checkout: self #pretty redundant, just to show a second step
- task: DownloadPipelineArtifact#2
inputs:
buildType: 'specific'
project: '65189d0a-e547-4e24-9be0-f5c1ef304db9'
definition: '324'
buildVersionToDownload: 'latest'
artifactName: 'templates'
targetPath: '$(Build.SourcesDirectory)/gdb'
That run for ages without any problems, but since a week or so the DownloadPipelineArtifact-step throws an error:
Es konnte keine Verbindung hergestellt werden, da der Zielcomputer die
Verbindung verweigerte.
which indicates a connection-error. However I'm not even sure which computer want to connect to which here.
The checkout-step runs successfully, so I expect the pipeline is able to run jobs on that agent.
I used the UI for the download-step to chose the correct project and pipeline, so the above IDs should also be okay.
Related
I'm trying to code sign a Wix installer package that was developed by another company (I have limited knowledge of Wix).
As a proof of concept piece of work we did I signed the MSIs and EXE using WixSharp.DigitalSignature as below, which seemed to work with a self signed certificate
project.DigitalSignature = new DigitalSignature()
{
PfxFilePath = Resources.CertificateUri,
HashAlgorithm = HashAlgorithmType.sha256,
Description = Resources.BootstrapperProject,
TimeUrls = new System.Collections.Generic.List<Uri>() { new Uri("http://timestamp.digicert.com") }
};
But now the time has come to implement with a proper certificate from GlobalSign it seems the above option isn't now possible as we now have to store the certificate in Azure Key Vault.
We have tried signing the MSIs and EXEs with AzureSignTool through the pipelines but when running the installer I'm always getting the error "0x80070001 - Incorrect function".
The log file outputs the below information:
[0ADC:1034][2021-12-21T11:00:53]i320: Registering bundle dependency provider: {0315ab7d-04da-4a77-8536-fa0e0211c531}, version: 1.0.0.124
[0ADC:1034][2021-12-21T11:00:53]i371: Updating session, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{0315ab7d-04da-4a77-8536-fa0e0211c531}, resume: Active, restart initiated: No, disable resume: No
[1710:10C8][2021-12-21T11:00:53]i336: Acquiring container: WixAttachedContainer, copy from: C:\Users\Administrator\Desktop\DigiView Installer.exe
[1710:10C8][2021-12-21T11:00:58]i000: Setting string variable 'WixBundleLastUsedSource' to value 'C:\Users\Administrator\Desktop\'
[1710:1720][2021-12-21T11:00:58]e000: Error 0x80070001: Failed to extract all files from container, erf: 1:2:0
[1710:10C8][2021-12-21T11:00:58]e000: Error 0x80070001: Failed to wait for operation complete.
[1710:10C8][2021-12-21T11:00:58]e000: Error 0x80070001: Failed to open container.
[1710:10C8][2021-12-21T11:00:58]e000: Error 0x80070001: Failed to open container: WixAttachedContainer.
[1710:10C8][2021-12-21T11:00:58]e312: Failed to extract payloads from container: WixAttachedContainer to working path: C:\Users\ADMINI~1\AppData\Local\Temp\2\{4D72E5B3-50AB-4B5D-BD93-BC559386F434}\5A4A1D973A87D89730BC20C9B805B7A384EF1383, error: 0x80070001.
[1710:0F88][2021-12-21T11:00:59]e000: Error 0x80070001: Failed while caching, aborting execution.
There is very limited information online about this scenario, does anyone have a way forward for the particular problem I'm facing? Or can point me to some useful resources?
I'm having some troubles with my azure devops testing-pipeline.
I'm using xunit tests and every test-project runs correctly and I can view the test results, but the pipeline fails anyway because of the following error
##[error]Testhost process exited with error: A fatal error was encountered. The library 'hostpolicy.dll' required to execute the application was not found in 'C:\Program Files\dotnet'.
##[error]. Please check the diagnostic logs for more information.
Like suggested here, I added an additional filter for testhost.dll so my yaml-snippet looks like this:
- task: VSTest#2
inputs:
platform: '$(buildPlatform)'
configuration: '$(buildConfiguration)'
testSelector: 'testAssemblies'
testAssemblyVer2: |
**\*test.dll
!**\*TestAdapter.dll
!**\obj\**
!**\testhost.dll
!*testhost.dll
searchFolder: '$(System.DefaultWorkingDirectory)'
diagnosticsEnabled: true
codeCoverageEnabled: true
However, the error still occurs and my Build is marked as failed.
How can I fix this?
This GitHub issue should hopefully help.
Things to try:
remove references from one test assembly to another
update Microsoft.NET.Test.SDK to 16.6.1
add an application.runtimeconfig.json file
Hope this helps!
The step "Run functional tests" in a build lauched with TFS 2015 ends with this error message :
DistributedTests: Test run is aborted. Logging details of the run logs.
DistributedTests: Une nouvelle série de tests a été créée.
Série de tests mise en file d\'attente pour Project Collection Build Service (TEAM FOUNDATION).
DistributedTests: Test discovery started.
DistributedTests: Test Run Discovery Completed . Test run id : 14886
DistributedTests: 2 test cases discovered.
DistributedTests: Test execution started. Test run id : 14886
DistributedTests: UnExpected error occured during test execution. Try again.
DistributedTests: Error : Une ou plusieurs erreurs se sont produites.--->Failed to obtain durationInMs field.
DistributedTests: Test run aborted. Test run id: 14886
Any ideas to fix it?
There is a known issue on vsts-tasks github, check you are not having the following:
System is expected to throw “Failed to obtain durationInMs” error if TFS/Build Agent is Update 1, but Test Agent is higher than Update 1 viz Update 2. The reason is that we have done changes around durationInMs in Test Agent 2015 Update 2 and also in TFS 2015 Update 2, hence Test Agent 2015 Update 2 and higher versions are not backward compatible with lower versions of TFS.
Also both from the linked issue and from here it seems that the reason can be that the system is in French.
While generating test cases using command line option I am getting the following error.
EvoSuite
Going to generate test cases for class: testgeneration.Multiplication
[MASTER] 14:03:51.716 [main] ERROR TestGeneration - Not possible to access to clients. Clients' state: Terminated with exit status 1. Master registry port: 14981
[MASTER] 14:03:51.803 [main] ERROR SearchStatistics - No statistics has been saved because EvoSuite failed to generate any test case
[MASTER] 14:03:51.904 [main] ERROR TestGeneration - failed to write statistics data
That can happen if EvoSuite's client process does crash. Why is crashing is hard to tell without further information. Could it be a bug in EvoSuite, or some weird combination of events.
I tried to install the Stanbol version from branch "release-0.12" from github.
On my system I have:
Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_55, vendor: Oracle Corporation
Java home: /usr/lib/jvm/java-7-openjdk-i386/jre
When I start the command:
mvn install
I get the following error for the Apache Stanbol Integration Tests => error-log
The first lines of the error are:
06.08.2014 15:47:02.025 *INFO * [main] Setting org.osgi.service.http.port=8765
06.08.2014 15:47:02.026 *INFO * [main] Starting launcher ...
06.08.2014 15:47:02.030 *INFO * [main] HTTP server port: 8765
15:47:03,614 INFO StanbolTestBase:163 - Got HttpHostConnectException at
http://localhost:8765/ - will retry
When I skiped the test I also got no response from the server...
I already tried it with java-version 1.6, but there I got the error:
[WARNING] Rule 0: org.apache.maven.plugins.enforcer.RequireJavaVersion failed
with message:
Java 7 or higher is required to compile this module
Has someone an idea what I made wrong (does it need some further software requirements)? Or how can I get the server running correctly?
The integration test starts a Stanbol Server (actually the full launcher) in its own JVM. The tests waits for up to 180 seconds for this server to start. During that time the test resends some test requests to check if the server is up and running.
Based on the provided log this period starts at about "15:47" so the test should wait until about "15:50" before it gives up.
Because of the line
^C15:48:42,236 INFO StanbolTestBase:146 - Got 404 at http://localhost:8765/entityhub - will retry
in the log my guess is that the build process was manually canceled with ^C before the server was fully started.
The server side logs of the test run are available at target/launchdir/stanbol/logs/error.log. If the integration tests do fail one will usually find the reason in this log file.