Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Solución de problemas CodePipeline

La siguiente información puede ayudarle a solucionar problemas comunes en AWS CodePipeline.

Error de canalización: canalización configurada con AWS Elastic Beanstalk devuelve un mensaje de error: «Falló la implementación. El rol proporcionado no tiene los permisos suficientes: Service:AmazonElasticLoadBalancing»

Problema: el rol de servicio de CodePipeline no tiene permisos suficientes para AWS Elastic Beanstalk algunas operaciones en Elastic Load Balancing, entre otras. La función de servicio de CodePipeline se actualizó el 6 de agosto de 2015 para solucionar este problema. Los clientes que crearon su rol de servicio antes de esta fecha deben modificar la instrucción de política de su rol de servicio para añadir los permisos necesarios.

Posibles correcciones: la solución más fácil es editar la instrucción de política para su rol de servicio como se detalla en Añade permisos a la función de CodePipeline servicio.

Una vez aplicada la política editada, siga los pasos de Iniciar la canalización manualmente para volver a ejecutar manualmente las canalizaciones que usa Elastic Beanstalk..

En función de sus requisitos de seguridad, puede modificar también los permisos de otras dos formas.

Error de implementación: una canalización configurada con un AWS Elastic Beanstalk la acción de implementación se bloquea en lugar de fallar si falta el permiso DescribeEvents "»

Problema: la función de servicio de CodePipeline debe incluir la "elasticbeanstalk:DescribeEvents" acción de cualquier canalización que la utilice. AWS Elastic Beanstalk Sin este permiso, las acciones de AWS Elastic Beanstalk implementación se bloquean sin fallar ni indicar un error. Si esta acción no aparece en su rol de servicio, significa que CodePipeline no tiene permisos para ejecutar la etapa de implementación en canalización AWS Elastic Beanstalk en su nombre.

Posibles soluciones: revisa tu rol CodePipeline de servicio. Si falta la acción "elasticbeanstalk:DescribeEvents", utilice los pasos de Añade permisos a la función de CodePipeline servicio para añadirla mediante la característica Edit Policy de la consola de IAM.

Una vez aplicada la política editada, siga los pasos de Iniciar la canalización manualmente para volver a ejecutar manualmente las canalizaciones que usa Elastic Beanstalk..

Error de canalización: una acción de origen devuelve un mensaje con permisos insuficientes: «No se pudo acceder al nombre del CodeCommit repositorio». Asegúrese de que rol de IAM de la canalización tenga permisos suficientes para obtener acceso al repositorio".

Problema: la función de servicio para CodePipeline no tiene permisos suficientes CodeCommit y es probable que se haya creado antes de que se añadiera la compatibilidad con el uso de CodeCommit repositorios el 18 de abril de 2016. Los clientes que crearon su rol de servicio antes de esta fecha deben modificar la instrucción de política de su rol de servicio para añadir los permisos necesarios.

Posibles soluciones: agrega los permisos necesarios CodeCommit a la política de tu rol de CodePipeline servicio. Para obtener más información, consulte Añade permisos a la función de CodePipeline servicio.

Error de canalización: una acción de compilación o prueba de Jenkins se ejecuta de manera prolongada y da un error debido a la falta de credenciales o permisos

Problema: si el servidor Jenkins está instalado en una instancia de Amazon EC2, es posible que la instancia no se haya creado con un rol de instancia que tenga los permisos necesarios para ello. CodePipeline Si utiliza un usuario de IAM en un servidor de Jenkins, en una instancia local o en una instancia de Amazon EC2 creada sin el rol de IAM necesario, el usuario de IAM no tiene los permisos necesarios o el servidor de Jenkins no puede tener acceso a esas credenciales a través del perfil configurado en el servidor.

Soluciones posibles: asegúrese de que el rol de la instancia de Amazon EC2 o el usuario de IAM estén configurados con la política administrada AWSCodePipelineCustomActionAccess o con los permisos equivalentes. Para obtener más información, consulte AWS políticas administradas para AWS CodePipeline.

