Publish build artifact from folder without including root folder - continuous-integration

On Azure DevOps, I have some files I want to publish:
$(Build.ArtifactStagingDirectory)/dist/app/index.html
$(Build.ArtifactStagingDirectory)/dist/app/bundle.js
I want to publish them into an artifact app.zip which contains, at the root level:
- index.html
- bundle.js
However when I use the "Publish Build Artifacts" tasks with the path set to $(Build.ArtifactStagingDirectory)/dist/app, I get the following contents in app.zip:
app/
index.html
bundle.js
I tried setting the publish path to:
$(Build.ArtifactStagingDirectory)/dist/app/**
$(Build.ArtifactStagingDirectory)/dist/app/*
$(Build.ArtifactStagingDirectory)/dist/app/*.*
but all of these fail the build with the error Not found PathtoPublish

if I understand your question , you trying to publish 2 files as your atficats.
as you are already ready with app.zip
may be first retry copying it to another staging folder and then try to copy it from there. or see the below pattern to traverse through the directories.
then you need
- task: PublishBuildArtifacts
inputs:
pathtoPublish: $(Build.ArtifactStagingDirectory)/**/*
artifactName: MyBuildOutputs
Cheers.
AJ

Related

Deploy a specific project to NuGet with a matrix configuration

My appveyor.yml looks like below:
environment:
matrix:
- solution_name: Src/App1.sln
- solution_name: Src/App2.sln
before_build:
- cmd: dotnet restore %solution_name%
build:
project: '%solution_name%'
publish_nuget: true
after_build:
- dotnet pack Src\App1.csproj
deploy:
- provider: NuGet
api_key:
secure: [my api key]
on:
branch: master
artifact: /.*(\.|\.s)nupkg/
artifacts:
- path: Out\
name: App1
- path: '**\*.nupkg'
It works well with one catch: it seems deploy twice during the build process. Below is part of the AppVeyor log:
Collecting artifacts...
Found artifact 'Out' matching 'Out' path
Found artifact 'Out\App1\Release\App1.6.0.3.nupkg' matching '**\*.nupkg' path
Uploading artifacts...
[1/2] App1.6.0.3.nupkg (164,127 bytes)...100%
[2/2] Out\App1\Release\App1.6.0.3.nupkg (164,127 bytes)...100%
Deploying using NuGet provider
Publishing App1.6.0.3.nupkg to https://www.nuget.org/api/v2/package...OK
Publishing App1.6.0.3.nupkg to https://www.nuget.org/api/v2/package...Skipped (A package with ID 'App1' and version '6.0.3' already exists and cannot be modified.)
No packages were pushed.
So I login NuGet.org and I can see App1.6.0.3 is published successfull. However, in the above log, the same package is published twice, hence the second publish is skipped, and end up with message "No packages we pushed." But actually there was one package pushed.
Maybe it is because I have a matrix configuration under environment section, so AppVeyor runs deploy twice? If so, how can tell AppVeyor to deploy only once?
After some experiments, I found a fix, that is removing publish_nuget: true under build section. This line will cause AppVeyor to create a nuget package, and dotnet pack Src\App1.csproj command under after_build section will create a nuget package, too. So there will be two identical .nupkg files generated in different location, and AppVeyor will find both files and push them to nuget server.
Result:
build:
project: '%solution_name%'
after_build:
- dotnet pack Src\App1.csproj

How to do dotnet publish in Build Yaml

Can you please give an example the way to specify in build.yaml if needs to do dotnet publish a test project in .Net Core 2.1. referred this couldn't figure out exactly the way.
It says below, what should be the yaml way
For this task to work, you must have already published the output of your build to this directory by using the dotnet publish --output $(Build.ArtifactStagingDirectory) command. To copy additional files to this directory before publishing,
As example how below represent in build.yaml in class application (API Solution)
dotnet publish ~/projects/app1/app1.csproj
Tried below
- task: DotNetCoreCLI#2
displayName: "Prepare Publish Files"
inputs:
command: publish
projects: ""
arguments: --output $(Build.ArtifactStagingDirectory)/src/xxx.EndToEnd.Integration.Tests/xxx.EndToEnd.Integration.Tests.csproj
But get below error, in fact mine is API solution where I am trying to publish end2end tests and run them after deployment.
##[error]No web project was found in the repository. Web projects are identified by presence of either a web.config file or wwwroot folder in the directory.
##[error]Project file(s) matching the specified pattern were not found.
With below YAML code I was able to run the build
- task: DotNetCoreCLI#2
displayName: "dotnet e2e tests"
inputs:
command: publish
publishWebProjects: false
projects: '**/*.csproj'
arguments: --output $(Build.ArtifactStagingDirectory)/src/xxx.EndToEnd.Integration.Tests
zipAfterPublish: false
Explanation:
publishWebProjects: false - Since this is a API solution.
The easy way is to create task in designer wizard and see the YAML file there (Separate tab to show yaml file)

