✏️ Update the release relative content in the documentation for the Dockerfile checking changes.

Author: Chisanan232

docs_with_docusarus/contents/development/ci-cd/release-system.mdx

@@ -46,6 +46,10 @@ graph TD
     A --> C[Parse Release Intent]
     B --> C
     
+    B --> B1[Check Dockerfile]
+    B1 -->|Exists| B2[Enable Docker Jobs]
+    B1 -->|Missing| B3[Skip Docker Jobs]
+    
     C --> D[Version Bump]
     B --> E[Config Outputs]
     E --> F[Docker Registry URLs]
@@ -57,8 +61,10 @@ graph TD
     D --> K[Documentation]
     
     I --> L[PyPI via OIDC]
+    B2 --> J
     J --> M[Docker Hub - Config Based]
     J --> N[GitHub Container Registry - Config Based]
+    B3 -.->|Skipped| J
     K --> O[Docusaurus Versioning - Config Based]
     
     I & J & K --> P[Supply Chain Security]
@@ -82,7 +88,26 @@ config:
 - Auto-detects project name and package name from repository and `pyproject.toml`
 - Applies smart defaults for missing configuration sections
 
-**Step 2: Release Intent Analysis** 
+**Step 2: Dockerfile Detection** 🆕
+```yaml
+check-dockerfile:
+  name: Check Dockerfile Exists
+  runs-on: ubuntu-latest
+  steps:
+    - name: Check for Dockerfile
+      run: |
+        if [ -f "Dockerfile" ]; then
+          echo "has_dockerfile=true" >> $GITHUB_OUTPUT
+        else
+          echo "has_dockerfile=false" >> $GITHUB_OUTPUT
+        fi
+```
+- Checks for `Dockerfile` in repository root
+- Sets `has_dockerfile` output for downstream Docker jobs
+- Enables conditional execution of all Docker-related processes
+- Provides clear logging for Docker availability
+
+**Step 3: Release Intent Analysis** 
 ```yaml
 intent:
   uses: Chisanan232/Template-Python-UV-Project/.github/workflows/rw_parse_release_intent.yaml@master
@@ -104,17 +129,20 @@ intent:
    - Builds from correct bumped version (e.g., 0.0.1, not 0.0.0)
 
 2. **Docker Image** (`GHCR` & `DockerHub`) - **Config Enhanced**:
+   - **Automatic Dockerfile Detection**: 🆕 Detects Dockerfile presence; gracefully skips all Docker processes if not found
+   - **Conditional Execution**: Docker jobs only run when both a Dockerfile exists AND configuration allows it
    - **Config-Based Registry URLs**: 
      - **Docker Hub**: Uses `${{ needs.config.outputs.docker_registry_dockerhub }}`
      - **GHCR**: Uses `${{ needs.config.outputs.docker_registry_ghcr }}`
    - **Health Check Configuration**: Uses config-based `${{ needs.config.outputs.docker_health_check_path }}` and `${{ needs.config.outputs.docker_health_check_port }}`
    - **Application Environment**: Uses `${{ needs.config.outputs.docker_app_env_name }}` and `${{ needs.config.outputs.docker_app_env_value }}`
-   - **Dual Registry Publishing**: Publishes to both registries simultaneously
+   - **Dual Registry Publishing**: Publishes to both registries simultaneously (when Dockerfile exists)
    - **Parallel Publishing Jobs**: Separate jobs ensure isolated registry operations
    - **Multi-architecture builds**: amd64, arm64 support for both registries
    - **Supply Chain Security**: SBOM generation, Cosign signing, SLSA attestation
    - **Registry-Specific Authentication**: GHCR uses GitHub token, Docker Hub uses dedicated credentials
    - **Consistent Tagging**: Same version tags applied to both registries
+   - **Smart Summaries**: Workflow outputs clearly indicate Docker skipped vs published
    - **Fixed**: Uses correct version tags from git sync fix
 
 3. **Documentation** (`Docusaurus`) - **Config Enhanced**:
@@ -159,10 +187,15 @@ graph TD
     A --> C[Parse Release Intent]
     B --> C
     
+    B --> B1[Check Dockerfile]
+    B1 -->|Exists| B2[Run Docker Validation]
+    B1 -->|Missing| B3[Skip Docker Validation]
+    
     C --> D[Python Build Check]
-    C --> E[Docker Build & Test - Config Based]
+    B2 --> E[Docker Build & Test - Config Based]
+    B3 -.->|Skipped| E
     C --> F[Docs Build Test - Config Based]
-    C --> G[Supply Chain Security]
+    E --> G[Supply Chain Security]
     
     B --> H[Config Validation]
     H --> I[Registry URL Validation]
@@ -174,6 +207,8 @@ graph TD
     G --> N[Security Attestation]
     
     D & E & F & G & H --> O[Enhanced Validation Summary]
+    O -->|No Dockerfile| P[Docker Skipped Status]
+    O -->|Has Dockerfile| Q[Docker Validated Status]
 ```
 
 **Step-by-Step Enhanced Validation:**