Si utiliza un usuario de IAM, asegúrese de que el AWS perfil configurado en la instancia utilice el usuario de IAM configurado con los permisos correctos. Es posible que tengas que proporcionar las credenciales de usuario de IAM que configuraste para la integración entre Jenkins y CodePipeline directamente en la interfaz de usuario de Jenkins. Este procedimiento no se recomienda. Si tiene que hacerlo, asegúrese de que el servidor de Jenkins está protegido y usa HTTPS en lugar de HTTP.

Error de canalización: una canalización creada en una AWS Región que usa un depósito creado en otro AWS La región devuelve un "InternalError" con el código "JobFailed»

Problema: La descarga de un artefacto almacenado en un bucket de Amazon S3 fallará si la canalización y el bucket se crean en AWS regiones diferentes.

Posibles soluciones: asegúrese de que el bucket de Amazon S3 en el que está almacenado su artefacto esté en la misma AWS región que la canalización que ha creado.

Error de implementación: un archivo ZIP que contiene un archivo WAR se implementa correctamente en AWS Elastic Beanstalk, pero la URL de la aplicación indica un error 404 no encontrado

Problema: un archivo WAR se ha implementado correctamente en un entorno de AWS Elastic Beanstalk , pero la URL de la aplicación devuelve un error 404 Not Found.

Posibles soluciones: AWS Elastic Beanstalk puede descomprimir un archivo ZIP, pero no un archivo WAR contenido en un archivo ZIP. En lugar de especificar un archivo WAR en su archivo buildspec.yml, especifique una carpeta que incluya el contenido que se va a implementar. Por ejemplo:

version: 0.2

phases:
  post_build:
    commands:
      - mvn package
      - mv target/my-web-app ./
artifacts:
  files:
    - my-web-app/**/*
 discard-paths: yes

Para ver un ejemplo, consulte Ejemplo de AWS Elastic Beanstalk para CodeBuild.

Los nombres de la carpeta de artefactos de la canalización parecen estar truncados

Problema: Al ver los nombres de los artefactos de oleoductos en CodePipeline, los nombres aparecen truncados. Esto puede hacer que parezca que los nombres son similares o que ya no contienen el nombre completo de la canalización.

Explicación: CodePipeline trunca los nombres de los artefactos para garantizar que la ruta completa de Amazon S3 no supere los límites de tamaño de la política al CodePipeline generar credenciales temporales para los trabajadores.

Aunque el nombre del artefacto parezca truncado, se CodePipeline asigna al depósito del artefacto de forma que no se vea afectado por los artefactos con nombres truncados. La canalización puede funcionar con normalidad. Esto no supone un problema con la carpeta ni con los artefactos. Los nombres de las canalizaciones tienen una longitud máxima de 100 caracteres. Aunque el nombre de la carpeta de artefactos parezca estar acortado, sigue siendo único para la canalización.

Añade CodeBuild GitClone permisos para las conexiones a Bitbucket, Enterprise Server o GitHub GitHub GitLab.com

Cuando usas una acción AWS CodeConnections en una fuente y una CodeBuild acción, hay dos maneras de transferir el artefacto de entrada a la compilación:

Para agregar permisos a su política de rol de CodeBuild servicio, debe crear una política administrada por el cliente y adjuntarla a su rol de CodeBuild servicio. Los pasos siguientes crean una política en la que se especifique el UseConnection permiso en el action campo, el ARN de la conexión se especifique en el Resource campo y se limite el ID del repositorio de origen. Condition

Añade CodeBuild GitClone permisos para las acciones CodeCommit de origen

Cuando tu canalización tiene una acción CodeCommit fuente, puedes pasar el artefacto de entrada a la compilación de dos maneras:

Para agregar permisos a tu política de rol de CodeBuild servicio, debes crear una política administrada por el cliente y adjuntarla a tu rol de CodeBuild servicio. Los siguientes pasos crean una política que especifica el permiso codecommit:GitPull en el campo action.

Error de canalización: una implementación con la CodeDeployToECS acción devuelve un mensaje de error: «Se produjo una excepción al intentar leer el archivo del artefacto de definición de la tarea desde: nombre del artefacto de < origen» >

Problema:

El archivo de definición de la tarea es un artefacto obligatorio para la acción de CodePipeline implementación en Amazon ECS mediante CodeDeploy (la CodeDeployToECS acción). El tamaño máximo del ZIP del artefacto en la acción de implementación CodeDeployToECS es de 3 MB. Se devuelve el siguiente mensaje de error cuando no se encuentra el archivo o el tamaño del artefacto supera los 3 MB:

Excepción al intentar leer el archivo de artefactos de definición de tareas de: <nombre del artefacto del origen>

Posibles correcciones: asegúrese de que el archivo de definición de la tarea se incluya como un artefacto. Si el archivo ya existe, asegúrese de que el tamaño comprimido es inferior a 3 MB.

GitHub (a través de la aplicación OAuth) acción fuente: la lista de repositorios muestra diferentes repositorios

Problema:

Tras autorizar correctamente una acción GitHub (mediante una aplicación OAuth) en la CodePipeline consola, puedes elegir entre una lista de tus repositorios. GitHub Si la lista no incluye los repositorios que esperaba ver, puede solucionar el problema de la cuenta utilizada para la autorización.

Posibles soluciones: la lista de repositorios que aparece en la CodePipeline consola se basa en la GitHub organización a la que pertenece la cuenta autorizada. Comprueba que la cuenta con la que vas a autorizar GitHub sea la cuenta asociada a la GitHub organización en la que se creó el repositorio.

GitHub Acción de origen (a través de la GitHub aplicación): no se puede completar la conexión a un repositorio

Problema:

Como para conectarse a un GitHub repositorio se utiliza el AWS conector GitHub, necesitas permisos de propietario de la organización o permisos de administrador para acceder al repositorio para crear la conexión.

Posibles soluciones: para obtener información sobre los niveles de permisos de un GitHub repositorio, consulta https://docs.github.com/en/free-pro-team @ latest/github teams/permission /setting-up-and-managing-organizations-and- -levels-for-an-organization.

Error de Amazon S3: al ARN del rol de servicio se le niega el acceso a S3 para el bucket de S3 CodePipeline < > < BucketName >

Problema:

Mientras está en curso, la CodeCommit acción CodePipeline comprueba la existencia del bucket del artefacto de canalización. Si la acción no tiene permiso para comprobarlo, se produce un AccessDenied error en Amazon S3 y aparece el siguiente mensaje de error: CodePipeline

CodePipeline al rol de servicio «arn:aws:iam::AccountID: role/service -role/RoleID" se le está denegando el acceso a S3 para el bucket de S3 "» BucketName

Los CloudTrail registros de la acción también registran el error. AccessDenied

Posibles soluciones: haga lo siguiente:

Una vez aplicada la política editada, siga los pasos de Iniciar la canalización manualmente para volver a ejecutar manualmente la canalización.

Las canalizaciones con Amazon S3, Amazon ECR o una CodeCommit fuente ya no se inician automáticamente

Problema:

Tras realizar un cambio en los ajustes de configuración de una acción que utiliza reglas de eventos (EventBridgeo CloudWatch eventos) para detectar cambios, es posible que la consola no detecte ningún cambio en el que los identificadores de activación de origen sean similares y tengan caracteres iniciales idénticos. Como la consola no crea la nueva regla de eventos, la canalización ya no se inicia automáticamente.

Un ejemplo de un cambio menor al final del nombre del parámetro CodeCommit sería cambiar el nombre de la CodeCommit sucursal MyTestBranch-1 aMyTestBranch-2. Como el cambio se produce al final del nombre de la rama, es posible que la regla de eventos de la acción de origen no actualice ni cree una regla para la nueva configuración del origen.

Esto se aplica a las acciones de origen que utilizan eventos de CWE para la detección de cambios, de la siguiente manera:

Posibles soluciones:

Realice una de las siguientes acciones:

Tras editar la configuración de las acciones en la consola, acepte los recursos de detección de cambios actualizados creados por la consola.

Se produjo un error de conexión al conectarse a GitHub: «Se ha producido un problema, asegúrate de que las cookies estén activadas en tu navegador» o «El propietario de una organización debe instalar la GitHub aplicación»

Problema:

Para crear la conexión para una acción de GitHub origen en CodePipeline, debes ser el propietario de la GitHub organización. Para los repositorios que no pertenecen a una organización, debe ser el propietario del repositorio. Cuando alguien que no sea el propietario de la organización crea una conexión, se crea una solicitud para el propietario de la organización y se muestra uno de los siguientes errores:

Se ha producido un problema, asegúrese de que las cookies estén habilitadas en el navegador

OR

El propietario de una organización debe instalar la GitHub aplicación

Posibles soluciones: en el caso de los repositorios de una GitHub organización, el propietario de la organización debe crear la conexión con el GitHub repositorio. Para los repositorios que no pertenecen a una organización, debe ser el propietario del repositorio.

Las canalizaciones con el modo de ejecución cambiado al modo EN COLA o PARALELO fallan cuando se alcanza el límite de ejecución

Problema: el número máximo de ejecuciones simultáneas para una canalización en modo EN COLA es de 50 ejecuciones. Cuando se alcanza este límite, la canalización falla sin mostrar ningún mensaje de estado.

Posibles soluciones: al editar la definición de la canalización para el modo de ejecución, realice la edición por separado de otras acciones de edición.

Para obtener más información sobre el modo de ejecución EN COLA o PARALELO, consulte CodePipeline conceptos.

Las canalizaciones en modo PARALELO tienen una definición de canalización desactualizada si se editan al cambiar al modo EN COLA o SUPERSEDED

Problema: para las canalizaciones en modo paralelo, al editar el modo de ejecución de la canalización en el modo EN COLA o SUPERSEDED, la definición de canalización para el modo PARALELO no se actualizará. La definición de canalización actualizada al actualizar el modo PARALELO no se usa en los modos SUPERSEDED o QUEUED.

Posibles soluciones: para las canalizaciones en modo paralelo, al editar el modo de ejecución de la canalización en el modo EN COLA o SUPERSEDED, evite actualizar la definición de la canalización al mismo tiempo.

Para obtener más información sobre el modo de ejecución EN COLA o PARALELO, consulte CodePipeline conceptos.

Las canalizaciones que cambien del modo PARALELO a otro mostrarán un modo de ejecución anterior

Problema: en el caso de las canalizaciones en modo PARALELO, al editar el modo de ejecución de la canalización en el modo EN COLA o SUPERSEDED, el estado de la canalización no mostrará el estado actualizado como PARALELO. Si la canalización cambia del modo PARALELO al modo EN COLA o SUPERSEDED, el estado de la canalización en modo SUPERSEDED o EN COLA será el último estado conocido en cualquiera de esos modos. Si la canalización nunca se ejecutó en ese modo anteriormente, el estado quedará vacío.

Posibles soluciones: para las canalizaciones en modo paralelo, al editar el modo de ejecución de la canalización en el modo EN COLA o SUPERSEDED, tenga en cuenta que la pantalla del modo de ejecución no mostrará el estado PARALELO.

Para obtener más información sobre el modo de ejecución EN COLA o PARALELO, consulte CodePipeline conceptos.

Es posible que las canalizaciones con conexiones que utilicen el filtrado de desencadenadores por rutas de archivo no se inicien al crear la ramificación

Descripción: En el caso de las canalizaciones con acciones de origen que utilizan conexiones, como una acción de BitBucket origen, puedes configurar un disparador con una configuración de Git que te permita filtrar por rutas de archivo para iniciar la canalización. En algunos casos, en el caso de las canalizaciones con activadores que se filtran por rutas de archivos, es posible que la canalización no se inicie cuando se cree por primera vez una rama con un filtro de rutas de archivo, ya que esto no permite que la CodeConnections conexión resuelva los archivos que se han modificado. Cuando la configuración de Git para el activador esté configurada para filtrar las rutas de los archivos, la canalización no se iniciará cuando la rama con el filtro se haya creado recientemente en el repositorio de origen. Para obtener más información sobre el filtrado de las rutas de los archivos, consultaAgregación de desencadenadores con tipos de eventos de solicitud de inserción o extracción de código.

Resultado: Por ejemplo, las canalizaciones CodePipeline que tengan un filtro de rutas de archivo en una rama «B» no se activarán cuando se cree la rama «B». Si no hay filtros de rutas de archivo, la canalización seguirá iniciándose.

Es posible que las canalizaciones con conexiones que utilicen el filtrado de desencadenadores por rutas de archivo no se inicien cuando se alcance el límite de archivos