Appveyor builds for all branches instead of specified ones

We have currently three separated appveyor projects, one for each branch in our repository.
Our problem is follwing:
Appveyor ignores my filter on github branches. Everytime we make a commit to master, stage or dev it builds on all three projects instead of the single one we did make a commit to.
Each branch has a unique appveyor.yml file looking like this:
This is the appveyor.yml for dev
version: 0.0.{build}
branches:
only:
- dev
image: Visual Studio 2017
configuration: dev
before_build:
- nuget restore
build:
project: Core.Api.sln
publish_wap: true
verbosity: minimal
build_script:
- ps: .\build.ps1
after_build:
- cmd: dotnet publish src\Core.Api --output %appveyor_build_folder%\dist
test: off
artifacts:
- path: dist
name: dist.web
deploy:
...
When we make a commit, it builds on all projects. Any idea??
This happens because each project has Webhook configured on GitHub and each time someone makes a commit, each project build is triggered by webhook. Then, regardless of what branch is configured for project (that is only default branch for manual/API builds), AppVeyor reads appveyor.yml from the branch where commit was done.
Solution is to use either alternative YAML file names or alternative YAML file location.
With alternative YAML file names you can have something like appveyor-dev.yml, appveyor-stage.yml files and set specific AppVeyor project to use specific file. With alternative YAML file location is it basically the same, but in other location than repo. I personally like alternative YAML file location more because of less duplication and potential merging issues.
In both cases when webhook in say branch dev come to stage project, it still will read appveyor-dev.yml and do the right filtering.

How to specify wildcard artifacts subdirectories in .gitlab-ci.yml?

I'm using GitLab CI to build a C# solution and try to pass some build artifacts from one build stage to another.
The problem is, that the artifacts are not located in a single directory but in different subdirectories, which however all have the same names bin/ or obj/.
My .gitlab-ci.yml looks like the following:
...
stages:
- build
- test
build:
stage: build
script:
CALL %MSBuild% ...
artifacts:
paths:
- /**/bin/
- /**/obj/
expire_in: 6 hrs
test:
stage: test
dependencies:
- build
...
I tried to capture the artifacts using different ways, e.g.
**/bin/
**/obj/
(invalid syntax), or
.*/bin/
.*/obj/
but that one did not find any artifacts, just as /**/bin/ and /**/obj/, giving me following errors:
Uploading artifacts...
WARNING: /**/bin/: no matching files
WARNING: /**/obj/: no matching files
How can I specify a subdirectory pattern to be scanned for artifacts? Or is this even possible at all?
Simply using
artifacts:
untracked: true
is not an option, because of a huge untracked packages/ subdirectory, which causes artifacts upload to fail because of a too large archive:
Uploading artifacts...
untracked: found 4513 files
ERROR: Uploading artifacts to coordinator... too large archive id=36 responseStatus=413 Request Entity Too Large token=...
FATAL: Too large
The gitlab-ci-multi-runner build runner is built using Go and currently uses filepath.Glob() to scan for any specified artifacts in file_archiver.go.
Go doesn't seem to support the double star glob expression as discussed in another question here at SO. So there seem to be no way to use a full-featured **/bin expression at the moment.
Because however all my projects are located at the same level below the solution root, it is still possible to use something like
artifacts:
paths:
- "*/bin"
- "*/obj"
Note that the quotes (") seem to be required, as well as no trailing path separator at the end.
It should also be possible to explicitly add more levels by adding more globbing expressions (as described here):
paths:
...
- "*/obj"
- "*/*/bin"
- "*/*/obj"
...
GitLab is tracking this issue here, and will possibly be fixed in a future version.
UPD: due to mentioned issue is closed and due to documentation, since GitLab runner 13.0 it supports doublestar.Glob.
So it is now possible to write something like this:
paths:
- "**/bin"
- "**/obj"
And it will include all nested directories with names bin and obj in artifacts

Create a Deployment Package to folder TeamCity

I currently have Team City set up on a server that does:
1) Build the Project
2) Run unit tests
3) Publish the project through IIS if successful
I want to add another step so that a .zip file is produced consisting of what was deployed to a directory on the server running team city. I am to understand that this is possible through artefacts but everything I've tried so far hasn't worked to give me the publish output.
I've tried options such as "** => C:\TC\Test.zip" but that includes the actual code implementation files.
Is there a way in which to publish a zip containing the publish result?
I've been trying this for hours without luck so far so hopefully I can get an answer.
You can use this to zip all files relative to the root of the build:
**/* => artifacts.zip
To zip all files relative to a folder named publish:
publish/**/* => artifacts.zip
If your published files are not included in the zip, they may have been published to someplace outside of the root of the build.

Resources