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
Copy file name to clipboardExpand all lines: .github/workflows/README.md
+40-19Lines changed: 40 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -2,32 +2,36 @@
2
2
3
3
## Overview
4
4
5
-
The `build-and-push-image.yaml` workflow builds the storefront Docker image and pushes it to Amazon ECR when changes are merged to the `main` branch via PR.
5
+
The `build-and-push-image.yaml` workflow builds the storefront Docker image and
6
+
pushes it to Amazon ECR when changes are merged to the `main` branch via PR.
|`AWS_ACCOUNT_ID`| AWS account ID for ECR |`123456789012`|
24
+
|`AWS_REGION`| ECR region |`sa-east-1`|
25
+
| — | ECR repository name is taken from `DECO_SITE_NAME` in the Dockerfile (no need to set) | —|
24
26
25
27
### 2. AWS authentication
26
28
27
29
**Option A - OIDC (recommended):**
28
30
29
-
1. Configure OIDC in AWS per [GitHub docs](https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services)
30
-
2. Create an IAM role with ECR permissions (`ecr:GetAuthorizationToken`) and push policy
@@ -36,39 +40,56 @@ The `build-and-push-image.yaml` workflow builds the storefront Docker image and
36
40
2. In **Settings > Secrets and variables > Actions > Secrets**, add:
37
41
-`ECR_CI_AWS_ACCESS_KEY_ID`
38
42
-`ECR_CI_AWS_SECRET_ACCESS_KEY`
39
-
3. The workflow uses Access Keys by default; for OIDC, comment out the Access Keys step and uncomment the OIDC step
43
+
3. The workflow uses Access Keys by default; for OIDC, comment out the Access
44
+
Keys step and uncomment the OIDC step
40
45
41
46
### 3. ECR repository
42
47
43
-
The repository name is taken from `DECO_SITE_NAME` in the Dockerfile. The pipeline checks if the repo exists and **creates it automatically on first run** if not. No need to create it manually.
48
+
The repository name is taken from `DECO_SITE_NAME` in the Dockerfile. The
49
+
pipeline checks if the repo exists and **creates it automatically on first run**
50
+
if not. No need to create it manually.
44
51
45
-
The IAM role/user must have: `ecr:CreateRepository`, `ecr:DescribeRepositories`, `ecr:SetRepositoryPolicy`, and standard push permissions (`ecr:GetAuthorizationToken`, `ecr:BatchCheckLayerAvailability`, `ecr:PutImage`, etc.).
52
+
The IAM role/user must have: `ecr:CreateRepository`, `ecr:DescribeRepositories`,
53
+
`ecr:SetRepositoryPolicy`, and standard push permissions
### 4. Cross-account policy (optional, no account IDs in repo)
48
58
49
-
To allow **cross-account pull** (and write/Lambda per your policy) **without putting account IDs in the public repo**, use a variable:
59
+
To allow **cross-account pull** (and write/Lambda per your policy) **without
60
+
putting account IDs in the public repo**, use a variable:
50
61
51
-
1. In **Settings > Secrets and variables > Actions > Variables**, create the variable **`ECR_REPOSITORY_POLICY_JSON`**.
52
-
2. Paste as value the full ECR repository policy JSON (including ARNs with account IDs and, if used, the `LambdaECRImageCrossAccountRetrievalPolicy` condition).
62
+
1. In **Settings > Secrets and variables > Actions > Variables**, create the
63
+
variable **`ECR_REPOSITORY_POLICY_JSON`**.
64
+
2. Paste as value the full ECR repository policy JSON (including ARNs with
65
+
account IDs and, if used, the `LambdaECRImageCrossAccountRetrievalPolicy`
66
+
condition).
53
67
54
-
The workflow applies this policy **only on the first run**, when the ECR repository is created. On subsequent runs the step is skipped. If the variable is not set, the step is skipped and no custom policy is applied.
68
+
The workflow applies this policy **only on the first run**, when the ECR
69
+
repository is created. On subsequent runs the step is skipped. If the variable
70
+
is not set, the step is skipped and no custom policy is applied.
55
71
56
72
## Resulting image
57
73
58
74
-**Multi-arch**: linux/amd64 and linux/arm64 (manifest list created by buildx)
-**Semantic tag**: `{registry}/storefront:1.0.0` (patch auto-incremented per
76
+
release: 1.0.0 → 1.0.1 → 1.0.2)
60
77
-**Latest tag**: `{registry}/storefront:latest`
61
78
-**Build arg**`GIT_REVISION`: full commit SHA (for traceability)
62
79
63
80
## GitHub Release
64
81
65
82
On each successful build, a release is created in the repo with:
83
+
66
84
- Tag in the form `v1.0.0`
67
85
- Auto-generated release notes
68
86
- Reference to the Docker image published to ECR
69
87
70
-
The next version number is derived from the latest existing tag (patch increment).
88
+
The next version number is derived from the latest existing tag (patch
89
+
increment).
71
90
72
91
## Monorepo
73
92
74
-
If the storefront lives in a monorepo (subdirectory), move the workflow to `.github/workflows/` at the repo root and adjust `paths` and Docker `context`/`file` to include the `storefront/` prefix.
93
+
If the storefront lives in a monorepo (subdirectory), move the workflow to
94
+
`.github/workflows/` at the repo root and adjust `paths` and Docker
95
+
`context`/`file` to include the `storefront/` prefix.
0 commit comments