@@ -190,7 +225,19 @@ config:
 - Validates Docker registry URLs and health check configurations
 - Confirms documentation path accessibility
 
-**Step 2: Release Intent Validation**
+**Step 2: Dockerfile Detection** 🆕
+```yaml
+check-dockerfile:
+  name: Check Dockerfile Exists
+  outputs:
+    has_dockerfile: ${{ steps.check.outputs.has_dockerfile }}
+```
+- Detects Dockerfile presence in repository root
+- Determines whether Docker validation should run
+- Outputs boolean flag for conditional job execution
+- Enables graceful skipping for Python-only projects
+
+**Step 3: Release Intent Validation**
 ```yaml
 intent-parse:
   uses: Chisanan232/Template-Python-UV-Project/.github/workflows/rw_parse_release_intent.yaml@master
@@ -202,10 +249,13 @@ intent-parse:
 
 #### Enhanced Security Validation
 
+- **Automatic Dockerfile Detection**: 🆕 Checks for Dockerfile presence; skips Docker validation if not found
+- **Conditional Docker Validation**: Docker build tests and security scans only run when Dockerfile exists
 - **Defensive Checks**: Pre-flight image existence validation
 - **Vulnerability Scanning**: Grype integration for CVE detection
 - **Fallback SBOM**: Workspace scanning if Docker image scan fails
 - **Supply Chain Security**: Full SBOM, signing, and attestation testing
+- **Flexible Validation**: Works for both Docker-based and Python-only projects
 
 ### 3. Staging Release Workflow (`release-staging.yml`)
 
@@ -224,12 +274,19 @@ graph TD
     A --> C[Compute Staging Version]
     B --> C
     
+    B --> B1[Check Dockerfile]
+    B1 -->|Exists| B2[Build Docker RC Images]
+    B1 -->|Missing| B3[Skip Docker RC]
+    
     C --> D[Staging Python Package]
     C --> E[Staging Docker Images]
     C --> F[Staging Documentation]
     
     D --> G[TestPyPI - Config Based]
-    E --> H[GHCR Staging - Config Based]
+    B2 --> E
+    E --> H1[DockerHub RC - Config Based]
+    E --> H2[GHCR RC - Config Based]
+    B3 -.->|Skipped| E
     F --> I[Preview Branch - Config Based]
     
     B --> J[Config Outputs]
@@ -250,7 +307,19 @@ config:
 - Provides validation version settings: `${{ needs.config.outputs.validation_version }}` and `${{ needs.config.outputs.validation_test_version }}`
 - Configures preview documentation branch: `${{ needs.config.outputs.docs_preview_branch }}`
 
-**Step 2: Staging Version Computation**
+**Step 2: Dockerfile Detection** 🆕
+```yaml
+check-dockerfile:
+  name: Check Dockerfile Exists
+  outputs:
+    has_dockerfile: ${{ steps.check.outputs.has_dockerfile }}
+```
+- Checks for Dockerfile in repository root
+- Controls Docker RC image builds for both DockerHub and GHCR
+- Enables Python-only projects to skip Docker staging
+- Provides clear feedback in staging summary
+
+**Step 3: Staging Version Computation**
 - Uses config-based validation version format
 - Creates release candidate versions with config-provided settings
 - Integrates with git configuration from config outputs
@@ -261,10 +330,12 @@ config:
    - Pre-release Python packages using `${{ needs.config.outputs.validation_version }}`
    - Git commits with `${{ needs.config.outputs.git_commit_name }}` and `${{ needs.config.outputs.git_commit_email }}`
 
-2. **GHCR Staging** - **Config Enhanced**: 
-   - Docker images with `-rc` tags using `${{ needs.config.outputs.docker_registry_ghcr }}`
+2. **Docker Staging (DockerHub & GHCR)** - **Config Enhanced**: 
+   - **Automatic Dockerfile Detection**: 🆕 RC images only built if Dockerfile exists in repository
+   - Docker images with `-rc` tags using `${{ needs.config.outputs.docker_registry_dockerhub }}` and `${{ needs.config.outputs.docker_registry_ghcr }}`
    - Health check validation using config-based `${{ needs.config.outputs.docker_health_check_path }}` and `${{ needs.config.outputs.docker_health_check_port }}`
    - Application environment testing with `${{ needs.config.outputs.docker_app_env_name }}` and `${{ needs.config.outputs.docker_app_env_value }}`
+   - Gracefully skips if no Dockerfile present
 
 3. **Documentation Preview** - **Config Enhanced**: 
    - Staging documentation branch using `${{ needs.config.outputs.docs_preview_branch }}`
@@ -332,6 +403,7 @@ graph LR
 ✅ **Validated**: Comprehensive pre-release validation  
 ✅ **Staged**: Safe staging environment testing  
 ✅ **Multi-Target**: Python, Docker, and docs deployment  
+✅ **Flexible**: 🆕 Automatic Dockerfile detection - works for both Docker-based and Python-only projects  
 ✅ **Efficient**: Matrix-based concurrent processing  
 ✅ **Robust**: Fallback mechanisms and defensive checks
 
@@ -1332,6 +1404,32 @@ artifacts:
   docker: skip    # Skips both registries
 ```
 