Descripción: En el caso de las canalizaciones con acciones de origen que utilizan conexiones, como una acción de BitBucket origen, puedes configurar un activador con una configuración de Git que te permita filtrar por rutas de archivo para iniciar la canalización. CodePipeline recupera hasta los 100 primeros archivos; por lo tanto, si la configuración de Git del desencadenador está configurada para filtrar las rutas de los archivos, es posible que la canalización no se inicie si hay más de 100 archivos. Para obtener más información sobre cómo filtrar las rutas de los archivos, consultaAgregación de desencadenadores con tipos de eventos de solicitud de inserción o extracción de código.

Resultado: por ejemplo, si una diferencia contiene 150 archivos, CodePipeline examina los 100 primeros archivos (sin ningún orden en particular) para compararlos con el filtro de rutas de archivo especificado. Si el archivo que coincide con el filtro de rutas de archivo no se encuentra entre los 100 archivos recuperados CodePipeline, no se invocará la canalización.

CodeCommit o es posible que las revisiones del código fuente de S3 en modo PARALELO no coincidan con el evento EventBridge

Descripción: En el caso de las ejecuciones en canalización en modo PARALLEL, una ejecución puede comenzar con el cambio más reciente, como la confirmación del CodeCommit repositorio, que puede no coincidir con el cambio del EventBridge evento. En algunos casos, cuando entre las confirmaciones o las etiquetas de imagen que inician la canalización transcurre en una fracción de segundo, cuando se CodePipeline recibe el evento y se inicia la ejecución, si se coloca otra etiqueta de confirmación o imagen CodePipeline (por ejemplo, la CodeCommit acción), se clona la confirmación de HEAD en ese momento.

Resultado: en el caso de las canalizaciones en modo PARALELO con una fuente CodeCommit o S3, independientemente del cambio que haya provocado la ejecución de la canalización, la acción de origen siempre clonará el HEAD en el momento en que se inicie. Por ejemplo, para una canalización en modo PARALELO, se inserta una confirmación, que inicia la canalización para la ejecución 1, y la segunda ejecución de la canalización utiliza la segunda confirmación.

La acción de implementación de EC2 falla y aparece el mensaje de error No existe tal archivo

Descripción: una vez que la acción de implementación de EC2 descomprime los artefactos en el directorio de destino de las instancias, la acción ejecuta el script. Si el script está en el directorio de destino pero la acción no puede ejecutarlo, la acción fallará en esa instancia y las instancias restantes no se podrán implementar.

En los registros de una implementación donde el directorio de destino es /home/ec2-user/deploy/ y la ruta del repositorio de origen es myRepo/postScript.sh, aparece un error similar a los siguientes.

Resultado: se produce un error de la acción de implementación en la canalización.

Posibles soluciones: para solucionar el problema, realice estos pasos.

La acción EKS Deploy falla con un mensaje de error inalcanzable para el clúster

Descripción: una vez ejecutada la acción de implementación de EKS, la acción falla con el mensaje de error cluster unreachable. El mensaje muestra un problema de acceso en el clúster debido a la falta de permisos. En función del tipo de archivo (gráfico de Helm o archivo de manifiesto de Kubernetes), el mensaje de error se muestra de la siguiente manera.

Resultado: se produce un error de la acción de implementación en la canalización.

Posibles soluciones: si se usa un rol existente, el rol de CodePipeline servicio debe actualizarse con los permisos necesarios para usar la acción de implementación de EKS. Además, para permitir el acceso del rol de CodePipeline servicio a su clúster, debe agregar una entrada de acceso al clúster y especificar el rol de servicio de la entrada de acceso.

Pipeline no se activa en todas las sucursales cuando varias acciones de origen hacen referencia al mismo repositorio

Problema: una canalización tiene varias acciones de origen que utilizan conexiones (como un Bitbucket o una GitLab conexión), y cada acción de origen apunta a una rama diferente del mismo repositorio. GitHub Solo una de las ramas activa la canalización cuando se introducen cambios. La suscripción a los webhooks de la conexión se registra para la combinación de canalización y repositorio, no por sucursal. Por lo tanto, no se admiten acciones de múltiples fuentes dirigidas a diferentes ramas del mismo repositorio dentro de una misma canalización.

Posibles soluciones: usa una canalización independiente para cada rama que quieras activar de forma independiente.

¿Necesita ayuda con otro problema?

Pruebe estos otros recursos: