CODEWITHSUNDEEP
azure-devopsazure-pipelines
RHarris
RHarris

Reputation: 11167

How do I build different projects in the same repo with Azure Pipelines

I'm new to Azure Pipelines. I have a repo in Azure DevOps that includes a Web API project, a background service and a bunch of common libraries. I'm trying to create two Pipelines to produce two different drops -- one for the API and one for the service. I don't want the code in the service drop to include any of the web api stuff and visa versa.

In my pipeline parameters, I have the specific project of either the api or the service referenced (i.e. ProjectName/*.csproj).

That is what is used for Restore, Build, etc. However, when I run either of the pipelines, I get the same result -- they both include everything in the repo. IOW, my background service project (which has no reference to the api) winds up with all the web api controllers, the web.config, etc.

Is it possible to accomplish what I'm after?

YAML API Pipeline

variables:
- name: BuildParameters.RestoreBuildProjects
  value: MyAPI/*.csproj
- name: BuildParameters.TestProjects
  value: MyAPI/*[Tt]ests/*.csproj
name: $(date:yyyyMMdd)$(rev:.r)
jobs:
- job: Job_1
  displayName: Agent job 1
  pool:
    name: Azure Pipelines
  steps:
  - checkout: self
    fetchDepth: 1
  - task: DotNetCoreCLI@2
    displayName: Restore
    inputs:
      command: restore
      projects: $(BuildParameters.RestoreBuildProjects)
  - task: DotNetCoreCLI@2
    displayName: Build
    inputs:
      projects: $(BuildParameters.RestoreBuildProjects)
      arguments: --configuration $(BuildConfiguration)
  - task: DotNetCoreCLI@2
    displayName: Test
    inputs:
      command: test
      projects: $(BuildParameters.TestProjects)
      arguments: --configuration $(BuildConfiguration)
  - task: DotNetCoreCLI@2
    displayName: Publish
    inputs:
      command: publish
      publishWebProjects: True
      projects: $(BuildParameters.RestoreBuildProjects)
      arguments: --configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)
      zipAfterPublish: True
  - task: PublishBuildArtifacts@1
    displayName: Publish Artifact
    condition: succeededOrFailed()
    inputs:
      PathtoPublish: $(build.artifactstagingdirectory)
      TargetPath: '\\my\share\$(Build.DefinitionName)\$(Build.BuildNumber)'
...

YAML Backgroun Service Pipeline

variables:
- name: BuildParameters.RestoreBuildProjects
  value: MyServices/*.csproj
- name: BuildParameters.TestProjects
  value: MyServices/*[Tt]ests/*.csproj
name: $(date:yyyyMMdd)$(rev:.r)
jobs:
- job: Job_1
  displayName: Agent job 1
  pool:
    name: Azure Pipelines
  steps:
  - checkout: self
    fetchDepth: 1
  - task: DotNetCoreCLI@2
    displayName: Restore
    inputs:
      command: restore
      projects: $(BuildParameters.RestoreBuildProjects)
  - task: DotNetCoreCLI@2
    displayName: Build
    inputs:
      projects: $(BuildParameters.RestoreBuildProjects)
      arguments: --configuration $(BuildConfiguration)
      workingDirectory: MyServices
  - task: DotNetCoreCLI@2
    displayName: Test
    inputs:
      command: test
      projects: $(BuildParameters.TestProjects)
      arguments: --configuration $(BuildConfiguration)
  - task: DotNetCoreCLI@2
    displayName: Publish
    inputs:
      command: publish
      publishWebProjects: True
      projects: $(BuildParameters.RestoreBuildProjects)
      arguments: --configuration $(BuildConfiguration) --output $(build.artifactstagingdirectory)
      zipAfterPublish: True
      workingDirectory: MyServices
  - task: PublishBuildArtifacts@1
    displayName: Publish Artifact
    condition: succeededOrFailed()
    inputs:
      PathtoPublish: $(build.artifactstagingdirectory)
      ArtifactName: service-drop
      TargetPath: '\\my\share\$(Build.DefinitionName)\$(Build.BuildNumber)'
...

Upvotes: 2

Views: 2017

Answers (2)

RHarris
RHarris

Reputation: 11167

It turns out I had the Publish Web Projects flag checked in the publish options. By unchecking that option, I was able to create a build of my services!

Upvotes: 0

FFFffff
FFFffff

Reputation: 1045

I think you only need to specify PathtoPublish parameter in the PublishBuildArtifacts@1 task.

It could look something like this (added "\myAPI\build\release"):

  - task: PublishBuildArtifacts@1
    displayName: Publish Artifact
    condition: succeededOrFailed()
    inputs:
      PathtoPublish: '$(build.artifactstagingdirectory)\myAPI\build\release'
      ArtifactName: service-drop
      TargetPath: '\\my\share\$(Build.DefinitionName)\$(Build.BuildNumber)'

If you're not sure what's the path, just inspect the output artifact of the last run.

Link to docs: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/publish-build-artifacts-v1?view=azure-pipelines

PathtoPublish - The folder or file path to publish. This can be a fully-qualified path or a path relative to the root of the repository.

Another possible workaround is to add an extra delete file step before publishing the artifact, where you delete all the unnecessary files in the artifact staging directory.

Delete task docs: https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/utility/delete-files?view=azure-devops

Upvotes: 2

Related Questions