php - custom - composer satis

Usando Composer y Private Repository en GitHub usando VCS en Build Server

Question

Mi compsoser.json utiliza 2 repositorios privados de nuestra cuenta de Github de organización y es el siguiente.

{
    "name": "API",
    "repositories": [
      {
        "type": "vcs",
        "url": "[email protected]/company/private.git"
      },
      {
        "type": "vcs",
        "url": "[email protected]/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"
    }
}

Hemos configurado las claves SSH y las hemos agregado a las claves autorizadas en nuestro servidor de almacenamiento. Cuando ejecutamos git clone, funciona perfectamente y no solicita credenciales.

Sin embargo, cuando ejecutamos la actualización de compositor, la recuperación de los repositorios falla porque el compositor no tiene acceso a los repositorios.

Dado que esto se ejecuta de forma no interactiva, ya que forma parte de un script de compilación, no podemos ingresar las credenciales y nos gusta que sea automatizado.

¿Qué podemos hacer para permitir que el compositor tenga acceso a nuestro repo privado durante la compilación?

Answer 1

Entiendo que el título de la pregunta menciona específicamente el uso del tipo ''vcs'', pero este es un método alternativo para usar repositorios git privados para implementar un proyecto como un paquete.

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

La limitación es que debe cambiar manualmente el número de versión cada vez que lo implemente si desea obtener la última versión. Sin embargo, esta es también su ventaja.

Definir un repositorio de esta manera te permitirá obtener una versión etiquetada específica . En este caso, la confirmación con la etiqueta 0.1.0 se 0.1.0 en la composer update .

Deberá agregar las claves SSH del servidor en el que está implementando en su cuenta de github.

Answer 2

Las URL en su pregunta original faltan dos puntos:

"url": "[email protected]/company/private.git"

debiera ser

"url": "[email protected]:/company/private.git"

Acabo de tener el mismo problema y esto lo solucionó.

Answer 3

Puede configurar el compositor para usar archivos clave para acceder al repositorio privado.

Más información: https://getcomposer.org/doc/articles/handling-private-packages-with-satis.md#security

Answer 4

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

Realmente aprecié las respuestas y la guía; Sin embargo, no pude conseguir que la solución funcionara para mí. Y, creo que la respuesta podría utilizar algunos detalles adicionales con respecto a lo que parece estar sucediendo aquí.

• proveedor: el nombre del proveedor utilizado en el paquete composer.json .
• nombre-paquete: el usuario del nombre del paquete en el composer.json del paquete.
• versión arbitraria: un número de versión aleatoria; No es necesario que exista como una versión en GitHub.
• github-username: la cuenta de usuario de GitHub donde vive el repositorio.
• github-repository: El nombre del repositorio de GitHub.
• rama: la rama de GitHub para usar al revisar el código.

Las dos cosas que me dieron el mayor problema fue que los dos puntos (:) no (¿no debería?) Deben ir seguidos de una barra ( / ). No te olvides de poner .git al final de la url .

Puntos de conjetura e incertidumbre:

1. No estoy seguro de qué pasaría si cambia el miembro package.name a algo incorrecto. En otras palabras, no sé si esta es una referencia interna para solo; O, si va a pasar algo más allí.
2. No estoy seguro de si la rama realmente cambia algo y no estoy en condiciones de probar.