I'm trying to release new version on a test projet but my artifact is not recognised.
Discovering tests...OK
Deploying using GitHub provider
Creating "a2" release for repository "Phonations/TravisTest" tag "a2" commit "44d044aa7708508f016dfef67fbdd82f08642f8d"...OK
No artifacts were published. Make sure you have specified correct artifacts filter.
Build success
(full output available here)
I checked the artifact artifact.txt is present as you can see when performing the dir command in the build output.
It is specified here
You should setup artifacts packaging in appveyor.yml. For that file in your project this would be:
artifacts:
- path: artifact.txt
Related
I'm trying to set up my first pipeline to deploy a web app to an Azure App service. I am able to manually publish the site via Visual Studio but now I am trying to get it build and deploy from an Azure Repo. The build part works fine and without errors. The problem comes in when I add in the deploy task. The deploy task doesn't seem to be able to find the file/s to deploy.
My Pipeline
My Publish config:
In my Pipeline the Publish section shows the following debug info:
##[debug]Exit code 0 received from tool 'C:\Program Files\dotnet\dotnet.exe'
##[debug]STDIO streams have closed for tool 'C:\Program Files\dotnet\dotnet.exe'
##[debug]modifyOutputPath=true
##[debug]Zip Source: D:\a\1\a\s
##[debug]Zip arguments: Source: D:\a\1\a\s , target: D:\a\1\a\s.zip
##[debug]Successfully created archive D:\a\1\a\s.zip
##[debug]rm -rf D:\a\1\a\s
##[debug]removing directory D:\a\1\a\s
The Publish Artifact config section:
The Publish Artifact section shows the following success message:
File upload succeed.
Upload 'D:\a\1\a' to file container: '#/10370704/drop'
Associated artifact 541 with build 667
The Web Deployment config looks like this:
Then the Azure Web App Deployment shows the following debug and error message:
##[debug]pattern: 'D:\a\1\s**.zip'
##[debug]expanding braces
##[debug]pattern: 'D:/a/1/s/**/.zip'
##[debug]applying include pattern against original list
##[debug]0 matches
##[debug]0 final results
##[debug]No matching files were found with search pattern: D:\a\1\s**.zip
##[debug]Deployment Failed with Error: Error: No package found with specified pattern:
D:\a\1\s**.zipCheck if the package mentioned in the task is published as an artifact in the build or a previous stage and downloaded in the current job.
##[debug]task result: Failed
##[error]Error: No package found with specified pattern: D:\a\1\s***.zip
You can try to use powershell task to list the files in the folder before publish the Azure Web App.
From your description, it seems the pattern should be $(Build.ArtifactStagingDirectory)/*.zip?
I have a project containing both Javascript and Typescript files. I'm using SonarCloud to analyse this project from an Azure DevOps pipeline.
I set the task Prepare Analysis Configuration in my build pipeline like this:
- task: SonarCloudPrepare#1
inputs:
SonarCloud: 'Sonarcloud'
organization: 'MyOrg'
scannerMode: 'CLI'
configMode: 'manual'
cliProjectKey: 'My key'
cliProjectName: 'My name'
cliSources: '.'
When running the pipeline, I have the following error in my pipeline on Sonar Cloud Analyze step
INFO: Found 1 tsconfig.json file(s): [/home/vsts/work/1/s/tsconfig.json]
##[error]ERROR: Cannot find module 'typescript'
##[error]ERROR: TypeScript dependency was not found and it is required for analysis.
ERROR: Install TypeScript in the project directory or use NODE_PATH env. variable to set TypeScript location, if it's located outside of project directory.
ERROR: TypeScript dependency was not found and it is required for analysis.
ERROR: Install TypeScript in the project directory or use NODE_PATH env. variable to set TypeScript location, if it's located outside of project directory.
##[error]ERROR: Missing TypeScript dependency
The analysis works well for javascript files but not for typescript files. I have the typescript package installed as dev dependency in my package.json but it seems it is ignored by SonarCloud.
The documentation and topics I found are related to SonarQube version but I can't figure out how to setup this with SonarCloud.
By default, node_modules folder in local project folder won't be added into source control if you're using Visual Studio.
And this error would occur since Run Code Analysis task can't find the dependency packages defined in your package.json file. My reproducible step:
Then I add one npm install task before Prepare Analysis task to install missing packages:
NodeJS is my project name. Also in Devops repos, this is the name of the folder where package.json exists.
Then this issue went away in my pipeline:
Hope it also helps for your issue :)
In addition: You can also choose to add local node_modules folder into source control if you want. But this is not recommended in Azure Devops Service.
I'm busy deploying a .NET Core 2.1 application into our testing environment, but I'm getting the following error.
Error:
An assembly specified in the application dependencies manifest (MyApp.deps.json) was not found:
package: 'System.Diagnostics.EventLog', version: '4.5.0'
path: 'runtimes/win/lib/netcoreapp2.1/System.Diagnostics.EventLog.dll'
We are using the Windows Compatibility Pack to access the Event Log.
I have the following item in the dependency Json file:
"System.Diagnostics.EventLog/4.5.0": {
"dependencies": {
"Microsoft.Win32.Registry": "4.5.0",
"System.Security.Permissions": "4.5.0",
"System.Security.Principal.Windows": "4.5.0",
"System.Threading.AccessControl": "4.5.0"
},
"runtime": {
"lib/netstandard2.0/System.Diagnostics.EventLog.dll": {
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
},
"runtimeTargets": {
"runtimes/win/lib/netcoreapp2.0/System.Diagnostics.EventLog.dll": {
"rid": "win",
"assetType": "runtime",
"assemblyVersion": "4.0.0.0",
"fileVersion": "4.6.26515.6"
}
}
}
Please advise how one should deploy these dependencies. Also, what is the root folder to this relative path runtimes/win/lib/netcoreapp2.0?
We actually found a solution for our scenario:
- Our situation was that we tried to run a netcoreapp based test project on our test agent
- dotnet test on the project file worked
- dotnet vstest sometimes worked on the project output directory (we are not sure why and on which setup)
- dotnet vstest did run into the above error when run into an other directory & downloaded from CI
- dotnet vstest did run into an AssemblyNotFoundException on the test agent (which didn't make any sense for us)
The solution was to use dotnet publish for our test project and use the "self-contained" output to run on the test agent. dotnet publish copied the required runtimes/win/lib/netcoreappX.X/*.dll files into the publish output directory.
After a lot of testing, the key issue seems to be the "RuntimeIdentifiers". There is a visible option for this when you publish, but in order to use it when just building you need to add a couple of tags to your .csproj file.
The first is:
<RuntimeIdentifier>win-x86</RuntimeIdentifier>
This will cause NuGet to retrieve the correct dlls (change the value depending on your needs). For me I was compiling to platform x86. I don't know what NuGet was getting by default, but whatever it was had different file sizes for the same files.
You also should then add this tag:
<SelfContained>false</SelfContained>
or else your build will default to copying the entire framework.
Also note that using the RuntimeIdentifier tag will cause your default output folder to include the value you specified. For example my subfolder became:
Project\bin\x86\Debug\netcoreapp3.1\win-86\
For publishing you should be able to do something similar; the problem will be to match your RuntimeIdentifier to your platform. You shouldn't need to specify SelfContained unless you specifically need to.
For awhile in my Team City build, I am unable to publish my source NuGet packages to symbolsource.org as it responds with 500 Internal Server Error.
[16:02:36][push] Pushing NCode.Composition.DisposableParts 1.0.1 to the symbol server (http://nuget.gw.symbolsource.org/Public/NuGet)...
[16:04:18][push] Failed to process request. 'Internal Server Error'.
[16:04:18][push] The remote server returned an error: (500) Internal Server Error..
[16:04:18][push] Process exited with code 1
I am able to publish my normal packages to NuGet.org just fine. I believe that I have properly configured everything as documented by symbol source.
https://www.symbolsource.org/MyGet/Wiki/Publishing
http://www.symbolsource.org/Public/Metadata/NuGet
https://www.symbolsource.org/Public/Account/Register
Here is my Build Step configuration for NuGet Publish:
Runner Type: NuGet Publish
NuGet.exe: Default 2.8.6
Packages: *.nupkg
API Key: (my personal API key from NuGet.org)
Package Source: (blank)
In my build output directory and artifacts recognized by TeamCity, I do have both of my packages in there:
NCode.Composition.DisposableParts.1.0.1.nupkg
NCode.Composition.DisposableParts.1.0.1.symbols.nupkg
Any assistance would be appreciated!
I think that the problem is with two packages with the same name. Did you try a workaround with another build configuration and snapshot dependency?
I'm using another build configuration with snapshot dependency to build which produces *.nupkg and *.symbol.nupkg. Artifact dependency is set to:
-:*.nupkg => <replace with location>
+:*.symbol.nupkg
The build configuration only publishes *.symbol.nupkg to symbolsource.org.
When you deploy an artifact to Artifactory over an existing artifact, it does not associate it with the build that the existing artifact has.
For example: If you used the Jenkins Artifactory Plugin to deploy three artifacts:
example.jar
example.pom
example.json
Then it would create a new build, associate these artifacts with that build, and deploy the artifacts to the location and repo you specified.
Let's say this deployed to /libs-release-local/example/1.0/ with buildName "example-build" and buildNumber 51
If you looked at the artifacts, you will see on the build tab that it is associated with the build-info.json.
Now, let's say you deploy example.json using the REST API to the same location:
PUT /libs-release-local/example/1.0/example.json
Now the new artifact is not associated with the build-info.json!
How can I deploy the artifact so that it is associated with an already existing build-info.json? (in this example, the "/example-build/51" build).
Not being able to do this causes all sorts of issues (such as when build_promotion is done, it promotes only the previously associated artifacts, and not anything deployed later.)
Artifactory associates the Build Info descriptor with the build artifacts artifacts based on their checksum.
If you look at the JSON which is the Build Info descriptor, you'll be able to see:
{
...
"modules" : [ {
"id" : "org._10ne.gradle:rest-gradle-plugin:0.2.0",
"artifacts" : [ {
"type" : "pom",
"sha1" : "f0dcec6a603aa99f31990e20c0f314749f0e22ca",
"md5" : "427dcf49c07cc7be175ea31fd92da44e",
"name" : "rest-gradle-plugin-0.2.0.pom"
},
....
}
}
A Build Info descriptor describes a "build" which is essentially a single unit of module/s produced by a certain process; this process depends on a specific environment.
You're deploying a new artifact which was not part of the original process or environment that the Build Info describes; if it was, it would have been produced with the exact same checksum as the former artifact
You are basically compromising the integrity of the "build" unit.
The "right" way to do it would be to start a new build process and produce a valid Build Info descriptor.