Estoy implementando el front-end de mi sitio web en amazon s3 a través de canalizaciones de Gitlab. Mis implementaciones anteriores han funcionado correctamente, pero las implementaciones más recientes no. Aquí está el error:
Completed 12.3 MiB/20.2 MiB (0 Bytes/s) with 1 file(s) remaining upload failed: dist/vendor.bundle.js.map to s3://<my-s3-bucket-name>/vendor.bundle.js.map Unable to locate credentials Bajo mis variables secretas he definido cuatro. Son variables de credenciales de S3 (AWS_ACCESS_KEY_ID & AWS_SECRET_ACCESS_KEY) para dos depósitos diferentes. Un par es para la rama de prueba y el otro es para la rama de producción .
No: las variables del entorno de producción están protegidas y las demás variables no. Aquí está el script de implementación que ejecuto:
#/bin/bash #upload files aws s3 cp ./dist s3://my-url-$1 --recursive --acl public-readEntonces, ¿por qué recibo este error de ubicación de credenciales? Seguramente debería recoger las variables de entorno automáticamente (las desprotegidas) e implementarlas. ¿Necesito definir las variables en el trabajo y referirme a ellas?
(Encontré este problema muchas veces, agregando otra respuesta para las personas que tienen el mismo error, por otras razones).
Una lista de verificación rápida.
Vaya a Configuración -> CI/CD -> Variables y verifique:
AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY .protected , solo se pueden ejecutar en ramas protected (como master ).Si el error aún ocurre:
AWS_SECRET_ACCESS_KEY no contenga ningún carácter especial (puede generar errores extraños).El problema real fue una colisión relacionada con el nombre de las variables. Para ambas ramas, las variables se denominaron AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY . Sin embargo, el problema no era solo cambiarles el nombre, ya que la canalización todavía no los recogía.
Imprimí la contraseña en los registros para determinar qué contraseña estaba siendo seleccionada por qué rama, pero descubrí que ninguna de las dos estaba siendo utilizada. La solución fue tener un nombre único para cada contraseña de cada rama (p. ej., PRODUCTION_ACCESS_KEY_ID y TESTING_ACCESS_KEY_ID ) y en el script de compilación hacer referencia a ellos:
deploy_app_production: environment: name: production url: <url> before_script: - echo "Installing ruby & dpl" - apt-get update && apt-get install -y ruby-full - gem install dpl stage: deploy tags: - nv1 script: - echo "Deploying to production" - sh deploy.sh production $PRODUCTION_ACCESS_KEY_ID $PRODUCTION_SECRET_ACCESS_KEY only: - master Y en deploy.sh me referí a las variables pasadas (aunque terminé cambiando a dpl ):
dpl --provider=s3 --access-key-id=$2 --secret-access-key=$3 --bucket=<my-bucket-name>-$1 --region=eu-west-1 --acl=public_read --local-dir=./dist --skip_cleanup=true¿Ha intentado ejecutar la imagen de Docker que usa en su secuencia de comandos de canalizaciones de GitLab localmente, en modo interactivo?
De esa manera, podría verificar que las variables de entorno que no se detectan son el problema. (Es decir, si establece las mismas variables de entorno localmente y funciona, entonces sí, ese es el problema).
Sospecho que tal vez las credenciales se recojan bien y tal vez simplemente no tengan todos los permisos necesarios para realizar la operación solicitada. Sé que el mensaje de error dice lo contrario, pero los mensajes de error de S3 tienden a ser bastante engañosos cuando se trata de problemas de permisos.