Usando Git: Resumen
Git es una parte esencial del sistema de entrega, y alentamos a todos los usuarios que aún no están familiarizados con sus conceptos a aprender más sobre el sitio web de Git. También hay algunos útiles Hojas de trucos de Git por ahí para usar.
Git debe estar instalado para usar las API del sistema de entrega, y puede hacerlo en el sitio web de Git. Sin embargo, los ejemplos de línea de comandos que damos no se pueden usar directamente como están escritos, ya que se usan varios marcadores de posición. Sustituya en la variable de entorno o valor por lo siguiente: ID DE LA CUENTA , REPO_NOMBRE , ACCESO_TOKEN , NOMBRE DE USUARIO
Usando Git: Autorizar
A diferencia de las API REST, solo puede autorizar de una manera con Git: a través de la autenticación básica utilizando su nombre de usuario y contraseña de Brightcove. Actualmente no es posible usar tokens de acceso OAuth con Git.
Git debería solicitarle su nombre de usuario y contraseña, por lo que no verá ninguna mención de autenticación en los ejemplos a continuación.
Git: Crear / actualizar repositorio
Con Git instalado y un repositorio creado a través de REST, puede comenzar a crear su repositorio local para su uso. Un repositorio local creado simplemente creando un directorio y luego inicializando Git dentro de ese directorio usando el git init mando.
mkdir my_repo
cd my_repo
git init
Con el repositorio inicializado, ahora querrá vincularlo al repositorio remoto en el sistema Brightcove para que pueda enviar fácilmente los cambios al servidor.
git remote add origin https://repos.api.brightcove.com/v1/accounts/[ACCOUNT_ID]/repos/[REPO_NAME]
Luego, puede agregar, editar o eliminar archivos para su control remoto local como desee. Luego puede usar los comandos normales de Git para actualizar el repositorio remoto.
git add -A
git commit 'Changing stuff'
git push
Usando Git: Push repo
Los detalles de dónde se insertan los diferentes archivos se dan en la salida del git push. También puede encontrar la URL base para cualquier repositorio dentro de las llamadas a la API REST a la URL del repositorio. Todos los archivos se almacenan en un CDN para que todos los usuarios puedan verlos rápidamente.
Si está creando su propio reproductor completamente personalizado, debe tener en cuenta que no podemos garantizar que las actualizaciones de todos los archivos se realicen simultáneamente dentro de un cliente típico como un navegador. Por lo tanto, se recomienda encarecidamente que los usuarios de las API del sistema de entrega utilicen una estrategia de control de versiones que garantice que los archivos estrechamente acoplados se soliciten juntos después de realizar una actualización. Una estrategia para lograr esto es realizar actualizaciones en una ubicación completamente nueva en lugar de sobrescribir los archivos existentes. Esto obliga a que los archivos solicitados sean las fuentes originales, ya que no hay posibilidad de que haya una copia en caché en nuestro servicio. Sin embargo, debe esperar que las primeras solicitudes de estas copias no almacenadas en caché tarden más de lo habitual. Para ser claros, si está creando reproductores usando las API de administración de reproductores y no usando las API del sistema de entrega directamente, no necesita preocuparse por esto, ya que los problemas de caché se manejan por usted.
El tiempo total que le lleva ver las actualizaciones reflejadas en su sitio en vivo depende de varios factores. Lo más importante es que estos factores incluyen el almacenamiento en caché del navegador y el tiempo que lleva completar una solicitud de purga de nuestros nodos de borde. Por lo general, no debería tomar más de cinco minutos desde la última vez que presionó a un repositorio. Esto se debe a que los archivos que servimos están configurados para almacenar en caché en un navegador durante cinco minutos de forma predeterminada y solo toma alrededor de un minuto en promedio para que se borren todos nuestros nodos de borde. Sin embargo, en condiciones de máxima carga de servicio, el tiempo de purga puede ser mucho mayor, hasta 10 minutos. En el peor de los casos, tomaría (aún determinando este tiempo) que todas las capas de almacenamiento en caché se borren y que las actualizaciones finalmente se activen. Esto nunca debería suceder a menos que la solicitud de purga haya fallado o se haya agotado el tiempo de espera y nuestro controlador de caché de respaldo fuera necesario para actualizar su contenido.
Ver sus cambios
Después de realizar cambios, probablemente le gustaría ver lo que ha hecho. Puede hacer esto usando el gitk mando. Cuando use este comando en su Git inicializado directamente, aparecerá una GUI que le mostrará su trabajo. Aparecerá una muestra simple de la siguiente manera:
Usando Git: Clonar repositorio
Puede copiar un repositorio que Brightcove ya está almacenando en su sistema local. En términos de Git, esto se conoce como clonar un repositorio. Esto le permite no solo obtener un repositorio creado por otra persona en su organización, sino también recuperar los repositorios que han creado las API de administración de reproductores.
git clone https://repos.api.brightcove.com/v1/accounts/{account_id}/repos/$REPO_NAME/$ACCESS_TOKEN
Respuestas de error: Git
Las respuestas de error para las llamadas de Git se limitan a lo que su cliente Git pueda admitir:
- Si intenta llamar a un repositorio que no existe, normalmente recibirá un mensaje sobre git-upload-pack no encontrado: ¿ejecutó git update-server-info en el servidor?. Verifique para asegurarse de que la URL del repositorio sea correcta.
- Si su llamada no puede ser autenticada o autorizada, generalmente se le pedirá una contraseña. Salga de esta solicitud de contraseña e intente repasar la guía de OAuth nuevamente para asegurarse de tener un token de acceso válido.