3

Converting a pipeline from classic to YAML (so I know it works).

I build and my publish artifact task looks like this:

 - task: PublishPipelineArtifact@1 displayName: 'Publish Pipeline Artifact' inputs: targetPath: '$(Build.ArtifactStagingDirectory)/MyArtifact' artifact: MyArtifact

The result when build looks like this:

enter image description here

I then want to deploy this to a webapp YAML:

- stage: Dev jobs: - job: DeployApp displayName: Deploy Web App pool: name: myPrivate demands: msbuild steps: - task: DownloadPipelineArtifact@2 inputs: artifact: MyArtifact - task: AzureRmWebAppDeployment@4 displayName: 'Deploy App' inputs: WebAppKind: 'Web App On Windows' azureSubscription: 'edited out...' WebAppName: webAppName package: '$(System.ArtifactsDirectory)' enableXmlTransform: true

Which results in this output in Azure DevOps:

enter image description here

A difference in chunks but since size match very exactly I'm happy.

I then get error on the deployment so I started look in Kudo and can see that in SitePackages all my packages are 1 kb (or empty...). I expected 61.2 MB.

enter image description here

I took my working classic deployment, and there i had this row:

packageForLinux:'$(System.DefaultWorkingDirectory)/_MyArtifact/MyArtifact/MyApplication.zip'

But that path wasn't even found. And packageForLinux felt wrong but doesn't matter as I understand it.

So can someone please me in the right direction how to deploy a web app (on windows) using YAML?

Improve this question
2
  • The folder that's used is $(Pipeline.Workspace), not $(System.DefaultWorkingDirectory), the default folder is different for different tasks, so you can't always trust they extract to the default working directory. Commented Jun 28, 2019 at 11:07
  • 2
    @jessehouwing thank you very much! That was exactly it. Commented Jun 28, 2019 at 12:30

2 Answers 2

Reset to default
5

The folder that's used is $(Pipeline.Workspace), not $(System.DefaultWorkingDirectory), the default folder is different for each task type, so you can't always trust they extract to the default working directory.

Improve this answer
Sign up to request clarification or add additional context in comments.

Comments

1

I've wasted a lot of time deciphering these folder paths. I'm adding this info to help anyone else with this issue. Obviously my artifact was empty because my staging folder was empty.

After a few hours of digging I discovered that $(Build.SourcesDirectory) represents the root of where my dacpac files are built to

In my case I'm using the CopyFiles task as it supports wildcards. So whatever dacpac files are generated under the bin subfolder will be picked up and copied to the artifacts staging directory

# Build and publish the database solution trigger: - master # this builds on a self hosted pool rather than the MS cloud agent pool: name: MySelfHostedPool demands: - MSBuild - SqlPackage steps: - task: MSBuild@1 displayName: Build DB solution inputs: solution: MemberDB.sln logFileVerbosity: diagnostic # Copy build output to artifact staging directory so they can be published as artifacts in the next step - task: CopyFiles@2 displayName: Copy dacpac to artifacts staging inputs: SourceFolder: '$(Build.SourcesDirectory)' flattenFolders: true Contents: '**\bin\**\*.dacpac' TargetFolder: '$(Build.ArtifactStagingDirectory)' - task: PublishPipelineArtifact@1 displayName: Publish dacpac inputs: artifactname: 'drop' targetPath: $(Build.ArtifactStagingDirectory)
Improve this answer

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.