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 the application code from the builder stage
118
+
COPY --from=builder /app .
119
+
120
+
# Expose the port the app runs on (adjust if your app uses a different port)
121
+
EXPOSE 8000
122
+
123
+
# Command to run the application
124
+
CMD ["python", "app.py"]
125
+
92
126
---
93
127
94
-
## 4. Google Cloud Run Specifics
128
+
## 4. Recommended Base Images
129
+
130
+
### Generic Base Image suggestions
131
+
* For programming languages use their official base image.
132
+
* Use latest version of the language specific image as base image.
133
+
* Review project config files to identify required runtime version:
134
+
* When a runtime version is specified, use that version for the base image.
135
+
* If no minimum version is specified use latest version of the runtime
136
+
137
+
### Google Cloud Run Specifics Base Images
95
138
96
139
If you are deploying to **Google Cloud Run**, you can leverage advanced features for security and maintenance.
97
140
98
-
### Base Image for Cloud Run Automatic Updates
141
+
####Base Image for Cloud Run Automatic Updates
99
142
100
143
Google Cloud can automatically patch security vulnerabilities in your base image if you follow the **"Scratch Pattern"**.
101
144
@@ -121,11 +164,11 @@ CMD [ "node", "index.js" ]
121
164
122
165
```
123
166
124
-
### Recommended Base Images (Stacks)
167
+
####Recommended Base Images (Stacks)
125
168
126
169
A base image serves as the starting foundation for container-based development. You build your application by layering necessary libraries, binaries, and configuration files on top of this image. Google Cloud's buildpacks publish these images with various configurations for system packages and languages.
127
170
128
-
#### Key Guidelines
171
+
#####Key Guidelines
129
172
130
173
***Hosting**: Base images are hosted in every region where the Artifact Registry is available.
131
174
***Updates**: Security and maintenance updates are released routinely. Depending on your environment (e.g., Cloud Run functions) and configuration, these updates can be applied automatically or manually.
@@ -139,70 +182,70 @@ A base image serves as the starting foundation for container-based development.
139
182
140
183
141
184
Runtime IDs and environment details (mostly Ubuntu 22.04 or 18.04, with some newer Ubuntu 24.04 options) for the following languages:
Copy file name to clipboardExpand all lines: skills/google-cicd-pipeline-design/SKILL.md
+5-3Lines changed: 5 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,11 +23,13 @@ Your purpose in this stage is to operate as a collaborative consultant, guiding
23
23
24
24
1.**Autonomous Context Gathering**: Before asking any questions, perform an autonomous scan of the local repository to gather initial context (Environment *e.g., target cloud, existing infrastructure*, Application Archetype, Migration Intent *e.g., from Jenkins, from on-prem*).
25
25
2.**Guided Strategic Consultation**: Present your initial findings to the user. Then, ask key strategic questions to clarify their release strategy (e.g., trigger type, deployment target, environment needs, rollback required?, canary deployments required?).
26
-
3.**Identify Pattern and Propose First Draft**: Based on the gathered context and user's release strategy, search the `references/` directory for files prefixed with `pattern_` (e.g., `pattern_trunk_based_push_to_deploy.txt`). Select the best-matching pattern *(e.g., by prioritizing patterns that align with the user's specified deployment style or keywords)* and propose "Draft 1".
27
-
4.**Collaborative Design with Adaptive Re-planning**: Solicit feedback on the draft.
26
+
3.**Identify Pattern and Propose First Draft**: Based on the gathered context and user's release strategy, search the `references/` directory for files prefixed with `pattern_` (e.g., `pattern_trunk_based_push_to_deploy.txt`). Select the best-matching pattern.
27
+
4.**Best Practice Cross-Reference**: Before proposing the draft, you MUST read any relevant `how_to_` files in the `references/` directory (e.g., `how_to_build_cloudbuild_yaml.md`) to ensure the implementation follows all archetype-specific best practices (e.g., linting, testing, image tagging, scanning, provenance).
28
+
5.**Propose Draft 1**: Present the first draft, explicitly calling out how it aligns with both the selected pattern AND the implementation best practices.
29
+
6.**Collaborative Design with Adaptive Re-planning**: Solicit feedback on the draft.
28
30
***For minor changes** (e.g., "add a linter"), update the plan and present a new draft.
29
31
***For major architectural changes** (e.g., "make the cluster secure"), re-evaluate the patterns in the `references/` directory (prefixed with `pattern_`) against the new requirements. Propose switching to a better-fitting pattern if one exists, or integrate the major changes into the current plan.
30
-
5.**Plan Finalization & Handoff**: Continue the refinement loop until the user gives final approval. Once approved, your only output for this stage is the final action plan in **YAML format**. After generating the YAML, you will automatically proceed to Stage 2.
32
+
7.**Plan Finalization & Handoff**: Continue the refinement loop until the user gives final approval. Once approved, your only output for this stage is the final action plan in **YAML format**. After generating the YAML, you will automatically proceed to Stage 2.
0 commit comments