Skip to content
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
102 changes: 102 additions & 0 deletions .github/workflows/deploy-lambdas.yml
Original file line number Diff line number Diff line change
@@ -0,0 +1,102 @@
name: Deploy lambdas

on:
workflow_call:
inputs:
ENV:
required: true
type: string
SERVICE:
required: true
type: string
secrets:
SLACK_NOTIFICATION_CI_RUNS:
required: true
ACCESS_TOKEN:
required: true
AWS_ACCESS_KEY_ID:
required: true
AWS_SECRET_ACCESS_KEY:
required: true
AWS_DEFAULT_REGION:
required: true

jobs:
deploy:
name: Deploy Staging Lambdas
runs-on: ubuntu-latest
container:
image: timbru31/node-alpine-git
Copy link
Copy Markdown
Contributor

@mateja176 mateja176 Jun 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that you chose timbru31/node-alpine-git because it based on the official node alpine image with the benefit of having git installed. Do you think that the comfort eliminating the apk install git is worth it compared to using the official node image which offers more version and is more up to date (as a consequence more secure under some circumstances)?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Really I just copied it from the other workflow. @thejamespower made the change I believe - what are your thoughts?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's probably better to use the official one and use apk to add git, I was just being lazy

env:
ENV: ${{ inputs.ENV }}
SERVICE: ${{ inputs.SERVICE }}
ACCESS_TOKEN: ${{ secrets.ACCESS_TOKEN }}
AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
AWS_DEFAULT_REGION: ${{secrets.AWS_DEFAULT_REGION}}
SLACK_NOTIFICATION_CI_RUNS: ${{ secrets.SLACK_NOTIFICATION_CI_RUNS }}
steps:
- name: Clone repository
uses: actions/checkout@v2
- name: Set NodeJS
uses: actions/setup-node@v2
with:
node-version-file: .nvmrc
cache: npm
- name: 'NPM: Add Config and Authorization'
run: |
rm -f .npmrc
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The .npmrc file might not exist which would cause rm to exit with a non-zero exit code. Also redirecting the echo command output below, using >, will surely override the contents of .npmrc.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK the -f flag means that if it doesn't exist it won't error. Also as I remember I had found that > wasn't overriding the original file... quite likely I made some sort of mistake though

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're right about the -f flag. Although it can also be used for ignoring confirmation prompts and similar. The redirection should work on the other hand. One possibility is that the original .npmrc file is protected and as such cannot be overriden, thus must be forcefully removed and recreated. Though I don't think that's likely.

echo "@emritio:registry=https://npm.pkg.github.com/" > .npmrc
echo "//npm.pkg.github.com/:_authToken=${PAT}" >> .npmrc
env:
PAT: ${{ secrets.ACCESS_TOKEN }}
# - name: Add git safe directory
# run: git config --global --add safe.directory /__w/${PWD##*/}/${PWD##*/}
# - name: Semantic Release
# uses: cycjimmy/semantic-release-action@v3
# env:
# GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# with:
# semantic_version: 19
# - name: Get previous tag
# id: previoustag
# uses: 'WyriHaximus/github-action-get-previous-tag@v1'
# - name: Set TAG_TO_DEPLOY
# env:
# VERSION: ${{ steps.previoustag.outputs.tag }}
# run: |
# echo "TAG_TO_DEPLOY=${VERSION}" >> $GITHUB_ENV
# - name: Checkout tag
# run: |
# git checkout tags/${TAG_TO_DEPLOY}
- name: Configuration
env:
AWS_CLI_VERSION: 1.18.101
DOCKER_VERSION: 20.10.11-r1
run: |
apk update
apk add --no-cache curl bash coreutils py3-pip git zip
ln -s /usr/share/zoneinfo/UTC /etc/localtime
apk add --no-cache docker==${DOCKER_VERSION}
pip3 install awscli==${AWS_CLI_VERSION}
- name: Start deployment slack notification
run: |
curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"The $SERVICE service(s) deployment on $ENV environment has begun.\n \"}" \
$SLACK_NOTIFICATION_CI_RUNS
- name: Build project
env:
NODE_AUTH_TOKEN: ${{ secrets.PACKAGES_ACCESS_TOKEN }}
run: |
rm -rf node_modules
npm ci
npm run build
rm -rf node_modules
npm ci --only=production --ignore-scripts
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The --only-production option is not referenced in the documentation. Would you go along with removing it?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah looks like npm prune --production is a better option for what they're trying to do

Copy link
Copy Markdown
Contributor

@mateja176 mateja176 Jun 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Interesting remark. In summary, since NODE_ENV is not set to production, npm ci will install devDepedencies which are required to build. Afterwards, they can be removed via npm prune --production. Consequently, rm -rf node_modules is redundant.

Copy link
Copy Markdown
Contributor

@mateja176 mateja176 Jun 27, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Additionally, in case that all depdencies, including devDependencies are installed, running cross-env NODE_ENV=production npm ci will result in the removal of devDependencies. However, semantically spreaking, the prune command makes much more sense.
On the other hand, considering that npm ci will override versions based on the current values specfied in package.json and package-lock.json, the first rm -rf node_modules command is redundant as well.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

npm prune didn't work as I expected and we were left with a massive zip

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please reference npm-prune demo.

- name: Zip code
run: |
zip -r event_handler_lambda.zip *
- name: Update event handler lambda
run: |
aws lambda update-function-code --function-name emrit-$ENV-$SERVICE --zip-file fileb://event_handler_lambda.zip --publish
aws lambda wait function-updated --function-name emrit-$ENV-$SERVICE