I've built a Code Pipeline (Source > Build > Deploy) and it's failing on the deploy step.
It's a Net Core 3.1 Api project.
I check the elastic beanstalk logs and I see:
2020/07/02 14:14:00.600060 [ERROR] An error occurred during execution of command [app-deploy] - [CheckProcfileForDotNetCoreApplication]. Stop running the command. Error: error stat /var/app/staging/MyApi/MyApi.dll: no such file or directory with file /var/app/staging/MyApi/MyApi.dll
As far as I know I have no control over /var/app/staging/ and this is built in AWS stuff?
The build step is working so I am unsure on this error.
My buildspec.yml is:
version: 0.2
phases:
build:
commands:
- dotnet publish -c release -o ./build_output ./MyApi/MyApi.csproj
artifacts:
files:
- '**/*'
base-directory: 'build_output'
This is the "zipfile/build_output" folder:
This is the zip file root folder:
These are the files in the build artifacts zip file that pipeline is using. The error says it cannot find MyAppName.dll (renamed to MyApi in the pic). It's there so I wonder why the problem.
Perhaps it doesnt like the folder structure in the zip file - see pic.
I had the same problem.
In my case, if the solution name and project name were different, I got the same error when I deployed the code from Visual Studio to Beanstalk, but when I added a project with the same name as the solution name and built it, I didn't get an error.
I suspect that there will be behavior during deployment that assumes the .dll file has the same name as the solution name.
Warning: This is a workaround, not a solution!
On the project that's failing to deploy, change the "Assembly name" in Project Properties / Application tab, to the name of the DLL it's missing (typically the solution name or the first period-separated part of the namespace).
i.e. "SLNNAME"
Then, redeploy your beanstalk app and it should work.
As Marcin correctly noticed, the indentation was incorrect for the "base-directory"
base-directory: 'build_output'
Should be
base-directory: 'build_output'
As others have noted, it is looking for only the first part of your project name .dll. In my case, my project and Assembly name were both UC.Web which yielded the error during deployment:
Error: error stat /var/app/staging/UC.dll: no such file or directory with file /var/app/staging/UC.dll
My solution that worked was I renamed my Assembly name from UC.Web to simply UC and it deployed successfully. While a solution for everyone, it is a workaround for the time being until Amazon fixes this.
Related
I would like to follow tensorflow example to build generate_streaming_test_wav to generate test wav. And my bazel version is 0.16.1.
The problem is when I use command bazel run tensorflow/examples/speech_commands:generate_streaming_test_wav
, the following error message shown up:
xxx#xxx:~/kws/tensorflow-0911$ bazel run tensorflow/examples/speech_commands:generate_streaming_test_wav
Starting local Bazel server and connecting to it...
ERROR: error loading package '': Encountered error while reading extension file 'closure/defs.bzl': no such package '#io_bazel_rules_closure//closure': Error downloading [https://mirror.bazel.build/github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz, https://github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz] to /home/janet/.cache/bazel/_bazel_janet/2d14dc1ff5782da202e00efcc3cd86bc/external/io_bazel_rules_closure/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz: All mirrors are down: []
ERROR: error loading package '': Encountered error while reading extension file 'closure/defs.bzl': no such package '#io_bazel_rules_closure//closure': Error downloading [https://mirror.bazel.build/github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz, https://github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz] to /home/janet/.cache/bazel/_bazel_janet/2d14dc1ff5782da202e00efcc3cd86bc/external/io_bazel_rules_closure/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz: All mirrors are down: []
INFO: Elapsed time: 57.573s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)
FAILED: Build did NOT complete successfully (0 packages loaded)
However, I can use wget download those two packages.
1.https://mirror.bazel.build/github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz 2.https://github.com/bazelbuild/rules_closure/archive/dbb96841cc0a5fb2664c37822803b06dab20c7d1.tar.gz
I think my network should be fine. I have no idea why it can't download those files.
Any idea or suggestions would be very appreciated!
If you know your proxy server, you should be able to set:
export HTTPS_PROXY=http://me:mypassword#myproxyserver.domain.com:myport
export HTTP_PROXY=http://me:mypassword#myproxyserver.domain.com:myport
and run the bazel build again.
If you don't know the proxy server used by wget check /etc/wgetrc or ~/.wgetrc
I've seen conflicting statements about HTTPS_PROXY and HTTP_PROXY being uppercase and lowercase, so you might try setting both. (Some have used unset to remove the lowercase settings. See: https://github.com/bazelbuild/bazel/issues/587#issuecomment-412531604)
create a folder say 'dist'.
Now whatever URL bazel is not able to download .
do wget inside that folder. ( wget normally works with most of proxy)
then run
'bazel build ...... --distdir dist'
it will take packages from dist and compilation will do start.
This might be a bug in Bazel's repository rules. If you'd be so kind to file a bug, that'd be great!
As a workaround, extract the downloaded archive somewhere and replace the io_bazel_rules_closure rule in the WORKSPACE file with a local_repository rule pointing to the directory where you extracted the archive.
I'm trying to publish a relatively new ASP.NET site to azure appservice from Visual Studio.
I'm getting the following error message during the preview:
The "Dnu" task failed unexpectedly.
System.Exception:
Microsoft .NET Development Utility Clr-x86-1.0.0-rc1-16231
Copying to output path C:\Users*****\AppData\Local\Temp\PublishTemp*****************.********.WebApi114
Error: The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
at Microsoft.DNX.Tasks.Dnu.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext()
Path is long indeed. How do I fix it?
Error is from windows file API, not control by Azure App Service. Sadly I think you will have to find a way to shorter your file path in order to fix this issue.
I was running into the same issue trying to build an Angular2 app locally. So I tend to agree with Xiaomin that it may be a local issue. What worked for me was to run the dnu publish command from a command prompt with the output flag set with a shorter folder destination provided. For example, navigate to the location of the project you want to publish in a command prompt and type:
"dnu publish --runtime active -o c:\Sample"
The above command will post your output to c:\Sample.
You can interrogate the options as follows:
"dnu -help"
"dnu publish -help"
By default TFS Build creates a "Index Sources & Publish Symbols" step in a Visual Studio Build definition. When the step's property "Path to publish symbols" is empty, everything works fine. But when setting the path to a local directory, the step generates the following error:
2015-09-25T11:00:09.7991491Z Executing the powershell script: C:\NewAgent\tasks\PublishSymbols\1.0.4\PublishSymbols.ps1
2015-09-25T11:00:10.0022755Z Find-Files -SearchPattern **\bin\**\*.pdb -RootFolder C:\NewAgent\_work\990dcb3f\Projects
2015-09-25T11:00:10.0491548Z Found 15 files to index...
2015-09-25T11:00:10.0491548Z Invoke-IndexSources -RepositoryEndpoint <repositoryEndpoint> -SourceFolder C:\NewAgent\_work\990dcb3f\Projects -PdbFiles <pdbFiles>
2015-09-25T11:00:10.6272794Z Invoke-PublishSymbols -PdbFiles <pdbFiles> -Share C:\DebugSymbols -Product EntityMapper -Version 20150925.14 -MaximumWaitTime 7200000 -MaximumSemaphoreAge 1440 -ArtifactName
2015-09-25T11:00:10.7348541Z ##[error]Can't infer artifact type from artifact location C:\DebugSymbols.
2015-09-25T11:00:10.7504779Z
2015-09-25T11:00:10.7504779Z Start: AssociateArtifact
2015-09-25T11:00:10.7504779Z ##[error]Artifact Type is required.
2015-09-25T11:00:10.7504779Z End: AssociateArtifact
The pdb files are published to the specified directory, so i don't really understand what is causing the error (which then causes the whole build job to fail).
When the step's property "Path to publish symbols" is empty, everything works fine.
Yes, because if symbols path is not set, the script only index sources, not publishing symbols.
But when setting the path to a local directory, the step generates the error
You need prepare your symbol store. In your case setup folder sharing and permissions.
In my case changing the "Path to publish symbols" from
//myserver/symbols
to
\\myserver\symbols
solved the issue. Don't know why this happend to me but ok... :)
When running the top level maven target
test
I get the following error:
FATAL: command execution failed
java.io.IOException: Cannot run program "mvn" (in directory "/var/lib/jenkins /jobs/selenium/workspace"): java.io.IOException: error=2, No such file or directory
at java.lang.ProcessBuilder.start(ProcessBuilder.java:475)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:709)
at hudson.Launcher$ProcStarter.start(Launcher.java:338)
at hudson.Launcher$ProcStarter.join(Launcher.java:345)
at hudson.tasks.Maven.perform(Maven.java:263)
at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19)
at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717)
at hudson.model.Build$BuildExecution.build(Build.java:199)
at hudson.model.Build$BuildExecution.doRun(Build.java:160)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499)
at hudson.model.Run.execute(Run.java:1502)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: java.io.IOException: java.io.IOException: error=2, No such file or directory
at java.lang.UNIXProcess.<init>(UNIXProcess.java:164)
at java.lang.ProcessImpl.start(ProcessImpl.java:81)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:468)
... 15 more
Build step 'Invoke top-level Maven targets' marked build as failure
This seems to be an issue concerning the maven pathway, but I've setup the maven pathway on my host machine. M2_HOME, M2, and PATH are all correct. I know they are correct because I can run the maven commands from the command line. When I try to invoke maven commands in jenkins though I get the error.
So I went into Jenkins->Manage Jenkins->Configure System and I clicked on Maven installations...
I checked off on
Install automatically
Version 2.2.1
I clicked save and tried to run my project again with the same error. When I do mvn -version I get 2.2.1 so that should be right.
From the Configure System page I have also tried
Name default
MAVEN_HOME /usr/local/apache-maven/apache-maven-2.2.1
Any ideas?
The solution to my question has two parts. First I needed to make sure that after creating the maven Installation setup on the Configure System page, that I specified that same configuration in the build itself. Second Jenkins does not seem to have sufficient privileges on the redhat box I'm running it on. Once I finally got it pointed to the right maven instance I got a lot of unable to create file/folder errors. These permission errors could be the real reason I had so much trouble with maven on this machine. I have not solved these permission errors and will create a new question for them.
I am trying to retrieve Build Projects related information from my CruiseControl server through command line using cccmd.exe and passing the url and project name as command line arguments. The problem is when I am trying to use API's exposed by Cruise Control Service like
client.GetArtifactDirectory(project.Name);
client.GetLatestBuildName(project.Name);
I am getting the exception "The project does not exists on the CCNet Server" for my local CCNet Server.
For my production build server, I am getting the exception "Key cannot be null".
Finally found the solution, had to copy the folders and foldername.state files that are created during project build process to the directory from where ccservice.exe was running.