Skip to content

Commit 9d1fac7

Browse files
kschelonkakschelonka
authored
feat(deploy): add automated dev deployment (#6397)
Branch protection rule prevents external contributors from pushing to dev.
1 parent 975d58d commit 9d1fac7

File tree

2 files changed

+110
-2
lines changed

2 files changed

+110
-2
lines changed

‎.github/workflows/docker_build_deploy_dev.yml‎

Lines changed: 96 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,96 @@
1+
name: Build Docker image and publish to GAR (Dev)
2+
3+
# Actions in this repository could be streamlined with
4+
# reusable workflows (significant refactor)
5+
permissions: {}
6+
7+
on:
8+
push:
9+
branches:
10+
- dev
11+
12+
jobs:
13+
build_and_push_to_gar:
14+
# Define permissions at the job level
15+
permissions:
16+
contents: "read" # Needed for checkout
17+
id-token: "write" # Needed for GCP auth
18+
packages: "none" # Explicitly disable package permissions
19+
name: Build and Push Docker image to GAR
20+
runs-on: ubuntu-latest
21+
environment: build
22+
env:
23+
GAR_IMAGE_BASE: ${{ vars.GAR_REPO }}/${{ github.event.repository.name }} # Base name for GAR image
24+
GAR_REGISTRY: us-docker.pkg.dev
25+
steps:
26+
- name: Check out the repo
27+
uses: actions/checkout@v6
28+
with:
29+
persist-credentials: false
30+
31+
- name: Authenticate to Google Cloud
32+
id: gcp-auth
33+
uses: google-github-actions/auth@v3
34+
with:
35+
token_format: access_token
36+
workload_identity_provider: ${{ vars.GCPV2_GITHUB_WORKLOAD_IDENTITY_PROVIDER }}
37+
service_account: ${{ vars.GCP_GAR_SERVICE_ACCOUNT }}
38+
39+
- name: Login to Artifact Registry
40+
id: gar-login
41+
uses: docker/login-action@v3
42+
with:
43+
registry: ${{ env.GAR_REGISTRY }}
44+
username: oauth2accesstoken
45+
password: ${{ steps.gcp-auth.outputs.access_token }}
46+
47+
- name: Extract metadata (tags, labels) for Docker
48+
id: meta
49+
uses: docker/metadata-action@v5
50+
with:
51+
# Only generate the image name for GAR
52+
images: ${{ env.GAR_IMAGE_BASE }}
53+
tags: |
54+
# Generate tag based on short commit SHA
55+
type=sha,format=short,prefix=dev-
56+
57+
- name: Create version.json
58+
run: |
59+
# Use full sha here for version.json content
60+
echo "{\"commit\":\"$GITHUB_SHA\",\"version\":\"$GITHUB_REF_NAME\",\"source\":\"https://github.com/$GITHUB_REPOSITORY\",\"build\":\"$GITHUB_RUN_ID\"}" > version.json
61+
62+
- name: Set up QEMU
63+
uses: docker/setup-qemu-action@v3
64+
65+
- name: Set up Docker Buildx
66+
id: buildx
67+
uses: docker/setup-buildx-action@v3
68+
69+
- name: Build and push Docker image to GAR
70+
id: build-and-push
71+
env:
72+
TAGS: ${{ steps.meta.outputs.tags }}
73+
uses: docker/build-push-action@v6
74+
with:
75+
context: .
76+
# Push is true to push to GAR after build
77+
push: true
78+
# Tags generated by the metadata action (only GAR tag)
79+
tags: ${{ env.TAGS }}
80+
# Pass build arguments
81+
build-args: |
82+
SENTRY_RELEASE=${{ github.sha }}
83+
NEXT_PUBLIC_SENTRY_DSN=${{ secrets.SENTRY_DSN }}
84+
SENTRY_DSN=${{ secrets.SENTRY_DSN }}
85+
# Pass secrets securely to the build
86+
secrets: |
87+
SENTRY_AUTH_TOKEN=${{ secrets.SENTRY_AUTH_TOKEN }}
88+
# Enable build cache for faster builds (optional but recommended)
89+
cache-from: type=gha
90+
cache-to: type=gha,mode=max
91+
92+
- name: Print Image URI
93+
env:
94+
TAGS: ${{ steps.meta.outputs.tags }}
95+
run: |
96+
echo "Pushed GAR image: $TAGS"

‎docs/release_process.md‎

Lines changed: 14 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,6 +4,7 @@
44

55
- [Production][prod] - Run manually by ENGR team (unless we need Env Var or other infrastructure changes)
66
- [Stage][stage] - Run automatically on PR merges
7+
- [Dev][dev] - Run automatically on push to `dev` branch (restricted to ENGR team)
78
- Locals: Run by ENGRs on their own devices. (See [README][readme] and other [`docs/`][docs].)
89

910
## Development
@@ -63,6 +64,16 @@ The standard release interval for Monitor is one week, meaning there should be a
6364

6465
Every commit to `main` is automatically deployed to the [Stage][stage] server via Github Actions. The image is built and uploaded to Google Artifact Registry. ArgoCD scans the registry and detects whenever a new image uploaded with a tag that is a short commit SHA. When one is detected, it triggers a new deployment. This is configured via the [Monitor tenant definition](https://github.com/mozilla/global-platform-admin/blob/main/tenants/monitor.yaml).
6566

67+
## Release to Dev
68+
69+
Every commit to `dev` branch is automatically deployed to the [Dev][dev] server via Github Actions. The image is built and uploaded to Google Artifact Registry. ArgoCD scans the registry and detects whenever a new image uploaded with a tag that is a short commit SHA prefixed by `dev-`. When one is detected, it triggers a new deployment. This is configured via the [Monitor tenant definition](https://github.com/mozilla/global-platform-admin/blob/main/tenants/monitor.yaml).
70+
71+
Before committing to `dev`, it's good practice to notify the team in slack in case someone is actively testing with the dev deployment.
72+
73+
Pushing to this branch is restricted to internal contributors.
74+
75+
Note that the dev deployment is protected by IAP and requires Mozilla credentials to access.
76+
6677
### PR Merges
6778

6879
PRs can only be merged once they pass all the required checks:
@@ -150,8 +161,8 @@ Note the following caveats:
150161

151162
- All production releases must follow the date tag naming scheme or else they will not be deployed. The regex for image deployments is in the [monitor tenant definition file](https://github.com/mozilla/global-platform-admin/blob/main/tenants/monitor.yaml).
152163
- Example: `2024.09.01`; also can include additional numeric suffix preceded by a period, e.g. `2024.09.01.1` (for manually created deployments, typically hotfixes)
153-
- You can deploy to dev with this flow. Select "dev" from the environment dropdown menu and ensure the tag you input is a (previously deployed) short commit SHA, not one of the date tags.
154-
- Only commits which have already been deployed to staging can be released to development or production environments. In practice this means that you cannot and should not attempt to deploy from a tag created on a release branch
164+
- You can deploy to dev with this flow, but it's recommended to use the `dev` branch instead (see [Release To Dev](#release-to-dev)). Select "dev" from the environment dropdown menu and ensure the tag you input is a (previously deployed) short commit SHA, not one of the date tags.
165+
- Only commits which have already been deployed to staging can be released to development or production environments with this flow. In practice this means that you cannot and should not attempt to deploy from a tag created on a release branch.
155166
<!--
156167
Note: The reason that this is the case currently is due to a race condition with the on-push triggered jobs release_retag_v2 and docker_build_deploy_v2. The release_retag_v2 action attempts to pull an image uploaded by docker_build_deploy_v2 immediately, even though the job is not complete. However, the new tag _will_ create a staging release (tagged by the short commit SHA) that will override the current staging environment. This could result in confusion about the state of staging environment and commit verification by QA.
157168
@@ -205,6 +216,7 @@ After adding 1-click production deploy capability and broadly adopting [feature
205216

206217
[prod]: https://monitor.firefox.com/
207218
[stage]: https://stage.firefoxmonitor.nonprod.cloudops.mozgcp.net/
219+
[dev]: https://dev.monitor.nonprod.webservices.mozgcp.net/
208220
[readme]: https://github.com/mozilla/blurts-server/blob/main/README.md
209221
[docs]: https://github.com/mozilla/blurts-server/tree/main/docs
210222
[github-flow]: https://docs.github.com/en/get-started/quickstart/github-flow

0 commit comments

Comments
 (0)