diff --git a/skills/google-cicd-deploy/references/how_to_write_dockerfile.md b/skills/google-cicd-deploy/references/how_to_write_dockerfile.md index d3c8a72..0ede0b8 100644 --- a/skills/google-cicd-deploy/references/how_to_write_dockerfile.md +++ b/skills/google-cicd-deploy/references/how_to_write_dockerfile.md @@ -26,8 +26,6 @@ USER appuser ``` - - --- ## 3. Multi-Stage Builds (The Gold Standard) @@ -89,13 +87,58 @@ ENTRYPOINT ["/app"] ``` +### 💡 Example 3: Python simple application + +# --- Stage 1: Builder Stage --- +# Use a full Python image with build tools +FROM python:3.12-slim AS builder + +# Set the working directory inside the container +WORKDIR /app + +# Copy the requirements file and install dependencies +COPY requirements.txt . +RUN pip install --no-cache-dir -r requirements.txt + +# Copy application code +COPY . . + +# --- Stage 2: Final (Runtime) Stage --- +# Use a minimal, slim Python image for the final runtime +FROM python:3.12-slim AS final + +# Set the working directory +WORKDIR /app + +# Copy the installed packages from the builder stage into the final image +# This is a key step to include only the necessary libraries +COPY --from=builder /usr/local/lib/python3.12/site-packages /usr/local/lib/python3.12/site-packages + +# Copy the application code from the builder stage +COPY --from=builder /app . + +# Expose the port the app runs on (adjust if your app uses a different port) +EXPOSE 8000 + +# Command to run the application +CMD ["python", "app.py"] + --- -## 4. Google Cloud Run Specifics +## 4. Recommended Base Images + +### Generic Base Image suggestions +* For programming languages use their official base image. +* Use latest version of the language specific image as base image. +* Review project config files to identify required runtime version: + * When a runtime version is specified, use that version for the base image. + * If no minimum version is specified, use a recent stable version of the runtime. + +### Google Cloud Run Specific Base Images If you are deploying to **Google Cloud Run**, you can leverage advanced features for security and maintenance. -### Base Image for Cloud Run Automatic Updates +#### Base Image for Cloud Run Automatic Updates Google Cloud can automatically patch security vulnerabilities in your base image if you follow the **"Scratch Pattern"**. @@ -121,11 +164,11 @@ CMD [ "node", "index.js" ] ``` -### Recommended Base Images (Stacks) +#### Recommended Base Images (Stacks) 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. -#### Key Guidelines +##### Key Guidelines * **Hosting**: Base images are hosted in every region where the Artifact Registry is available. * **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. Runtime IDs and environment details (mostly Ubuntu 22.04 or 18.04, with some newer Ubuntu 24.04 options) for the following languages: -| Language | Runtime | Generation | Environment | Runtime ID | -| :---------- | :------------ | :-------------- | :---------- | :---------- | -| Node.js | Node.js 24 | 2nd gen | Ubuntu 24.04| nodejs24 | -| Node.js | Node.js 22 | 1st gen, 2nd gen| Ubuntu 22.04| nodejs22 | -| Node.js | Node.js 20 | 1st gen, 2nd gen| Ubuntu 22.04| nodejs20 | -| Node.js | Node.js 18 | 1st gen, 2nd gen| Ubuntu 22.04| nodejs18 | -| Node.js | Node.js 16 | 1st gen, 2nd gen| Ubuntu 18.04| nodejs16 | -| Node.js | Node.js 14 | 1st gen, 2nd gen| Ubuntu 18.04| nodejs14 | -| Node.js | Node.js 12 | 1st gen, 2nd gen| Ubuntu 18.04| nodejs12 | -| Node.js | Node.js 10 | 1st gen, 2nd gen| Ubuntu 18.04| nodejs10 | -| Node.js | Node.js 8 | 1st gen, 2nd gen| Ubuntu 18.04| nodejs8 | -| Node.js | Node.js 6 | 1st gen, 2nd gen| Ubuntu 18.04| nodejs6 | -| Python | Python 3.14 | 2nd gen | Ubuntu 24.04| python314 | -| Python | Python 3.13 | 2nd gen | Ubuntu 22.04| python313 | -| Python | Python 3.12 | 1st gen, 2nd gen| Ubuntu 22.04| python312 | -| Python | Python 3.11 | 1st gen, 2nd gen| Ubuntu 22.04| python311 | -| Python | Python 3.10 | 1st gen, 2nd gen| Ubuntu 22.04| python310 | -| Python | Python 3.9 | 1st gen, 2nd gen| Ubuntu 18.04| python39 | -| Python | Python 3.8 | 1st gen, 2nd gen| Ubuntu 18.04| python38 | -| Python | Python 3.7 | 1st gen | Ubuntu 18.04| python37 | -| Go | Go 1.25 | 2nd gen | Ubuntu 22.04| go125 | -| Go | Go 1.24 | 2nd gen | Ubuntu 22.04| go124 | -| Go | Go 1.23 | 2nd gen | Ubuntu 22.04| go123 | -| Go | Go 1.22 | 2nd gen | Ubuntu 22.04| go122 | -| Go | Go 1.21 | 1st gen, 2nd gen| Ubuntu 22.04| go121 | -| Go | Go 1.20 | 1st gen, 2nd gen| Ubuntu 22.04| go120 | -| Go | Go 1.19 | 1st gen, 2nd gen| Ubuntu 22.04| go119 | -| Go | Go 1.18 | 1st gen, 2nd gen| Ubuntu 22.04| go118 | -| Go | Go 1.16 | 1st gen, 2nd gen| Ubuntu 18.04| go116 | -| Go | Go 1.13 | 1st gen, 2nd gen| Ubuntu 18.04| go113 | -| Go | Go 1.11 | 1st gen, 2nd gen| Ubuntu 18.04| go111 | -| Java | Java 25 | 2nd gen | Ubuntu 24.04| java25 | -| Java | Java 21 | 2nd gen | Ubuntu 22.04| java21 | -| Java | Java 17 | 1st gen, 2nd gen| Ubuntu 22.04| java17 | -| Java | Java 11 | 1st gen, 2nd gen| Ubuntu 18.04| java11 | -| Ruby | Ruby 3.4 | 2nd gen | Ubuntu 22.04| ruby34 | -| Ruby | Ruby 3.3 | 1st gen, 2nd gen| Ubuntu 22.04| ruby33 | -| Ruby | Ruby 3.2 | 1st gen, 2nd gen| Ubuntu 22.04| ruby32 | -| Ruby | Ruby 3.0 | 1st gen, 2nd gen| Ubuntu 18.04| ruby30 | -| Ruby | Ruby 2.7 | 1st gen, 2nd gen| Ubuntu 18.04| ruby27 | -| Ruby | Ruby 2.6 | 1st gen, 2nd gen| Ubuntu 18.04| ruby26 | -| PHP | PHP 8.4 | 2nd gen | Ubuntu 22.04| php84 | -| PHP | PHP 8.3 | 2nd gen | Ubuntu 22.04| php83 | -| PHP | PHP 8.2 | 1st gen, 2nd gen| Ubuntu 22.04| php82 | -| PHP | PHP 8.1 | 1st gen, 2nd gen| Ubuntu 18.04| php81 | -| PHP | PHP 7.4 | 1st gen, 2nd gen| Ubuntu 18.04| php74 | -| .NET Core | .NET Core 8 | 2nd gen | Ubuntu 22.04| dotnet8 | -| .NET Core | .NET Core 6 | 1st gen, 2nd gen| Ubuntu 22.04| dotnet6 | -| .NET Core | .NET Core 3 | 1st gen, 2nd gen| Ubuntu 18.04| dotnet3 | +| Language | Runtime | Generation | Environment | Runtime ID | +| :-------- | :---------- | :--------------- | :----------- | :--------- | +| Node.js | Node.js 24 | 2nd gen | Ubuntu 24.04 | nodejs24 | +| Node.js | Node.js 22 | 1st gen, 2nd gen | Ubuntu 22.04 | nodejs22 | +| Node.js | Node.js 20 | 1st gen, 2nd gen | Ubuntu 22.04 | nodejs20 | +| Node.js | Node.js 18 | 1st gen, 2nd gen | Ubuntu 22.04 | nodejs18 | +| Node.js | Node.js 16 | 1st gen, 2nd gen | Ubuntu 18.04 | nodejs16 | +| Node.js | Node.js 14 | 1st gen, 2nd gen | Ubuntu 18.04 | nodejs14 | +| Node.js | Node.js 12 | 1st gen, 2nd gen | Ubuntu 18.04 | nodejs12 | +| Node.js | Node.js 10 | 1st gen, 2nd gen | Ubuntu 18.04 | nodejs10 | +| Node.js | Node.js 8 | 1st gen, 2nd gen | Ubuntu 18.04 | nodejs8 | +| Node.js | Node.js 6 | 1st gen, 2nd gen | Ubuntu 18.04 | nodejs6 | +| Python | Python 3.14 | 2nd gen | Ubuntu 24.04 | python314 | +| Python | Python 3.13 | 2nd gen | Ubuntu 22.04 | python313 | +| Python | Python 3.12 | 1st gen, 2nd gen | Ubuntu 22.04 | python312 | +| Python | Python 3.11 | 1st gen, 2nd gen | Ubuntu 22.04 | python311 | +| Python | Python 3.10 | 1st gen, 2nd gen | Ubuntu 22.04 | python310 | +| Python | Python 3.9 | 1st gen, 2nd gen | Ubuntu 18.04 | python39 | +| Python | Python 3.8 | 1st gen, 2nd gen | Ubuntu 18.04 | python38 | +| Python | Python 3.7 | 1st gen | Ubuntu 18.04 | python37 | +| Go | Go 1.25 | 2nd gen | Ubuntu 22.04 | go125 | +| Go | Go 1.24 | 2nd gen | Ubuntu 22.04 | go124 | +| Go | Go 1.23 | 2nd gen | Ubuntu 22.04 | go123 | +| Go | Go 1.22 | 2nd gen | Ubuntu 22.04 | go122 | +| Go | Go 1.21 | 1st gen, 2nd gen | Ubuntu 22.04 | go121 | +| Go | Go 1.20 | 1st gen, 2nd gen | Ubuntu 22.04 | go120 | +| Go | Go 1.19 | 1st gen, 2nd gen | Ubuntu 22.04 | go119 | +| Go | Go 1.18 | 1st gen, 2nd gen | Ubuntu 22.04 | go118 | +| Go | Go 1.16 | 1st gen, 2nd gen | Ubuntu 18.04 | go116 | +| Go | Go 1.13 | 1st gen, 2nd gen | Ubuntu 18.04 | go113 | +| Go | Go 1.11 | 1st gen, 2nd gen | Ubuntu 18.04 | go111 | +| Java | Java 25 | 2nd gen | Ubuntu 24.04 | java25 | +| Java | Java 21 | 2nd gen | Ubuntu 22.04 | java21 | +| Java | Java 17 | 1st gen, 2nd gen | Ubuntu 22.04 | java17 | +| Java | Java 11 | 1st gen, 2nd gen | Ubuntu 18.04 | java11 | +| Ruby | Ruby 3.4 | 2nd gen | Ubuntu 22.04 | ruby34 | +| Ruby | Ruby 3.3 | 1st gen, 2nd gen | Ubuntu 22.04 | ruby33 | +| Ruby | Ruby 3.2 | 1st gen, 2nd gen | Ubuntu 22.04 | ruby32 | +| Ruby | Ruby 3.0 | 1st gen, 2nd gen | Ubuntu 18.04 | ruby30 | +| Ruby | Ruby 2.7 | 1st gen, 2nd gen | Ubuntu 18.04 | ruby27 | +| Ruby | Ruby 2.6 | 1st gen, 2nd gen | Ubuntu 18.04 | ruby26 | +| PHP | PHP 8.4 | 2nd gen | Ubuntu 22.04 | php84 | +| PHP | PHP 8.3 | 2nd gen | Ubuntu 22.04 | php83 | +| PHP | PHP 8.2 | 1st gen, 2nd gen | Ubuntu 22.04 | php82 | +| PHP | PHP 8.1 | 1st gen, 2nd gen | Ubuntu 18.04 | php81 | +| PHP | PHP 7.4 | 1st gen, 2nd gen | Ubuntu 18.04 | php74 | +| .NET Core | .NET Core 8 | 2nd gen | Ubuntu 22.04 | dotnet8 | +| .NET Core | .NET Core 6 | 1st gen, 2nd gen | Ubuntu 22.04 | dotnet6 | +| .NET Core | .NET Core 3 | 1st gen, 2nd gen | Ubuntu 18.04 | dotnet3 | --- ## 5. Summary Checklist -| Feature | Best Practice | -| --- | --- | -| **Base Image** | Use official, versioned, slim, or distroless images. | -| **Layers** | Combine `RUN` commands; copy dependencies before source code. | -| **Security** | Prefer not to run as `root`; never include secrets/ENV keys in Dockerfile. | -| **Size** | Use **Multi-Stage builds** to strip out build-time bloat. | -| **Cloud Run** | Use `runtime provided` + base images | -| **Metadata** | Use `LABEL` to provide contact and versioning info. | +| Feature | Best Practice | +| -------------- | -------------------------------------------------------------------------- | +| **Base Image** | Use official, versioned, slim, or distroless images. | +| **Layers** | Combine `RUN` commands; copy dependencies before source code. | +| **Security** | Prefer not to run as `root`; never include secrets/ENV keys in Dockerfile. | +| **Size** | Use **Multi-Stage builds** to strip out build-time bloat. | +| **Cloud Run** | Use `runtime provided` + base images | +| **Metadata** | Use `LABEL` to provide contact and versioning info. | -### Sources: +#### Sources: https://cloud.google.com/run/docs/configuring/services/automatic-base-image-updates https://cloud.google.com/docs/buildpacks/base-images diff --git a/skills/google-cicd-pipeline-design/SKILL.md b/skills/google-cicd-pipeline-design/SKILL.md index e5cb7d5..bc2dc76 100644 --- a/skills/google-cicd-pipeline-design/SKILL.md +++ b/skills/google-cicd-pipeline-design/SKILL.md @@ -23,11 +23,13 @@ Your purpose in this stage is to operate as a collaborative consultant, guiding 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*). 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?). -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". -4. **Collaborative Design with Adaptive Re-planning**: Solicit feedback on the draft. +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. +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). +5. **Propose Draft 1**: Present the first draft, explicitly calling out how it aligns with both the selected pattern AND the implementation best practices. +6. **Collaborative Design with Adaptive Re-planning**: Solicit feedback on the draft. * **For minor changes** (e.g., "add a linter"), update the plan and present a new draft. * **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. -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. +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. ### Stage 2: Plan Implementation diff --git a/skills/google-cicd-pipeline-design/references/programming_language_specific_project_setup.md b/skills/google-cicd-pipeline-design/references/programming_language_specific_project_setup.md new file mode 100644 index 0000000..8e868a4 --- /dev/null +++ b/skills/google-cicd-pipeline-design/references/programming_language_specific_project_setup.md @@ -0,0 +1,72 @@ +## Example config for project setup +### Python +Python has shifted toward a more unified configuration approach recently, but you'll still see a mix of old and new. + +* pyproject.toml: The modern standard for defining build systems and project metadata. +* requirements.txt: A simple list of dependencies for pip. +* setup.py / setup.cfg: Legacy files for packaging and distribution. +* environment.yml: Used specifically for Conda virtual environments. +* tox.ini: Configuration for automated testing across different Python versions. + +### Java +Java relies heavily on established build automation tools. + +* pom.xml: The core configuration file for Maven projects. +* build.gradle: The build script for Gradle (Groovy DSL). +* settings.gradle: Defines project structure and module names for Gradle. +* MANIFEST.MF: Defines extension and package-related data for JAR files. + +### Go (Golang) +Go keeps it minimal with a focus on reproducibility. + +* go.mod: Defines the module's path and its dependency requirements. +* go.sum: Contains the expected cryptographic hashes of the content of specific module versions. + +### Ruby +Ruby’s ecosystem is centered around "Gems." +Gemfile: Describes the gem dependencies required to run the Ruby code. + +* Gemfile.lock: Records the exact versions of gems that were installed. +* .ruby-version: Specifies which version of the Ruby interpreter should be used. +* Rakefile: Contains instructions for rake (Ruby's build program). + +### Node.js +The JavaScript/TypeScript ecosystem is highly standardized. + +* package.json: Manifest file containing metadata, scripts, and dependencies. +* package-lock.json (or yarn.lock / pnpm-lock.yaml): Ensures consistent installation across machines. +* tsconfig.json: Configuration for TypeScript compiler settings. +* .npmrc: Configuration file for how npm should behave. + +### Rust +Rust uses a single, powerful tool called Cargo. + +* Cargo.toml: The manifest file where you declare dependencies and metadata. +* Cargo.lock: Created automatically to ensure reproducible builds by locking dependency versions. + +### Kotlin +Since Kotlin is often used in the JVM or Android ecosystem, it shares tools with Java but uses its own "flavor." +* build.gradle.kts: Gradle build script using the Kotlin DSL. +* settings.gradle.kts: Project-wide settings using Kotlin DSL. + +### PHP +Modern PHP development revolves around Composer. +* composer.json: Defines dependencies, autoloading rules, and project metadata. +* composer.lock: Locks the project to specific versions of dependencies. +* php.ini: The main configuration file for the PHP interpreter itself. + +### C / C++ +These languages are more fragmented, often depending on the build system chosen. + +* Makefile: Used by the make build automation tool. +* CMakeLists.txt: Configuration for CMake, the industry standard for cross-platform C/C++ builds. +* conanfile.txt / conanfile.py: Used by the Conan package manager. +* vcpkg.json: Configuration for the vcpkg dependency manager. + +### Visual Studio (IDE Specific) +While the languages above use the files listed, the Visual Studio IDE adds its own layer. +* .sln: The Solution file; acts as a container for one or more projects. +* .csproj / .vcxproj: Project files for C# and C++ respectively, containing build settings and file references. +* .editorconfig: Defines coding styles (indentation, etc.) to be enforced by the editor. +* App.config / Web.config: XML files for runtime configuration settings. +