Amplify-console: Update Amplify CLI version in Docker file?

Created on 11 Aug 2020 · 2Comments · Source: aws-amplify/amplify-console

Hey :wave:

I've noticed that my "cloning repository" step always has these entries per build:

2020-08-10T20:21:22.597Z [INFO]: # Ensuring NPM package '@aws-amplify/cli' is version: 'latest'
2020-08-10T20:21:29.721Z [INFO]: # Patching NPM package '@aws-amplify/cli' from 1.12.0 to 4.27.0...

And was wondering why it would have version 1.12.0 at all, that seemed strange to me. Turns out: In the provisioning step, this version is being installed – just to be updated one step later :smile:

I'm not sure whether the file is the correct one, but this Docker file here: https://github.com/aws-amplify/amplify-console/blob/master/images/latest/Dockerfile#L15 seems to be very, very similar to what is used on my EU-Central-1 app.

My provisioning step output

# Use the standard Amazon Linux base, provided by ECR/KaOS
# It points to the standard shared Amazon Linux image, with a versioned tag.
FROM 137112412989.dkr.ecr.us-west-2.amazonaws.com/amazonlinux:2
MAINTAINER Amazon AWS

# Framework Versions

ENV VERSION_NODE_8=8.12.0
ENV VERSION_NODE_10=10.16.0
ENV VERSION_NODE_12=12
ENV VERSION_NODE_DEFAULT=$VERSION_NODE_10
ENV VERSION_RUBY_2_4=2.4.6
ENV VERSION_RUBY_2_6=2.6.3
ENV VERSION_BUNDLER=2.0.1
ENV VERSION_RUBY_DEFAULT=$VERSION_RUBY_2_4
ENV VERSION_HUGO=0.55.6
ENV VERSION_YARN=1.16.0
ENV VERSION_AMPLIFY=1.12.0

# UTF-8 Environment

ENV LANGUAGE en_US:en
ENV LANG=en_US.UTF-8
ENV LC_ALL en_US.UTF-8

## Install OS packages

RUN touch ~/.bashrc
RUN yum -y update && \
 yum -y install \
 alsa-lib-devel \
 autoconf \
 automake \
 bzip2 \
 bison \
 bzr \
 cmake \
 expect \
 fontconfig \
 git \
 gcc-c++ \
 GConf2-devel \
 gtk2-devel \
 gtk3-devel \
 libnotify-devel \
 libpng \
 libpng-devel \
 libffi-devel \
 libtool \
 libX11 \
 libXext \
 libxml2 \
 libxml2-devel \
 libXScrnSaver \
 libxslt \
 libxslt-devel \
 libyaml \
 libyaml-devel \
 nss-devel \
 openssl-devel \
 openssh-clients \
 patch \
 procps \
 python3 \
 python3-devel \
 readline-devel \
 sqlite-devel \
 tar \
 tree \
 unzip \
 wget \
 which \
 xorg-x11-server-Xvfb \
 zip \
 zlib \
 zlib-devel \
 yum clean all && \
 rm -rf /var/cache/yum

## Install Node 8 & 10 & 12

RUN curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh | bash
RUN curl -o- -L https://yarnpkg.com/install.sh > /usr/local/bin/yarn-install.sh
RUN /bin/bash -c ". ~/.nvm/nvm.sh && \
 nvm install $VERSION_NODE_8 && nvm use $VERSION_NODE_8 && \
 nvm install $VERSION_NODE_10 && nvm use $VERSION_NODE_10 && \
 npm install -g sm grunt-cli bower vuepress gatsby-cli && \
 bash /usr/local/bin/yarn-install.sh --version $VERSION_YARN && \
    nvm install $VERSION_NODE_12 && nvm use $VERSION_NODE_12 && \
    npm install -g sm grunt-cli bower vuepress gatsby-cli && \
    bash /usr/local/bin/yarn-install.sh --version $VERSION_YARN && \
 nvm alias default node && nvm cache clear"

## Install Ruby 2.4.x and 2.6.x

