Why 1 out of 4 images isn't pushed into ECR - bash

Question

I could really learn some debugging techniques related to when images fail to be pushed into ECR on AWS.
I've got this "pusher" script:
#!/bin/sh
set -euo pipefail
if [ -z "$GITLAB_PULL_REQUEST" ] || [ "$GITLAB_PULL_REQUEST" == "false" ]
then
if [[ "$GITLAB_BRANCH" == "staging" ]]; then
export DOCKER_ENV=stage
elif [[ "$GITLAB_BRANCH" == "production" ]]; then
export DOCKER_ENV=prod
fi
if [ "$GITLAB_BRANCH" == "staging" ] || \
[ "$GITLAB_BRANCH" == "production" ]
then
curl "https://s3.amazonaws.com/aws-cli/awscli-bundle.zip" -o "awscli-bundle.zip"
unzip awscli-bundle.zip
./awscli-bundle/install -b ~/bin/aws
export PATH=~/bin:$PATH
export AWS_ACCOUNT_ID=27472596600
export AWS_ACCESS_KEY_ID=AKIAJGN7TUVKNORFB2A
export AWS_SECRET_ACCESS_KEY=M8GZei4Bf8aAWpcml1l7vzyedec8FkLWAYBSC7K
eval $(aws ecr get-login --region eu-west-2 --no-include-email)
export TAG=$GITLAB_BRANCH
export REPO=$AWS_ACCOUNT_ID.dkr.ecr.eu-west-2.amazonaws.com
fi
if [ "$GITLAB_BRANCH" == "staging" ] || \
[ "$GITLAB_BRANCH" == "production" ]
then
docker build $USERS_REPO -t $USERS:$COMMIT -f Dockerfile-$DOCKER_ENV
docker tag $USERS:$COMMIT $REPO/$USERS:$TAG
docker push $REPO/$USERS:$TAG # SUCCESSFULLY PUSHED
docker build $USERS_DB_REPO -t $USERS_DB:$COMMIT -f Dockerfile
docker tag $USERS_DB:$COMMIT $REPO/$USERS_DB:$TAG
docker push $REPO/$USERS_DB:$TAG # SUCCESSFULLY PUSHED
docker build $SWAGGER_REPO -t $SWAGGER:$COMMIT -f Dockerfile-$DOCKER_ENV
docker tag $SWAGGER:$COMMIT $REPO/$SWAGGER:$TAG
docker push $REPO/$SWAGGER:$TAG # SUCCESSFULLY PUSHED
docker build $CLIENT_REPO -t $CLIENT:$COMMIT -f Dockerfile-prod --build-arg REACT_APP_USERS_SERVICE_URL=""
docker tag $CLIENT:$COMMIT $REPO/$CLIENT:$TAG
docker push $REPO/$CLIENT:$TAG # LEFT OUT
fi
fi
Don't worry about the creds. They're not valid. I'm using GitLab CI and I can see no errors in the job log.
this is the job log of the image push:
Step 1/20 : FROM node:11.12.0-alpine as builder
---> 09084e4ff58d
Step 2/20 : WORKDIR /usr/src/app
---> Using cache
---> 7ee698668926
Step 3/20 : RUN apk add --no-cache --virtual .gyp python make g++
---> Using cache
---> a9f861b8e62f
Step 4/20 : ENV PATH /usr/src/app/node_modules/.bin:$PATH
---> Using cache
---> 5c3b377be213
Step 5/20 : COPY package.json /usr/src/app/package.json
---> 3a102c4e6b87
Step 6/20 : COPY package-lock.json /usr/src/app/package-lock.json
---> a92e6e57548b
Step 7/20 : RUN npm install --no-optional
---> Running in f62c36ac767e
> cypress#4.1.0 postinstall /usr/src/app/node_modules/cypress
> node index.js --exec install
Installing Cypress (version: 4.1.0)
[10:33:58] Downloading Cypress [started]
[10:33:59] Downloading Cypress 0% 0s [title changed]
[10:33:59] Downloading Cypress 1% 10s [title changed]
[10:33:59] Downloading Cypress 3% 7s [title changed]
[10:33:59] ...
...
[10:34:16] Unzipping Cypress 9% 149s [title changed]
[10:34:18] Unzipping Cypress 9% 172s [title changed]
[10:34:18] Unzipping Cypress 100% 0s [title changed]
[10:34:18] Unzipped Cypress [title changed]
[10:34:18] Unzipped Cypress [completed]
[10:34:18] Finishing Installation [started]
[10:34:18] Finished Installation /root/.cache/Cypress/4.1.0 [title changed]
[10:34:18] Finished Installation /root/.cache/Cypress/4.1.0 [completed]
You can now open Cypress by running: node_modules/.bin/cypress open
https://on.cypress.io/installing-cypress
added 2034 packages from 768 contributors and audited 38602 packages in 78.928s
found 1073 vulnerabilities (1058 low, 14 moderate, 1 high)
run `npm audit fix` to fix them, or `npm audit` for details
Saving cache
Uploading artifacts for successful job
00:01
Job succeeded
What debugging techniques I can use here ? Please ask if there's anything you need to know.

Answer 1

It happens for us as well. Seems like a concurrency problem