Could you clarify how path resolution for templates is managed in a more advanced scenario?
# File: jobs/build.yml
parameters:
- { name: variables, type: object }
- { name: steps, type: stepList }
jobs:
- job:
variables: ${{ parameters.variables }}
steps: ${{ parameters.steps }}
# File: variables/config.yml
variables:
configuration: Release
# File: .vsts.ci.yml
jobs:
- template: jobs/build.yml
parameters:
variables:
- template: variables/config.yml # Does not work!
steps:
- script: echo hello!
In this example, it seems that the variables template path variables/config.yml is resolved from the jobs template location jobs/build.yml. And indeed, file jobs/variables/config.yml does not exist.
But one would expect to have paths resolved from where there are used, here it would be from .vsts.ci.yml.
⚠Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
We really need more clarification, the purpose of templates is that we can reuse it anywhere and it doesn't seem the case.
Example of folder structures:
-- Build
---- Provision.yml
-- Deploy
---- CD.yml
-- Templates
---- GitVersion.yml
I would be my expectation that the Provision.yml would be able to use the template GitVersion.yml, how does this work?
@brunomartinspro, you can use GitVersion.yml from Provision.yml with a relative path: - template: ../Templates/GitVersion.yml. At least in this scenario, I know it works.
Please add some clarification on this issue in template documentation. It seems that relative paths work but fine but not absolute paths. In many cases, absolute paths will be (pun intended) absolutely preferred. If this is incorrect, please provide some examples showing how absolute paths function with templates. When I have tried to use absolute paths, I get an error when running the pipeline from the template path, where the template path is always prefixed by the relative path of the template, therefore appending the absolute path to the path of the template itself.
@brunomartinspro, any news about this?
Template paths should be relative to the file doing the including. If you have a nested hierarchy like this:
|
+-- fileA.yml
|
+-- dir1/
|
+-- fileB.yml
|
+-- dir2/
|
+-- fileC.yml
Then in fileA.yml you can get the other files like this:
steps:
- template: dir1/fileB.yml
- template: dir1/dir2/fileC.yml
On the other hand, if fileC.yml is your starting point, it can include the others like this:
steps:
- template: ../../fileA.yml
- template: ../fileB.yml
And for completeness, if we're starting at fileB.yml:
steps:
- template: ../fileA.yml
- template: dir2/fileC.yml
Most helpful comment
@brunomartinspro, you can use
GitVersion.ymlfromProvision.ymlwith a relative path:- template: ../Templates/GitVersion.yml. At least in this scenario, I know it works.