RUN gpg --keyserver hkp://pool.sks-keyservers.net --recv-keys 409B6B1796C275462A1703113804BB82D39DC0E3 7D2BAF1CF37B13E2069D6956105BD0E739499BDB && \
 curl -sL https://get.rvm.io | bash -s -- --with-gems="bundler"

ENV PATH /usr/local/rvm/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
RUN /bin/bash --login -c "\
 rvm install $VERSION_RUBY_2_4 && rvm use $VERSION_RUBY_2_4 && gem install bundler -v $VERSION_BUNDLER && gem install jekyll && \
    rvm install $VERSION_RUBY_2_6 && rvm use $VERSION_RUBY_2_6 && gem install bundler -v $VERSION_BUNDLER && gem install jekyll && \
 rvm cleanup all"

## Install awscli

RUN /bin/bash -c "pip3 install awscli && rm -rf /var/cache/apk/\*"

## Install SAM CLI

RUN /bin/bash -c "pip3 install aws-sam-cli"

## Install Hugo

RUN wget https://github.com/gohugoio/hugo/releases/download/v${VERSION_HUGO}/hugo_${VERSION_HUGO}_Linux-64bit.tar.gz && \
 tar -xf hugo*\${VERSION_HUGO}\_Linux-64bit.tar.gz hugo -C / && \
 mv /hugo /usr/bin/hugo && \
 rm -rf hugo*\${VERSION_HUGO}\_Linux-64bit.tar.gz

## Installing Cypress

RUN /bin/bash -c ". ~/.nvm/nvm.sh && \
 nvm use \${VERSION_NODE_DEFAULT} && \
 npm install -g --unsafe-perm=true --allow-root cypress"

## Install AWS Amplify CLI for VERSION_NODE_DEFAULT and VERSION_NODE_10

RUN /bin/bash -c ". ~/.nvm/nvm.sh && nvm use ${VERSION_NODE_DEFAULT} && \
    npm install -g @aws-amplify/cli@${VERSION_AMPLIFY}"
RUN /bin/bash -c ". ~/.nvm/nvm.sh && nvm use ${VERSION_NODE_10} && \
    npm install -g @aws-amplify/cli@${VERSION_AMPLIFY}"

## Environment Setup

RUN echo export PATH="\
/usr/local/rvm/gems/ruby-${VERSION_RUBY_DEFAULT}/bin:\
/usr/local/rvm/gems/ruby-${VERSION_RUBY_DEFAULT}@global/bin:\
/usr/local/rvm/rubies/ruby-${VERSION_RUBY_DEFAULT}/bin:\
/usr/local/rvm/bin:\
/root/.yarn/bin:\
/root/.config/yarn/global/node_modules/.bin:\
/root/.nvm/versions/node/${VERSION_NODE_DEFAULT}/bin:\
$(python3 -m site --user-base)/bin:\
$PATH" >> ~/.bashrc && \
 echo export GEM_PATH="/usr/local/rvm/gems/ruby-${VERSION_RUBY_DEFAULT}" >> ~/.bashrc && \
    echo "nvm use ${VERSION_NODE_DEFAULT} 1> /dev/null" >> ~/.bashrc

ENTRYPOINT [ "bash", "-c" ]

I have no idea about the impact this could have, but could you try updating the Amplify CLI version in the Docker file? This seems to be unnecessary work for every build in probably every Amplify app. You know, save trees and stuff 🌳 😊

Also, here's a Twitter thread discussing this issue with @sw-yx :) https://twitter.com/HerrBertling/status/1292923253846155264

backend question

Source

HerrBertling

👍1

All 2 comments

Thanks for pointing this out @HerrBertling ! The short answer is that your builds simply run faster if we force patch the CLI to the latest version each time than if we were to update our Docker file (and resulting built image) each time the CLI changes. Longer answer, our image builds must coincide with a scheduled caching run to make sure that our Docker file build image is cached and the Provisioning step runs in about 1/5 the time it would vs if it were not cached. If we were to update the Docker file & built image as often as the CLI versions change, we would miss this caching run most of the time, and your builds would take (noticeably) longer than a cached image with automatic patching. It's on our backlog to develop a better process for this, in the meantime, the force CLI patch for Amplify apps with a backend is what you'll see.