+:::tip Automatic Dockerfile Detection
+**New Feature**: All release workflows now automatically detect the presence of a `Dockerfile` in the repository root. If no Dockerfile is found, all Docker-related processes are gracefully skipped, regardless of the `docker` configuration setting.
+
+**Smart Behavior:**
+- ✅ **Dockerfile exists**: Docker processes run based on `docker` configuration (`auto`, `force`, `skip`)
+- ⚠️ **No Dockerfile**: Docker processes are automatically skipped with clear logging
+- 📋 **Summary output**: Workflow summaries clearly indicate when Docker was skipped due to missing Dockerfile
+
+**Affected Workflows:**
+- **Production Release** (`release.yml`): Skips Docker Hub and GHCR publishing
+- **Validation** (`release-validate.yml`): Skips Docker build validation and security scanning
+- **Staging** (`release-staging.yml`): Skips Docker Hub and GHCR RC image publishing
+
+**Example Workflow Output:**
+```
+=== Release Summary ===
+Dockerfile Check: ⚠️ Not Found (Docker skipped)
+Python Package: ✅ Published to PyPI
+DockerHub Build: ⏭️ Skipped (no Dockerfile)
+GHCR Build: ⏭️ Skipped (no Dockerfile)
+Documentation: ✅ Versioned
+```
+
+This allows the same template workflows to work seamlessly for Python-only projects without requiring any configuration changes.
+:::
+
 :::info Dual Registry Publishing Details
 When `docker: auto` or `docker: force`, the workflow creates **two parallel jobs**:
 
@@ -1448,15 +1546,21 @@ notes: "Documentation update release"
 
 ### Behavioral Matrix
 
