<p>I resolved the problem by publishing the terraform files from the Build pipeline:</p>
<pre><code>- publish: $(Build.SourcesDirectory)/terraform
  artifact: Terraform
</code></pre>
<p>I also realised that I could run <code>terraform validate</code> and other static analysis in the Build pipeline, and failing the build if this does not pass. So the Deploy pipeline has less validation to do and is just concerned with deployment.</p>

CC BY-SA 4.0
2022-08-31T16:13:35.870Z
2022-08-31T16:13:35.870Z
mikeagg
<p>How come my deployment pipeline cannot see the terraform files in my respository?</p>
<p>In Azure Devops I have a single  repo for a small app, with a simple folder structure</p>
<pre><code>main
├── pipelines
    build.yaml, deploy.yaml, etc
├── terraform
    main.tf, etc.
├── src
├── test
</code></pre>
<p>The Build pipeline builds the app, runs unit tests, and publishes the build as a pipeline artifact:</p>
<pre><code>- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    artifact: 'drop'
    publishLocation: 'pipeline'
</code></pre>
<p>The Deploy pipeline can be run manually for any environment, but when a build is successful on the main branch, the Deploy pipeline is automatically triggered to deploy the app to our CI environment:</p>
<pre><code>trigger: none
resources:
  pipelines:
    - pipeline: buildPipeline
      source: 'Build-MyApp'
      trigger:
        branches:
        - main
parameters:
- name: environment
  type: string
  default: dev 
</code></pre>
<p>But when the Deploy pipeline attempts to run terraform it cannot access the TF files from the repo. This is the output of <code>tree $(Pipeline.Workspace) /F</code> :</p>
<pre><code>/home/vsts/work/1
├── TestResults
├── a
├── b
├── buildPipeline
│   └── drop
│       └── MyApp.zip
└── s
</code></pre>
<p>Should I configure the Deploy pipeline with access to the triggering build's repo and if so, how? Or should I publish the terraform files (and any other IAC resources) as artifacts of the build?</p>

<azure-devops><infrastructure-as-code>
Accessing source files in triggered deployment build
mikeagg
# Accessing source files in triggered deployment build

(Asked by: username_0 on 2022-08-29)

How come my deployment pipeline cannot see the terraform files in my respository?
In Azure Devops I have a single  repo for a small app, with a simple folder structure
main
├── pipelines
    build.yaml, deploy.yaml, etc
├── terraform
    main.tf, etc.
├── src
├── test

The Build pipeline builds the app, runs unit tests, and publishes the build as a pipeline artifact:
- task: PublishPipelineArtifact@1
  inputs:
    targetPath: '$(Build.ArtifactStagingDirectory)'
    artifact: 'drop'
    publishLocation: 'pipeline'

The Deploy pipeline can be run manually for any environment, but when a build is successful on the main branch, the Deploy pipeline is automatically triggered to deploy the app to our CI environment:
trigger: none
resources:
  pipelines:
    - pipeline: buildPipeline
      source: 'Build-MyApp'
      trigger:
        branches:
        - main
parameters:
- name: environment
  type: string
  default: dev 

But when the Deploy pipeline attempts to run terraform it cannot access the TF files from the repo. This is the output of tree $(Pipeline.Workspace) /F :
/home/vsts/work/1
├── TestResults
├── a
├── b
├── buildPipeline
│   └── drop
│       └── MyApp.zip
└── s

Should I configure the Deploy pipeline with access to the triggering build's repo and if so, how? Or should I publish the terraform files (and any other IAC resources) as artifacts of the build?

**Tags:** azure-devops, infrastructure-as-code


---

## 1 answers

### Answer by username_0 on 2022-08-31. Score: 0

I resolved the problem by publishing the terraform files from the Build pipeline:
- publish: $(Build.SourcesDirectory)/terraform
  artifact: Terraform

I also realised that I could run terraform validate and other static analysis in the Build pipeline, and failing the build if this does not pass. So the Deploy pipeline has less validation to do and is just concerned with deployment.


---

