Using Composer and Private Repository on GitHub us

问题:

My compsoser.json uses 2 private repositories from our Organisation Github Account and is as follows.

{
    "name": "API",
    "repositories": [
      {
        "type": "vcs",
        "url": "[e-mail]/company/private.git"
      },
      {
        "type": "vcs",
        "url": "[e-mail]/company/private2.git"
      }
    ],
    "require": {
        "php": ">=5.3.3",
        "zendframework/zendframework": ">2.1.3",
        "doctrine/mongodb-odm": "dev-master",
        "doctrine/doctrine-mongo-odm-module": "dev-master",
        "company/private": "dev-master",
        "company/private2": "dev-master"
    }
}

We've setup SSH keys and added them to the authorized keys on our staging server. When we run git clone it works perfectly and isn't asking for any credentials.

However, when we run composer update the fetching of the repositories fails because composer doesn't have access to the repositories.

Since this is ran in a non-interactive way as this is part of a build script we can't enter credentials and like to have this automated.

What can we do to let composer have access to our private repo's during the build?

回答1:

You can configure composer to use key files to access private repository.

More info: https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md#security

回答2:

I understand the question title specifically mentions using type 'vcs' but this is an alternate method of using private git repos to deploy a project as a package.

"repositories": [
  {
    "type": "package",
    "package": {
      "name": "company/private",
      "version": "0.1.0",
      "type": "package",
      "source": {
        "url": "[e-mail]:/company/private.git",
        "type": "git",
        "reference": "master"
      }
    }
  }
],
"require": {
  "company/private": "*"
}

The limitation is that you must manually change the version number every time you deploy if you want the latest version. However, this is also its advantage.

Defining a repo in this way will allow you to pull a specific tagged version. In this case the commit with tag 0.1.0 will be pulled on composer update.

You will need to add the SSH keys of the server you are deploying to in your github account.

回答3:

The URLs in your original question are missing a colon:

"url": "[e-mail]/company/private.git"

should be

"url": "[e-mail]:/company/private.git"

I just had the same problem and this fixed it.

回答4:

"name": "{vendor}/{package-name}",    
"repositories": [
    {
        "type": "package",
        "package": {
            "name": "{vendor}/{package-name}",
            "version": "{arbitrary-version}",
            "type": "package",
            "source": {
                "url": "[e-mail]:{github-username}/{github-repository}.git",
                "type": "git",
                "reference": "{branch}"
            }
        }
    }
]
"require": {
    "{vendor}/{package-name}": "*"
}

I really appreciated the answers and guidance; however, could not get the solution to work for me. And, I think the answer could possibly use some added detail with regard to what appears to be going on here.

• vendor: The vendor name used in the package's composer.json.
• package-name: The package name user in the package's composer.json.
• arbitrary-version: A random version number; does not need to exist as a version in GitHub.
• github-username: The GitHub user account where the repo lives.
• github-repository: The GitHub repository name.
• branch: The GitHub branch to use when checking out the code.

The two things that gave me the greatest issue was the colon (:) does not (should not?) be followed by a forward slash (/). Don't forget to put .git at the end of the url.

Points of conjecture and uncertainty:

1. I'm not sure what would happen if you change the package.name member to something incorrect. In other words, I don't know if this is an internal reference for require alone; or, if there will be something else happening there.
2. I'm not sure if the branch actually changes anything and I'm not in a position to test.