soporte Contactar con asistencia técnica | estado del sistema Estado del Sistema

Git Información general

En este tema, aprenderá los conceptos básicos del uso de Git, que es una parte esencial de Delivery System API.

Usando Git: Descripción general

Git es una parte esencial del sistema de entrega, y alentamos a todos los usuarios que todavía no estén familiarizados con sus conceptos a que aprendan más sobre el sitio web de Git. También hay algunos prácticos Git cheat sheets por ahí para usar.

Git debe ser instalado para usar el Delivery System APIs, y puedes hacerlo en el sitio web de Git. Sin embargo, los ejemplos de la línea de comandos que damos no se pueden usar directamente tal como están escritos, ya que se usan varios marcadores de posición. Sustituir en la variable de entorno o valor por lo siguiente: ID DE LA CUENTA, REPO_NAME, ACCESS_TOKEN, NOMBRE DE USUARIO

Usando Git: Autorizar

A diferencia de las API REST, solo puede autorizar una forma 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 repos

Con Git instalado y un repositorio creado a través de REST, puede comenzar a crear su repositorio local para usar. Un repositorio local hecho 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 sus 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 lo 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: Repo de empuje

Los detalles de dónde se insertan los diferentes archivos se proporcionan en la salida del git push. También puede encontrar la URL base para cualquier repositorio dentro de las llamadas de la API REST a la URL del repositorio. Todos los archivos se almacenan en un CDN para que puedan ser vistos rápidamente por todos los usuarios.

Si está construyendo el suyo propio, completamente personalizado player, debe tener en cuenta que no podemos garantizar que las actualizaciones de todos los archivos se realicen simultáneamente en 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 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 exige 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ás creando players usando el player API de administración y no usar las API del sistema de entrega directamente, no necesita preocuparse por esto ya que las preocupaciones de caché se manejan por usted.

El tiempo total que le lleva ver las actualizaciones reflejadas en su sitio en vivo depende de una serie de 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 desde nuestros nodos de borde. Por lo general, no debería tomar más de cinco minutos desde la última vez que presionó 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 manera predeterminada y solo demora aproximadamente un minuto en promedio para que todos nuestros nodos de borde se borren. Sin embargo, bajo una carga de servicio máxima, el tiempo de purga puede ser mucho mayor, tanto como 10 minutos. En el peor de los casos, tomará (aún determinando esta vez) que todas las capas de almacenamiento en caché se borren y sus actualizaciones finalmente se activen. Esto nunca debería suceder a menos que la solicitud de purga haya fallado o haya excedido el tiempo de espera y nuestro manejador de caché de reserva haya tenido que actualizar su contenido.

Viendo tus cambios

Después de hacer cambios probablemente le gustaría ver lo que ha hecho. Puedes hacer esto usando el gitk mando. Cuando use este comando en su Git inicializado directamente, aparecerá una GUI que le mostrará su trabajo. Una muestra simple aparece de la siguiente manera:

GUI de gitk

Usando Git: Clone Repo

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 de su organización, sino también recuperar los repositorios que player API de gestión han creado.

          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 llamadas de Git se limitan a lo que sea compatible con su cliente de Git:

  • Si intenta llamar a un repositorio que no existe, generalmente 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 revisar nuevamente la guía de OAuth para asegurarse de tener un token de acceso válido.

Página actualizada por última vez el 12 jun 2020