You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This document describes the purpose and structure of the GitHub Actions workflow defined in `.github/workflows/aws-frontend-deploy.yml`.
8
+
9
+
## Overview
10
+
11
+
This workflow automates the process of building, pushing, and deploying the frontend application to AWS. It is triggered manually via the GitHub Actions UI using `workflow_dispatch`:
12
+
13
+
```yaml
14
+
on:
15
+
workflow_dispatch: # Manual trigger from GitHub Actions UI
16
+
inputs:
17
+
env:
18
+
type: choice
19
+
description: "AWS Incubator Env"
20
+
options: # Selectable environment options
21
+
- dev
22
+
- prod
23
+
ref:
24
+
description: "Branch, Tag, or SHA"# Code reference to deploy
25
+
required: true
26
+
```
27
+
28
+
Users can select the environment (`dev` or `prod`) and specify a branch, tag, or SHA to deploy.
29
+
30
+
## Environment Variables
31
+
32
+
The workflow sets several environment variables for use throughout the jobs:
33
+
34
+
```yaml
35
+
env:
36
+
AWS_SHARED_CLUSTER: incubator-prod # Target ECS cluster name
37
+
AWS_APP_NAME: vrms-frontend # Application name for tagging and service
38
+
AWS_REGION: us-west-2 # AWS region for deployment
39
+
DOCKERFILE: Dockerfile.prod # Dockerfile used for build
40
+
DOCKER_PATH: client # Path to frontend source and Dockerfile
41
+
```
42
+
43
+
Each of these environment variables is set at the top level of the workflow and is available to all jobs and steps. Here is a description of each:
44
+
45
+
- `AWS_SHARED_CLUSTER`: The name of the AWS ECS cluster to which the frontend will be deployed. In this workflow, it is set to `incubator-prod`. _Might be sourced from your AWS infrastructure naming conventions or deployment environment._
46
+
- `AWS_APP_NAME`: The application name used for tagging Docker images and identifying the service in AWS. Here, it is set to `vrms-frontend`. _Might be sourced from your project or repository name._
47
+
- `AWS_REGION`: The AWS region where resources are deployed. Set to `us-west-2` (Oregon). _Might be sourced from your AWS account's preferred deployment region._
48
+
- `DOCKERFILE`: The Dockerfile used for building the frontend image. Set to `Dockerfile.prod`, indicating a production-ready build. _Might be sourced from your repository's Docker configuration._
49
+
- `DOCKER_PATH`: The path to the directory containing the Dockerfile and frontend source code. Set to `client`. _Might be sourced from your repository structure._
50
+
51
+
## Jobs
52
+
53
+
### 1. `setup_env`
54
+
55
+
This job checks out the code and sets up environment-specific variables for the deployment:
56
+
57
+
```yaml
58
+
jobs:
59
+
setup_env:
60
+
name: Set-up environment
61
+
runs-on: ubuntu-latest
62
+
steps:
63
+
- name: Debug Action
64
+
uses: hmarr/debug-action@v2 # Prints debug info to logs
65
+
- name: Checkout
66
+
uses: actions/checkout@v3 # Checks out code at specified ref
When this workflow runs, it uses the `actions/checkout@v3` action to clone the entire repository. The initial working directory for all steps is the root of the repository.
164
+
165
+
Before building the Docker image, the workflow explicitly changes into the `client` directory using:
166
+
167
+
```bash
168
+
cd ./${{ env.DOCKER_PATH }}
169
+
```
170
+
171
+
This means that for the Docker build step, the working directory is `client/`, and the Dockerfile path `Dockerfile.prod` refers to `client/Dockerfile.prod`.
172
+
173
+
**Summary:**
174
+
175
+
- The workflow clones the entire repository.
176
+
- The working directory starts at the repo root.
177
+
- The workflow changes into the `client` directory before building the Docker image.
178
+
- The Docker build context and Dockerfile are both relative to the `client` directory.
179
+
180
+
## Summary
181
+
182
+
This workflow provides a manual, environment-aware deployment pipeline for the frontend application, leveraging Docker, Amazon ECR, and ECS. It ensures that only the specified code reference is built and deployed, and that deployments are traceable and auditable via GitHub Actions.
0 commit comments