YAML directory #1430
YAML directory #1430
Conversation
ericsciple
force-pushed
the
users/ersciple/m131directory
branch
from
119afbe to
9a8fa79
Compare
|
This would be useful to me as well to simplify automation of cloning build definitions at release time. |
|
|
||
| ```yaml | ||
| steps: | ||
| - template: ../../steps/foo/build.yml |
There was a problem hiding this comment.
Is a relative reference the only way to do this? ie, could you explicitly reference the root of the repo?
steps:
- template:/eng/common/steps/foo/build.ymlThere was a problem hiding this comment.
yes I believe that works today
|
|
||
| We plan to support a convention-based directory structure, with a couple goals in mind: | ||
|
|
||
| 1. Today we only create a build definition on-push for the root file `.vsts-ci.yml`. And resource authorization on-push is only handled for that one file. With a convention based |
There was a problem hiding this comment.
Does the file have to be in the root of the repo? If we put the file under another directory that isn't the root would it still work but just not auto update?
There was a problem hiding this comment.
root of the repo or the folder structure below if you want it to auto create.
|
|
||
| ## Definition creation on-push | ||
|
|
||
| On push, builds or releases would be created for yml files under the `builds` and `releases` directories. |
There was a problem hiding this comment.
Is there a way to configure the directory to look under?
There was a problem hiding this comment.
@weshaggard - no. And that's very intentional. We need to scope our search for large pushes.
There was a problem hiding this comment.
I understand the desire to limit the scope but it still feels like this could be configurable at some level (repo/definition/vsts instance). There are reasons for different projects to need a different set of directory structure.
There was a problem hiding this comment.
Interested in those scenarios ... feel free to email/discuss with @chrisrpatterson and I as well if that's easier.
There's also a desire for approachability of a repo where you can approach the repro and instantly know what it's process is (without access to the account's config). We're also considering marketing and names in this. (vsts-yaml is instantly recognizable, considering for folder as well)
There was a problem hiding this comment.
Is it possible to maintain the above described folder structure, but move the entire structure to some other directory and search for the existence of the .vsts-pipelines/ folder? So, your search is to find .vsts-pipelines, and then do all the yml search logic. That doesn't address the approachability aspect though.
Another option would be to have a root .vsts-config.yml file
|
I think this would be super useful and am eager to see it in action. |
| ## Directory structure | ||
|
|
||
| ``` | ||
| .vsts-pipelines/ |
There was a problem hiding this comment.
Could the folder name be shortened to .vsts/?
There was a problem hiding this comment.
we will probably shorten to .pipelines
There was a problem hiding this comment.
I agree with @natemcmaster. What happens if I use multiple build systems and they all use .pipelines/? I would rather the folder be specific to vsts, and have the shortest name possible.
There was a problem hiding this comment.
FYI - we started using .vsts/ in aspnet, but for a different reason: we don't want build definitions to be auto-created on push. This spec didn't mention if there would be a way to prevent auto-definition creation, so we picked a folder name that isn't currently in these plans.
There was a problem hiding this comment.
How many current build systems use/must use .pipelines for their yaml?
There was a problem hiding this comment.
None that I am aware of currently. I know that Gitlab allows for custom paths. Still, I would associate .vsts/ with your product easier than .pipelines/
|
Is there any update on this? We are having a discussion on where to put our build .yml files (we currently have 3 'top-level' builds, and 1 phase-template .yml). Having 4 (and probably more in the future) .yml files in the root of the repo doesn't make sense to me. So we were considering putting them in a |
|
@vtbassmatt - Can you take a look at this one? |
This PR is for discussion only. This is something we are thinking about, that will help solve specific shortcomings we have today.
This feature is on the backlog, but it currently is not "next".