Add alias location filters #1
Conversation
Pull Request Test Coverage Report for Build 23
💛 - Coveralls |
weitzman
left a comment
weitzman
left a comment
There was a problem hiding this comment.
Are any changes/impacts needed for drush's site-alias command? also note that alias files are listed st command. that doesn't need changes AFAICT.
README.md
Outdated
| ### Alias naming conventions | ||
|
|
||
| Site alias names always begin with a `@`, and typically are divided in two parts: the site name, and the environment name, each separated by a dot. Neither a site name not an enviornment name may contain a dot. An example alias that referenced the `dev` envionment of the site `example` might therefore look something like: | ||
| Site alias names always begin with a `@`, and typically are divided in three parts: the alias file location (optional), the site name, and the environment name, each separated by a dot. None of these names may contain a dot. An example alias that referenced the `dev` envionment of the site `example` in the `myisp` directory might therefore look something like: |
| @example.dev | ||
| @myisp.example.dev | ||
| ``` | ||
| The location name is optional. If specified, it will only consider alias files located in directories with the same name as the provided location name. The remainder of the path is immaterial; only the directory that is the immediate parent of the site alias file is relevant. The location name may be omitted, e.g.: |
There was a problem hiding this comment.
unless i'm mistaken, this encourages another level of nesting of aliases. but later in the docs we say that no deep searching is done for alias files. so folks must point explicitly to 'schools' dir?
There was a problem hiding this comment.
Yes, with this PR you must explicitly add every new location to your config directory, or the alias will not be found.
We could consider increasing the search depth by one, but for some locations that might be undesirable. We could consider adding a config location /path/to/alias/* to add every directory under a single path. I decided to start with the requirement to add each location explicitly. As you said elsewhere, this is sort of a "Drush for ISPs" feature. Users should only have a handful of ISPs, so unless this feature starts getting used for other purposes, I think the requirement for explicit config is acceptable.
There was a problem hiding this comment.
Also note that extra locations may be either inside of sites or next to it.
There was a problem hiding this comment.
Actually, the site-alias project allows deep searching -- it has an API to set the depth of the search. The search depth defaults to current-directory only (no deep searching), and Drush does not set it to allow deeper searching.
|
This PR did not require any changes to the API, and therefore required no changes in Drush for the |
… the 'location' directive.
Overview
This pull request:
Summary
Adds the ability to specify locations for alias files, e.g.
@isp.site.envwill look for the aliassite.env, but only in alias files where the immediate parent is named "isp".Motivation
In Drush 8 and earlier, complex aliases such as
@foo.bar.baz.bozwere possible. This scheme was too flexible, though; the previous example could have referred to the sitebar.bazin the groupfoo, or it could have been the sizebazin the groupfoo.bar. The only way to evaluate such expressions was to evaluate all aliased and then search for matches.Drush 9 greatly simplified alias parsing for improved performance. For a while, alias group files were supported (
@group.site.env), so long as none of the component parts (the group, site or env) contained a.; however, group files were removed so that all alias files could follow the same format. (Group files added another level of nesting to define the groups.)The elimination of this feature made the code much smaller and more comprehensible; however, it left a functionality gap. While it is possible to define a new directory to store all of the aliases for a single isp or remote server (or any other grouping of aliases), there is no way to specify which group an alias belongs to, or to list all of the aliases in a given group.
This PR re-introduces alias groups, but with a much simpler implementation. Now, an alias group is simply a location filter that names the directory that site aliases in the group are stored in.