While the node install task is reached pipeline fails with the above error how to resolve this
In the task removed the optional check latest option then it worked
Related
Used a self-hosted agent for building sample java but getting ##[error]Unhandled: EPERM: operation not permitted, stat 'C:\Users\DELL\Downloads\apache-maven-3.6.3\bin\mvn.cmd'
Please help me troubleshoot this error:
This issue was resolved. The root cause was due to authentication issue.
I was using a self-hosted agent and my Maven was asking for authentication but it was unable to autheniticate.
How I resolved this error :
I installed maven in D drive and changed the env variables such that it points to D drive then it worked fine.
We are seeing Azure Release Pipelines unable to download artifacts on a certain server - it times out after about 2min and we suspect it's a proxy issue i.e. the agent is NOT using the proxy it is configured to use.
When we disable/bypass the artifact download and let the agent run a curl command we see that it also times out when accessing HTTPS URLs but HTTP URLs are fine. So we can reproduce the problem with curl https://curl.haxx.se for example. Running this command directly on the server (as root or any user) works fine so it's an agent issue.
When we tell the agent to export https_proxy=<our proxy> (note httpS) and then CURL, the call to HTTPS succeeds. This implies that CURL knows about our HTTP_PROXY but not about HTTPS_PROXY and curl seems to be ignoring HTTP_PROXY for HTTPS domains. We suspect the agent passes/sets HTTP_PROXY but not HTTP_PROXY!
The problem is we can't run an export command before the artifact download as this is always the first step in the deployment group BEFORE any scripts can be executed.
Aside from the fact that we have export http_proxy and export https_proxy correctly defined in /etc/environment it would seem that the azure pipeline is unaware of the proxy when it tries to download artifact. Our .proxy file contains the proxy as http://proxy.ourlandomain:3333 and it is shown in the agent log as:
Agent is running behind proxy server: 'http://proxy.ourlandomain.com:3333'
...and then later...
[AGENT_PROXYURL] --> [http://proxy.ourlandomain.com:***#ourdomain.com]
It looks somehow garbled. Is it hiding 3333 as a secret with *** and where is this #ourdomain.com coming from???
Finally, the agent is running as root and when we curl HTTPS URLs as root it works fine.
WHY is the agent not using the proxy OR WHY is the artifact download failing?
2020-07-06T13:15:26.6383041Z ##[debug]Evaluating condition for step: 'Download artifact - Test1Artifact - Test1Linux'
2020-07-06T13:15:26.6423849Z ##[debug]Evaluating: succeeded()
2020-07-06T13:15:26.6429537Z ##[debug]Evaluating succeeded:
2020-07-06T13:15:26.6469145Z ##[debug]=> True
2020-07-06T13:15:26.6477846Z ##[debug]Result: True
2020-07-06T13:15:26.6517309Z ##[section]Starting: Download artifact - Test1Artifact - Test1Linux
2020-07-06T13:15:26.6717563Z ==============================================================================
2020-07-06T13:15:26.6718055Z Task : Download pipeline artifact
2020-07-06T13:15:26.6718463Z Description : Download a named artifact from a pipeline to a local path
2020-07-06T13:15:26.6718700Z Version : 1.2.5
2020-07-06T13:15:26.6719046Z Author : Microsoft Corporation
2020-07-06T13:15:26.6719901Z Help : Download a named artifact from a pipeline to a local path
2020-07-06T13:15:26.6720216Z ==============================================================================
2020-07-06T13:15:26.9979976Z Download from the specified build: #81654
2020-07-06T13:15:26.9980651Z Download artifact to: /prg/azure/deploy2/_work/r1/a/Test1Artifact/Test1Linux
2020-07-06T13:15:30.3332655Z ##[debug]Dedup parallelism: 192
2020-07-06T13:17:10.3457179Z ##[error]One or more errors occurred. (A task was canceled.)
2020-07-06T13:17:10.3471565Z ##[debug]Processed: ##vso[task.logissue type=error;]One or more errors occurred. (A task was canceled.)
2020-07-06T13:17:10.3485598Z ##[debug]Processed: ##vso[task.complete result=Failed;]
2020-07-06T13:17:10.3510288Z ##[debug] at System.Threading.Tasks.Task`1.GetResultCore(Boolean waitCompletionNotification)
at System.Threading.Tasks.Task`1.get_Result()
at Microsoft.VisualStudio.Services.BlobStore.Common.Telemetry.BlobStoreApplicationInsightsTelemetrySender..ctor(IAppTraceSource tracer, Uri baseAddress)
at Microsoft.VisualStudio.Services.BlobStore.Common.Telemetry.BlobStoreClientTelemetry..ctor(IAppTraceSource tracer, Uri baseAddress)
at Agent.Plugins.PipelineArtifact.DedupManifestArtifactClientFactory.CreateDedupManifestClient(AgentTaskPluginExecutionContext context, VssConnection connection, CancellationToken cancellationToken, BlobStoreClientTelemetry& telemetry)
at Agent.Plugins.PipelineArtifact.PipelineArtifactServer.DownloadAsync(AgentTaskPluginExecutionContext context, PipelineArtifactDownloadParameters downloadParameters, DownloadOptions downloadOptions, CancellationToken cancellationToken)
at Agent.Plugins.PipelineArtifact.DownloadPipelineArtifactTaskV1.ProcessCommandInternalAsync(AgentTaskPluginExecutionContext context, CancellationToken token)
at Agent.PluginHost.Program.Main(String[] args)
2020-07-06T13:17:10.3588657Z ##[section]Finishing: Download artifact - Test1Artifact - Test1Linux
UPDATE: Setting Environment=https_proxy=http://proxy.ourlandomain.com:3333 in the systemd config for the agent solves the problem and the artifact is downloaded. It would seem that either the download artifact task is not respecting http_proxy OR the agent should be and isn't setting https_proxy.
Download Artifact Fails ignoring http_proxy
According to the document Run a self-hosted agent behind a web proxy:
When your self-hosted agent requires a web proxy, you can inform the
agent about the proxy during configuration. This allows your agent to
connect to Azure Pipelines or TFS through the proxy. This in turn
allows the agent to get sources and download artifacts.
So, you could refer to above document and configure the agent right to check again.
Besides, as workaround, we could disable the default built in artifact download task:
Then, we could run an export command and use the task Download Build Artifacts to download the artifact.
Hope this helps.
I was trying to run a custom script on my scaleset vm due to the wrong location of the sh file the exeuction failed. but after that when I try to remove (az vmss extension delete) or rerun(az vmss extension set ) the custom script with correct url I keep getting the same error. It is stuck. How do I fix it.
Deployment failed. Correlation ID:
249a034f-76e2-4b0d-beb2-e9c6577623d1. VM has reported a failure when
processing extension 'customScript'. Error message: "Enable failed:
processing file downloads failed: failed to download file[0]: failed
to download file: http request failed: Get
https://wrongurl.blob.core.windows.net/script/deploytemp.sh: dial tcp:
lookup wrongurl.blob.core.windows.net on 164.33.122.16:53: no such
host".
Delete the instance and rebuild it!
It might not be the answer to delete the instance and rebuilding it, but applications on VMSS by nature should be resilient enough to let you do so.
Also, I'm curious if auto-healing/remediation helps you on this, I know that it does not reinstall the extension tough.
Attempting to build my local openwhisk instance using the provided VagrantFile. I am using the ephemeral CouchDB container as my datasource.
During ant clean build deploy I get the following exceptions:
BUILD FAILED
/home/vagrant/openwhisk/build.xml:55: The following error occurred while executing this line:
/home/vagrant/openwhisk/build.xml:99: exec returned: 5
Further up the logs I see the following repeated under the installCatalog.sh section:
[exec] error: The supplied authentication is invalid
I've verified that the couchdb credentials in my cloudant-local.env are correct by executing some test curl commands. Not sure what other authentication credentials it could be complaining about. Any ideas?
http://dumptext.com/6QDOWNE3
When you use an ephemeral Couch instance, you need to start it after ant clean build and before deploy. Further, every time you start the container, you have to run the script tools/db/createImmortalDBs.sh to initialize the authentication store.
ant clean build
tools/db/couchdb/start-couchdb-box.sh ...
tools/db/createImmortalDBs.sh
ant deploy
BTW, Did you mean couchdb-local.env?
Im trying to use jenkins to build and deploy the war file to a tomcat present in different server and im getting the following error -
Deploying /var/lib/jenkins/jobs/ura_Web/workspace/ura-1.0.war to container Tomcat 6.x Remote
ERROR: Publisher hudson.plugins.deploy.DeployPublisher aborted due to exception
org.codehaus.cargo.container.ContainerException: Failed to redeploy [/var/lib/jenkins/jobs/ura_Web/workspace/ura-1.0.war]
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:195)
at hudson.plugins.deploy.CargoContainerAdapter.deploy(CargoContainerAdapter.java:64)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:90)
at hudson.plugins.deploy.CargoContainerAdapter$1.invoke(CargoContainerAdapter.java:77)
at hudson.FilePath.act(FilePath.java:905)
at hudson.FilePath.act(FilePath.java:878)
at hudson.plugins.deploy.CargoContainerAdapter.redeploy(CargoContainerAdapter.java:77)
at hudson.plugins.deploy.DeployPublisher.perform(DeployPublisher.java:47)
at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:804)
at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:776)
at hudson.maven.MavenModuleSetBuild$MavenModuleSetBuildExecution.post2(MavenModuleSetBuild.java:969)
at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:726)
at hudson.model.Run.execute(Run.java:1618)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:491)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:247)
Caused by: java.io.FileNotFoundException: http://192.168.2.X/manager/list
at sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1401)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.invoke(TomcatManager.java:504)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.list(TomcatManager.java:622)
at org.codehaus.cargo.container.tomcat.internal.TomcatManager.getStatus(TomcatManager.java:635)
at org.codehaus.cargo.container.tomcat.internal.AbstractTomcatManagerDeployer.redeploy(AbstractTomcatManagerDeployer.java:176)
... 16 more </code>
Can anyone tell me what is wrong?
I had exactly this problem just now and still have not solved it. However, I suspect it is happening because of proxy issues.
Is it possible to try setting the manager URL to http://localhost
rather than http://192.168.2.X? This worked for me, showing that the credentials were at least correct and the module functions. When I switch the manager URL back to a remote machine or the FQDN of the local server, it again failed. This indicates to me something proxy related.
The only trouble then is configuring the proxy settings for Jenkins, especially http.nonProxyHosts. If you can do that maybe you'll have more luck than me. I cannot get the Jenkins System Information proxy values to change no matter what I do!
Also manually test from a browser on both the build server and elsewhere your access to the manager URL: http://192.168.2.X/manager/list