4

I am running a docker image in Azure Devops yaml-pipeline using a container step. However, I have problems mounting the content of the repo so that this is accessible from inside the docker image.

The Azure Devops pipeline.yml file is as follows:

container:
  image: 'image-name'
  endpoint: 'foo'
  options: '-v $(Build.SourcesDirectory):/testing'

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script inside docker image'

This fails with the error message:

Error response from daemon: create $(Build.SourcesDirectory): "$(Build.SourcesDirectory)" includes 
invalid characters for a local volume name, only "[a-zA-Z0-9][a-zA-Z0-9_.-]" are allowed. If you intended 
to pass a host directory, use absolute path

I also tried replacing $(..)$ with $[..] (see here but this results in the same error. Also with ${{..}} the pipeline will not even start (error: "A template expression is not allowed in this context" in the UI)

If I remove options the script runs, but the repo is not mounted.

For non-yaml pipelines, the question was addressed here.

Any ideas how to accomplish this? Or do I need to create a new docker image where the repo files have been add:ed?

dehkp
  • 43
  • 3

1 Answers1

5

Any ideas how to accomplish this? Or do I need to create a new docker image where the repo files have been add:ed?

When specifying the Container using Yaml Schema directly, the Azure DevOps Service will call an extra Initialize containers task automatically before checkout source repo task and your real tasks.

container:
  image: 'image-name'

steps:
- script: echo Hello, world!
  displayName: 'Run a one-line script inside docker image'

enter image description here

During the Initialize containers task, the predefined variables like Agent.BuildDirectory, Build.Repository.LocalPath and Build.SourcesDirectory are not expanded (non-defined variables).

So you can't use the Build.SourcesDirectory in this way cause the value of this variable is expanded after the Initialize containers task.

1.About why the link you shared above can work: It's in a docker task/step so it can recognize the $(Build.SourcesDirectory) variable. (The real build tasks run after the build variables are defined)

2.If you're using specific Micorosft-hosted agent, you can try hard-coding the path. You can check this similar issue.

Usually for windows-hosted agent: $(Build.SourcesDirectory)=> D:\a\1\s

For Ubuntu-hosted agent: $(Build.SourcesDirectory)=> /home/vsts/work/1/s.

LoLance
  • 25,666
  • 1
  • 39
  • 73
  • Really good answer, elaborating on all the pieces, the expansion timing and the different options and the ones which seem so, but are not - and the 'why'. Thank you! – Eugen Mayer Apr 28 '22 at 06:19