feat(deploy): add automated dev deployment

.github/workflows/docker_build_deploy_dev.yml

@@ -0,0 +1,96 @@
+name: Build Docker image and publish to GAR (Dev)
+
+# Actions in this repository could be streamlined with
+# reusable workflows (significant refactor)
+permissions: {}
+
+on:
+  push:
+    branches:
+      - dev
+
+jobs:
+  build_and_push_to_gar:
+    # Define permissions at the job level
+    permissions:
+      contents: "read" # Needed for checkout
+      id-token: "write" # Needed for GCP auth
+      packages: "none" # Explicitly disable package permissions
+    name: Build and Push Docker image to GAR
+    runs-on: ubuntu-latest
+    environment: build
+    env:
+      GAR_IMAGE_BASE: ${{ vars.GAR_REPO }}/${{ github.event.repository.name }} # Base name for GAR image
+      GAR_REGISTRY: us-docker.pkg.dev
+    steps:
+      - name: Check out the repo
+        uses: actions/checkout@v6
+        with:
+          persist-credentials: false
+
+      - name: Authenticate to Google Cloud
+        id: gcp-auth
+        uses: google-github-actions/auth@v3
+        with:
+          token_format: access_token
+          workload_identity_provider: ${{ vars.GCPV2_GITHUB_WORKLOAD_IDENTITY_PROVIDER }}
+          service_account: ${{ vars.GCP_GAR_SERVICE_ACCOUNT }}
+
+      - name: Login to Artifact Registry
+        id: gar-login
+        uses: docker/login-action@v3
+        with:
+          registry: ${{ env.GAR_REGISTRY }}
+          username: oauth2accesstoken
+          password: ${{ steps.gcp-auth.outputs.access_token }}
+
+      - name: Extract metadata (tags, labels) for Docker
+        id: meta
+        uses: docker/metadata-action@v5
+        with:
+          # Only generate the image name for GAR
+          images: ${{ env.GAR_IMAGE_BASE }}
+          tags: |
+            # Generate tag based on short commit SHA
+            type=sha,format=short,prefix=dev-
+
+      - name: Create version.json
+        run: |
+          # Use full sha here for version.json content
+          echo "{\"commit\":\"$GITHUB_SHA\",\"version\":\"$GITHUB_REF_NAME\",\"source\":\"https://github.com/$GITHUB_REPOSITORY\",\"build\":\"$GITHUB_RUN_ID\"}" > version.json
+
+      - name: Set up QEMU
+        uses: docker/setup-qemu-action@v3
+
+      - name: Set up Docker Buildx
+        id: buildx
+        uses: docker/setup-buildx-action@v3
+
+      - name: Build and push Docker image to GAR
+        id: build-and-push
+        env:
+          TAGS: ${{ steps.meta.outputs.tags }}
+        uses: docker/build-push-action@v6
+        with:
+          context: .
+          # Push is true to push to GAR after build
+          push: true
+          # Tags generated by the metadata action (only GAR tag)
+          tags: ${{ env.TAGS }}
+          # Pass build arguments
+          build-args: |
+            SENTRY_RELEASE=${{ github.sha }}
+            NEXT_PUBLIC_SENTRY_DSN=${{ secrets.SENTRY_DSN }}
+            SENTRY_DSN=${{ secrets.SENTRY_DSN }}
+          # Pass secrets securely to the build
+          secrets: |
+            SENTRY_AUTH_TOKEN=${{ secrets.SENTRY_AUTH_TOKEN }}
+          # Enable build cache for faster builds (optional but recommended)
+          cache-from: type=gha
+          cache-to: type=gha,mode=max
+
+      - name: Print Image URI
+        env:
+          TAGS: ${{ steps.meta.outputs.tags }}
+        run: |
+          echo "Pushed GAR image: $TAGS"

docs/release_process.md

@@ -4,6 +4,7 @@
 
 - [Production][prod] - Run manually by ENGR team (unless we need Env Var or other infrastructure changes)
 - [Stage][stage] - Run automatically on PR merges
+- [Dev][dev] - Run automatically on push to `dev` branch (restricted to ENGR team)
 - Locals: Run by ENGRs on their own devices. (See [README][readme] and other [`docs/`][docs].)
 
 ## Development
@@ -63,6 +64,16 @@ The standard release interval for Monitor is one week, meaning there should be a
 
 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).
 
+## Release to Dev
+
+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).
+
+Before committing to `dev`, it's good practice to notify the team in slack in case someone is actively testing with the dev deployment.
+
+Pushing to this branch is restricted to internal contributors.
+
+Note that the dev deployment is protected by IAP and requires Mozilla credentials to access.
+
 ### PR Merges
 
 PRs can only be merged once they pass all the required checks:
@@ -150,8 +161,8 @@ Note the following caveats:
 
 - 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).
   - 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)
-- 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.
-- 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
+- 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.
+- 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.
 <!-- 
 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.
 
@@ -205,6 +216,7 @@ After adding 1-click production deploy capability and broadly adopting [feature
 
 [prod]: https://monitor.firefox.com/
 [stage]: https://stage.firefoxmonitor.nonprod.cloudops.mozgcp.net/
+[dev]: https://dev.monitor.nonprod.webservices.mozgcp.net/
 [readme]: https://github.com/mozilla/blurts-server/blob/main/README.md
 [docs]: https://github.com/mozilla/blurts-server/tree/main/docs
 [github-flow]: https://docs.github.com/en/get-started/quickstart/github-flow