Wildcard branch alias support

[TravisCarden]

Summary: I want the ability to specify a wildcard branch alias that matches any branch--something like dev-* or @dev.

Details: I use branch aliases with path repositories to allow me to test changes to members of a network of interdependent packages, and the strategy works well for the small number of common, known branches that contributors submit pull requests to. However, some of my contributors like to test their changes by simply pushing a topic branch to trigger a build, resulting in path repositories with versions like dev-issue-12345 or dev-trying-something that can't possibly be predicted. So the path repositories don't resolve to packages that actually get installed, and my builds don't actually include the system under test. To solve this problem, I'd really like to have some kind of wildcard branch alias that doesn't require me to know or specify specific branch names ahead of time--something like dev-*, e.g., "dev-*": "1.0.x-dev", or simply @dev, e.g., "@dev": "1.0.x-dev".

Workaround: In the absence of such a feature I've been using the following workaround: I begin my builds by ensuring that the checked out Git branch matches my alias, e.g.:

BRANCH="1.0.x"; [[ $(git rev-parse --abbrev-ref HEAD) == ${BRANCH} ]] || git branch -f ${BRANCH} && git checkout ${BRANCH}

Request: Does such a feature already exist? If so, it should be documented. If not, could one be added? In either case I would be open to sending a pull request if the change would be welcome, but as it would be my first contribution to this project I might need a little guidance. Thanks!

[Seldaek]

Normally if you're on a feature branch Composer will try to match it to a real branch, e.g. you branch off dev-master to dev-foo-bar, it should figure out that this branch is based on dev-master, then figure out that master is aliased to 1.x or whatever. If this doesn't work maybe we should have a look at why this fails in your case. You can have a look at the VersionGuesser class.

An alternative is to provide COMPOSER_ROOT_VERSION to pin the version to something, but I don't think this works with Path repo packages.

[TravisCarden]

Thanks, @Seldaek. I looked at VersionGuesser and ran it on a repo I'm having trouble with. It actually returns the version I need, so I guess that's not my problem. composer why-not tells me "There is no installed package depending on "my/package" in versions not matching @dev". How can I find out why it's not using my repository? Update: I figured out why it wasn't working for me, and it wasn't an issue with Composer itself.

[TravisCarden]

I think I understand things now, and I propose that there is a valid use case for a wildcard branch alias, namely a CI workflow in which there may be no other branches in the repository for VersionGuesser to use to infer the target branch for a pull request and thus guess the correct version. To illustrate, suppose I have a pull request based on a branch called fix-some-issue. A standard Travis CI configuration will clone the repository with that branch only, and VersionGuesser will guess a version of dev-fix-some-issue. Obviously, there will be no branch alias for that in the target repository's composer.json, so if the test suite uses a path repository to compose the package into a test fixture, it will fail to find a match and instead download a stable release from Packagist. As stated before, this can be mitigate by manipulating the repository to trick Composer into guessing the version one wants. But it would be cleaner to be able to just tell Composer to treat any version as a match regardless. I imagine something like this:

"extra": {
  "branch-alias": {
      "@dev": "1.0.x-dev"
  }
}

[alcohol]

This is what COMPOSER_ROOT_VERSION is for.

[Seldaek]

@TravisCarden the problem with this "carpet bomb" approach you suggest is that when you do have multiple branches available e.g. with a vcs repository the branch-alias would resolve many branches to the same 1.0.x-dev alias and then the solver will have to pick one branch to install at random between all your dev branches, which sounds sub-optimal. It might help for your particular use case but I think in the bigger picture it'll be a mess.

[TravisCarden]

That makes sense, @Seldaek. I'll see if COMPOSER_ROOT_VERSION will work for my use case. Thanks for the help!