-| Configuration | Changed Files | Behavior |
-|---------------|---------------|----------|
-| `python: auto` | Python files changed | ✅ Publishes to PyPI |
-| `python: auto` | No Python files changed | ⏭️ Skips publishing |
-| `python: force` | Any/no changes | ✅ Always publishes |
-| `python: skip` | Any/no changes | ⏭️ Always skips |
-| `docs.mode: auto, strategy: changed` | Docs files changed | ✅ Versions changed sections |
-| `docs.mode: auto, strategy: always` | Any changes | ✅ Versions all sections |
-| `docs.mode: force` | Any/no changes | ✅ Always versions |
+| Configuration | Dockerfile Exists | Changed Files | Behavior |
+|---------------|-------------------|---------------|----------|
+| `python: auto` | N/A | Python files changed | ✅ Publishes to PyPI |
+| `python: auto` | N/A | No Python files changed | ⏭️ Skips publishing |
+| `python: force` | N/A | Any/no changes | ✅ Always publishes |
+| `python: skip` | N/A | Any/no changes | ⏭️ Always skips |
+| `docker: auto` | ✅ Yes | Docker files changed | ✅ Publishes to registries |
+| `docker: auto` | ✅ Yes | No Docker files changed | ⏭️ Skips publishing |
+| `docker: auto` | ❌ No | Any/no changes | ⏭️ Skips (no Dockerfile) |
+| `docker: force` | ✅ Yes | Any/no changes | ✅ Always publishes |
+| `docker: force` | ❌ No | Any/no changes | ⏭️ Skips (no Dockerfile) |
+| `docker: skip` | Any | Any/no changes | ⏭️ Always skips |
+| `docs.mode: auto, strategy: changed` | N/A | Docs files changed | ✅ Versions changed sections |
+| `docs.mode: auto, strategy: always` | N/A | Any changes | ✅ Versions all sections |
+| `docs.mode: force` | N/A | Any/no changes | ✅ Always versions |
 
 ### Configuration Validation
 

docs_with_docusarus/contents/development/ci-cd/reusable-workflows.mdx

@@ -339,10 +339,40 @@ jobs:
 
 ### Conditional Execution Patterns
 
-Reusable workflows support sophisticated conditional execution based on configuration and change detection:
+Reusable workflows support sophisticated conditional execution based on configuration, change detection, and environment checks:
 
 ```yaml
 jobs:
+  # Check for Dockerfile (New Feature)
+  check-dockerfile:
+    name: Check Dockerfile Exists
+    runs-on: ubuntu-latest
+    outputs:
+      has_dockerfile: ${{ steps.check.outputs.has_dockerfile }}
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v5
+      - name: Check for Dockerfile
+        id: check
+        run: |
+          if [ -f "Dockerfile" ]; then
+            echo "has_dockerfile=true" >> $GITHUB_OUTPUT
+          else
+            echo "has_dockerfile=false" >> $GITHUB_OUTPUT
+          fi
+
+  # Conditional Docker publishing with Dockerfile detection
+  publish_docker:
+    needs: [parse_intent, check-dockerfile, build_docker]
+    if: |
+      needs.check-dockerfile.outputs.has_dockerfile == 'true' &&
+      (needs.parse_intent.outputs.docker == 'force' ||
+       (needs.parse_intent.outputs.docker == 'auto' && needs.detect_changes.outputs.docker == 'true'))
+    uses: ./.github/workflows/rw_docker_operations.yaml
+    with:
+      operation: 'push'
+      registry: 'ghcr.io'
+
   # Conditional Python publishing
   publish_python:
     needs: [parse_intent, build_python]
@@ -355,6 +385,12 @@ jobs:
       registry: 'pypi'
 ```
 
+**Key Conditional Patterns**:
+- **Dockerfile Detection** 🆕: Docker jobs only run when `Dockerfile` exists in repository root
+- **Configuration-Based**: Jobs respect `force`, `auto`, or `skip` settings from intent
+- **Change Detection**: Auto mode considers file changes for smart execution
+- **Multi-Condition**: Combines environment checks with configuration for robust control
+
 ## Architecture Benefits
 
 ### DRY Principle Implementation