Deploy in CI #9
Deploy in CI #9
Conversation
WalkthroughReplaced static dev container configuration with a Jinja2 template to support multiple environments. Enhanced CI workflow to build frontend artifacts and deploy to production via Pulumi. Added artifact download capability to Pulumi workflow for deployment access to built artifacts. Changes
Sequence DiagramsequenceDiagram
participant GHA as GitHub Actions
participant FB as Frontend Build
participant Artifact Store as Artifact Store
participant Pulumi as Pulumi Deploy
GHA->>FB: Trigger build-app-frontend job
FB->>FB: Build frontend app
FB->>Artifact Store: Upload artifact
Artifact Store-->>FB: Artifact stored
Note over GHA: Merge/PR/Main detected
GHA->>Pulumi: Trigger pulumi-prod job
Pulumi->>Artifact Store: Download artifact<br/>(DOWNLOAD_ARTIFACT_NAME)
Artifact Store-->>Pulumi: Extract to path<br/>(DOWNLOAD_ARTIFACT_PATH)
Pulumi->>Pulumi: Deploy to production<br/>with frontend artifact
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes
Pre-merge checks❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
📜 Recent review detailsConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro 📒 Files selected for processing (4)
💤 Files with no reviewable changes (1)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (4)
🔇 Additional comments (4)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Pull request overview
This PR enables automated deployment through the CI pipeline by adding frontend build capabilities and production deployment workflow. The changes introduce a build step for the app frontend, artifact management for deployment, and a production deployment job that triggers on pull requests (for preview) and automatically deploys on merges to main.
Key changes:
- Added
build-app-frontendjob to build and upload frontend static assets - Added
pulumi-prodjob for production infrastructure preview and deployment - Extended
pulumi-aws.ymlworkflow to support downloading build artifacts
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| template/.github/workflows/pulumi-aws.yml | Added inputs and step for downloading build artifacts from upstream jobs |
| template/.github/workflows/ci.yaml.jinja | Added frontend build job, production deployment job, pull_request trigger, and updated required-check dependencies |
| template/.devcontainer/envs.json.jinja | Converted envs.json to Jinja template and added app-frontend environment configuration |
| template/.devcontainer/envs.json | Removed in favor of Jinja template version |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| DOWNLOAD_ARTIFACT_NAME: app-frontend-static-assets | ||
| DOWNLOAD_ARTIFACT_PATH: {% endraw %}{{ app_name }}{% raw %}_app/.output/public/{% endraw %}{% endif %}{% raw %} |
There was a problem hiding this comment.
The plan-to-staging job references the app-frontend-static-assets artifact here but is missing a dependency on the build-app-frontend job that creates this artifact. The job currently only depends on lint (line 64), but it should also depend on build-app-frontend. Without this dependency, the artifact download will fail because the artifact won't be available yet.
The needs array at line 64 should be changed to: needs: [ lint, build-app-frontend ]
| python-version: ${{ inputs.PYTHON_VERSION }} | ||
|
|
||
| - name: Download Artifact | ||
| uses: actions/[email protected] |
There was a problem hiding this comment.
The hardcoded version v6.0.0 for actions/download-artifact is inconsistent with the pattern used in the codebase. The actions/upload-artifact in ci.yaml.jinja uses a template variable {{ gha_upload_artifact }} for version management. Consider creating a similar variable (e.g., {{ gha_download_artifact }}) and using it here for consistency and easier version management.
Example: uses: actions/download-artifact@{{ gha_download_artifact }}
| uses: actions/download-artifact@v6.0.0 | |
| uses: actions/download-artifact@{{ gha_download_artifact }} |
Why is this change necessary?
Want to be able to deploy via CI pipeline instead manually in the console
How does this change address the issue?
Creates a CI job for it
What side effects does this change have?
N/A
How is this change tested?
Downstream repo
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.