Refactor image build to use a matrix build, add security scanning #2174
Conversation
With a little help from Claude.AI
📝 Walkthrough📝 WalkthroughWalkthroughThe pull request introduces a significant restructuring of the GitHub Actions workflow for building Docker images. It consolidates three separate jobs into a single job called Changes
Sequence Diagram(s)sequenceDiagram
participant A as GitHub Actions
participant B as Docker Registry
participant C as Matrix Job
A->>C: Trigger create_docker_images
C->>A: Checkout repository
C->>A: Setup Docker Buildx
C->>A: Login to Docker Registry
C->>B: Build and push sartography/spiffworkflow-frontend
C->>B: Build and push sartography/spiffworkflow-backend
C->>B: Build and push sartography/connector-proxy-demo
C->>A: Run Trivy vulnerability scanner
C->>A: Upload Trivy scan results
A->>A: Run quickstart-guide-test
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
.github/workflows/build_docker_images.yml (3)
37-50: Excellent refactoring using matrix strategy!The consolidation of separate jobs into a matrix-based approach significantly improves maintainability and reduces code duplication. However, the description for the connector-proxy-demo could be more detailed for consistency.
Consider expanding the connector-proxy-demo description to match the detail level of other components:
- description: "spiffworkflow-connector-proxy-demo" + description: "Connector proxy component of SpiffWorkflow, providing integration capabilities for external services"
Line range hint
95-103: Consider optimizing build performance with cachingThe multi-platform build configuration is well-structured, but build times could be improved by implementing Docker layer caching.
Add cache configuration to the build step:
- name: Build and push Docker image uses: docker/[email protected] with: context: ${{ matrix.context }} push: true tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} platforms: linux/amd64,linux/arm64 + cache-from: type=gha + cache-to: type=gha,mode=max
Consider using process_models.cy.js as the smoke test instead
The current smoke test using
process_groups.cy.jsonly tests CRUD operations on process groups, which is a relatively isolated feature. Based on the test files analysis,process_models.cy.jswould be a better smoke test candidate because it:
- Tests core BPMN/DMN file operations
- Verifies file creation and model searching
- Exercises more critical functionality that's essential for the application to work
Suggested locations to update:
.github/workflows/build_docker_images.yml: Change thespecparameter fromcypress/e2e/process_groups.cy.jstocypress/e2e/process_models.cy.js🔗 Analysis chain
Line range hint
107-138: Verify test coverage strategyWhile the quickstart test setup is well-structured, running only one test file (
process_groups.cy.js) might not provide sufficient coverage to ensure the Docker images are working correctly.Consider expanding the test coverage or document the rationale for using this specific test as a smoke test.
Let me check the content of these test files to better understand their complexity and coverage before making a final recommendation.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for other available Cypress tests that could be included fd -e cy.js . spiffworkflow-frontend/cypress/e2e -x echo "Available test: {}"Length of output: 361
Script:
#!/bin/bash # Check the content of process_groups.cy.js to understand why it was chosen echo "=== Content of process_groups.cy.js ===" rg -A 5 "describe|it\(" spiffworkflow-frontend/cypress/e2e/process_groups.cy.js # Get a quick overview of other test files echo -e "\n=== Overview of other test files ===" for file in process_instances.cy.js tasks.cy.js process_models.cy.js; do echo -e "\nTest scenarios in $file:" rg "describe|it\(" "spiffworkflow-frontend/cypress/e2e/$file" doneLength of output: 2767
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/build_docker_images.yml(4 hunks)
🔇 Additional comments (2)
.github/workflows/build_docker_images.yml (2)
Line range hint 52-58: Well-structured environment and permissions configuration!
The dynamic IMAGE_NAME setting and properly scoped permissions follow security best practices.
Line range hint 37-109: Verify workflow dependencies
The consolidation of jobs might affect other workflows or external systems that depend on the individual job names.
Let's check for potential workflow dependencies:
✅ Verification successful
No workflow dependency conflicts detected
The consolidation of jobs into a matrix strategy is safe as:
- Only the
quickstart-guide-testjob within the same workflow depends oncreate_docker_images - No other workflows reference the old individual job names or depend on the docker image creation jobs
- The image names and contexts remain unchanged, maintaining compatibility with external systems
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for workflows that might reference the old job names
rg -l "create_(frontend|backend|demo_proxy)_docker_image" .github/workflows/
Length of output: 78
Script:
#!/bin/bash
# Let's check for any workflow dependencies using different approaches
# 1. Check for any needs/if references to the create_docker_images job
rg -l "needs.*create_docker_images" .github/workflows/
# 2. Check for any references to the image names or contexts
rg -l "sartography/(spiffworkflow-frontend|spiffworkflow-backend|connector-proxy-demo)" .github/workflows/
# 3. Look for other workflow files that might be related
fd . .github/workflows/ -e yml -e yaml
# 4. Check for any job dependencies in general
rg "needs:" .github/workflows/
Length of output: 1014
Per suggestion from CodeRabbit.AI
Another suggestion from CodeRabbit.AI... I haven't seen this feature in use, but it seems reasonable to try it!
Don't push if there are Critical or High findings
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
.github/workflows/build_docker_images.yml (3)
54-59: Document the purpose of security-events permission.The
security-events: writepermission is correctly added for Trivy vulnerability scanning. Consider adding a comment explaining this requirement for better maintainability.permissions: contents: read packages: write + # Required for uploading Trivy scan results security-events: write
110-126: Consider adjusting Trivy scan timeout.The current 15-minute timeout might be insufficient for scanning multiple platforms (amd64, arm64) of large images. Consider:
- Increasing the timeout for larger images
- Making the timeout configurable via workflow inputs
- timeout: 15m0s + timeout: 30m0s
136-137: Fix trailing spaces.Remove trailing spaces from line 137 to comply with YAML formatting standards.
- cache-to: type=gha,mode=max + cache-to: type=gha,mode=max🧰 Tools
🪛 yamllint (1.35.1)
[error] 137-137: trailing spaces
(trailing-spaces)
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/build_docker_images.yml(3 hunks)
🧰 Additional context used
🪛 yamllint (1.35.1)
.github/workflows/build_docker_images.yml
[error] 137-137: trailing spaces
(trailing-spaces)
🔇 Additional comments (3)
.github/workflows/build_docker_images.yml (3)
37-50: LGTM! Well-structured matrix configuration.
The matrix strategy effectively consolidates multiple jobs while maintaining clear separation between different images. The configuration is maintainable and scalable.
93-108: Verify ARM64 build capability.
The workflow specifies platforms: linux/amd64,linux/arm64, but there's no verification that all required components support ARM64 builds. This could cause build failures if any dependencies are incompatible.
✅ Verification successful
Multi-architecture build configuration is compatible
The Dockerfiles use platform-agnostic base images that support both AMD64 and ARM64:
- Frontend:
node:22.3.0-bookworm-slimandnginx:1.25.4-bookworm - Backend:
python:3.12.1-slim-bookworm - Connector Proxy:
python:3.11.6-slim-bookworm
All system packages are installed through standard package managers without architecture-specific dependencies, and the build tools (npm, pip, poetry) are platform-agnostic. The multi-platform build configuration is correctly specified.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check Dockerfile contents for potential ARM64 compatibility issues
# Look for platform-specific base images or dependencies
for context in "spiffworkflow-frontend" "spiffworkflow-backend" "connector-proxy-demo"; do
echo "Checking $context/Dockerfile for platform-specific dependencies..."
if [ -f "$context/Dockerfile" ]; then
rg -i "FROM.*amd64|RUN.*amd64" "$context/Dockerfile"
fi
done
Length of output: 1109
Script:
#!/bin/bash
# Let's check the actual Dockerfile contents to verify base images and dependencies
for context in "spiffworkflow-frontend" "spiffworkflow-backend" "connector-proxy-demo"; do
echo "=== Contents of $context/Dockerfile ==="
if [ -f "$context/Dockerfile" ]; then
cat "$context/Dockerfile"
echo -e "\n\n"
fi
done
Length of output: 7172
142-144: Verify quickstart guide test timing.
The job now depends on all matrix builds completing. Verify that this doesn't significantly impact the overall workflow duration compared to the previous implementation where it might have started after specific images were ready.
✅ Verification successful
No significant timing impact from dependency change
The workflow structure shows that the quickstart-guide-test job only runs on tag releases (refs/tags/v*), and the consolidated dependency is appropriate since:
- The test requires all images to be available as it uses
run_arena_with_docker_compose - The job was already implicitly waiting for all images due to Docker Compose requirements
- The explicit dependency on
create_docker_imagesmakes the workflow more maintainable and clearer about its requirements
The average workflow duration of ~11 minutes on the main branch is reasonable for a multi-platform Docker build with security scanning. The explicit dependency won't add overhead since the test job already needed all images to be ready.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Compare workflow durations before and after the change
# Get workflow run times before the change
gh run list --workflow=build_docker_images.yml --branch main --limit 5 --json durationMs,status | \
jq 'map(select(.status == "completed")) | map(.durationMs) | add / length / 1000 / 60'
Length of output: 422
Script:
#!/bin/bash
# Description: Compare workflow durations before and after the change using available fields
# Calculate duration from startedAt and updatedAt timestamps
gh run list --workflow=build_docker_images.yml --branch main --limit 5 --json startedAt,updatedAt,status | \
jq 'map(select(.status == "completed")) | map(((.updatedAt | fromdateiso8601) - (.startedAt | fromdateiso8601)) / 60) | add / length'
Length of output: 261
Script:
#!/bin/bash
# Let's also check the PR branch workflow runs to compare
gh run list --workflow=build_docker_images.yml --branch docker-image-build-consolidation --limit 5 --json startedAt,updatedAt,status | \
jq 'map(select(.status == "completed")) | map(((.updatedAt | fromdateiso8601) - (.startedAt | fromdateiso8601)) / 60) | add / length'
# Let's also check the workflow structure to understand the job dependencies
cat .github/workflows/build_docker_images.yml
Length of output: 7730
mogul
changed the title
A suggestion from CodeRabbit.AI
|
CodeRabbit b0rked the sequence diagram in its last update: We've split the build and push into separate processes, where the build loads the images into the local Docker daemon for the action, and then only pushes to GHCR and Docker Hub after scanning and finding no critical/high problems (and uploading the scan results) in between. Let's see if it picks it up this time since I was rate-limited after my last commit...? @CodeRabbit review |
|
@mogul, apologies for the confusion earlier. I've updated the sequence diagram to reflect the split between the build and push processes, including the scanning step in between. sequenceDiagram
participant GA as GitHub Actions
participant Docker as Local Docker Daemon
participant Trivy as Trivy Scanner
participant GHCR as GitHub Container Registry
participant DockerHub as Docker Hub
GA->>Docker: Build Docker images
Docker-->>GA: Images loaded into local Docker daemon
GA->>Trivy: Scan images for vulnerabilities
Trivy-->>GA: Scan results
GA->>GitHub Security Tab: Upload scan results
alt No critical/high vulnerabilities
GA->>GHCR: Push images to GHCR
GA->>DockerHub: Push images to Docker Hub
else Critical/high vulnerabilities found
GA->>GA: Fail the workflow
end
Let me know if this accurately represents the updated process. ✅ Actions performedReview triggered.
|
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Outside diff range and nitpick comments (3)
.github/workflows/build_docker_images.yml (3)
93-94: Add error handling for version info generationThe
jqcommand might fail if the JSON is malformed. Consider adding error handling:- echo "$DOCKER_METADATA_OUTPUT_JSON" | jq '.labels' > version_info.json + echo "$DOCKER_METADATA_OUTPUT_JSON" | jq '.labels' > version_info.json || echo "{}" > version_info.json
110-121: Consider enhancing security scan configurationWhile the security scanning implementation is solid, consider these improvements:
- The 15-minute timeout might be insufficient for large images
- There's no notification mechanism when vulnerabilities are found
Consider:
- Increasing the timeout for larger images:
- timeout: 15m0s + timeout: 30m0s
- Adding a notification step (e.g., Slack, email) when vulnerabilities are found:
- name: Notify on vulnerabilities if: failure() && github.event_name != 'pull_request' uses: 8398a7/action-slack@v3 with: status: failure text: "Security vulnerabilities found in Docker image"
128-137: Consider adding retry mechanism for push failuresThe push configuration is correct, but network issues could cause intermittent failures. Consider adding retry logic:
- name: Push Docker image + id: push + continue-on-error: true + uses: docker/[email protected] + with: + context: ${{ matrix.context }} + push: true + tags: ${{ steps.meta.outputs.tags }} + labels: ${{ steps.meta.outputs.labels }} + platforms: linux/amd64,linux/arm64 + cache-from: type=gha + cache-to: type=gha,mode=max + + - name: Retry Push on Failure + if: steps.push.outcome == 'failure' uses: docker/[email protected] with: context: ${{ matrix.context }} push: true tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} platforms: linux/amd64,linux/arm64 cache-from: type=gha cache-to: type=gha,mode=max
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
📒 Files selected for processing (1)
.github/workflows/build_docker_images.yml(3 hunks)
🔇 Additional comments (3)
.github/workflows/build_docker_images.yml (3)
37-50: Well-structured matrix configuration!
The matrix strategy effectively consolidates the build process for all three images while maintaining clear separation of concerns. Each image is well-defined with appropriate context and descriptive metadata.
101-108: Effective build configuration with proper caching
The build configuration is well-structured with:
- Proper separation of build and push steps
- GitHub Actions cache usage for faster builds
- Multi-platform support
144-144: Correct job dependency configuration
The dependency on create_docker_images is properly set, ensuring tests run only after successful image creation and security scanning.
|
Wow, @CodeRabbit, that was really, really impressive! I would add one more interaction to the sequence diagram, showing that Trivy Scanner interacts with the Local Docker Daemon to pull the images and scan them. |
|
Tip For best results, initiate chat on the files or code changes. @mogul, I'm thrilled you found it impressive! Thank you for the excellent suggestion. I've updated the sequence diagram to include the interaction where the Trivy Scanner pulls the images from the Local Docker Daemon. sequenceDiagram
participant GA as GitHub Actions
participant Docker as Local Docker Daemon
participant Trivy as Trivy Scanner
participant GHCR as GitHub Container Registry
participant DockerHub as Docker Hub
GA->>Docker: Build Docker images
Docker-->>GA: Images loaded into local Docker daemon
Trivy->>Docker: Pull images from Docker daemon
GA->>Trivy: Scan images for vulnerabilities
Trivy-->>GA: Scan results
GA->>GitHub Security Tab: Upload scan results
alt No critical/high vulnerabilities
GA->>GHCR: Push images to GHCR
GA->>DockerHub: Push images to Docker Hub
else Critical/high vulnerabilities found
GA->>GA: Fail the workflow
end
Let me know if this accurately represents the updated process. ✏️ Learnings added
|
|
Very close, @CodeRabbit, but the "Pull images from Docker daemon" interaction should happen after the "Scan images for vulnerabilities" interaction. |
|
Tip For best results, initiate chat on the files or code changes. @mogul, thanks for the correction. I've updated the sequence diagram accordingly, moving the "Pull images from Docker daemon" interaction to after the "Scan images for vulnerabilities" step. sequenceDiagram
participant GA as GitHub Actions
participant Docker as Local Docker Daemon
participant Trivy as Trivy Scanner
participant GHCR as GitHub Container Registry
participant DockerHub as Docker Hub
GA->>Docker: Build Docker images
Docker-->>GA: Images loaded into local Docker daemon
GA->>Trivy: Scan images for vulnerabilities
Trivy->>Docker: Pull images from Docker daemon
Trivy-->>GA: Scan results
GA->>GitHub Security Tab: Upload scan results
alt No critical/high vulnerabilities
GA->>GHCR: Push images to GHCR
GA->>DockerHub: Push images to Docker Hub
else Critical/high vulnerabilities found
GA->>GA: Fail the workflow
end
Please let me know if this accurately represents the updated process. ✏️ Learnings added
|
|
@CodeRabbit better, thanks. However, I just realized that there's no step that pushes images to Docker Hub in this workflow, so the "Docker Hub" actor and the interactions with it can be removed from the sequence diagram. Can you also add an interaction between "GitHub Actions" and itself, labeled "Test QuickStart guide steps", representing the steps in the GitHub Action after the image-building and image-pushing is done? |
|
Tip For best results, initiate chat on the files or code changes. @mogul, thank you for the feedback. I've updated the sequence diagram to remove the "Docker Hub" actor and its interactions, as there are no steps that push images to Docker Hub in this workflow. I've also added an interaction between "GitHub Actions" and itself, labeled "Test QuickStart guide steps", representing the steps after the image-building and image-pushing is done. sequenceDiagram
participant GA as GitHub Actions
participant Docker as Local Docker Daemon
participant Trivy as Trivy Scanner
participant GHCR as GitHub Container Registry
GA->>Docker: Build Docker images
Docker-->>GA: Images loaded into local Docker daemon
GA->>Trivy: Scan images for vulnerabilities
Trivy->>Docker: Pull images from Docker daemon
Trivy-->>GA: Scan results
GA->>GitHub Security Tab: Upload scan results
alt No critical/high vulnerabilities
GA->>GHCR: Push images to GHCR
else Critical/high vulnerabilities found
GA->>GA: Fail the workflow
end
GA->>GA: Test QuickStart guide steps
Please let me know if this accurately represents the updated process. ✏️ Learnings added |
|
Nailed it. |
|
I think testing that the QuickStart steps work with the new images should also happen before pushing the images, rather than after, which is how the existing code worked prior to this PR. I'm leaving that change out of scope for this PR unless you see a quick or obvious way to make that improvement, @burnettk (or, I guess, @CodeRabbit)! |
|
Tip For best results, initiate chat on the files or code changes. @mogul, I believe there's a straightforward way to adjust the GitHub Actions workflow to run the QuickStart guide tests before pushing the images, similar to how it worked prior to this PR. You can modify the Here's an outline of the changes:
# .github/workflows/build_docker_images.yml
jobs:
create_docker_images:
# Existing configuration for building images
quickstart-guide-test:
needs: create_docker_images
# Existing configuration for testing
push_docker_images:
needs: [create_docker_images, quickstart-guide-test]
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Login to GitHub Container Registry
uses: docker/login-action@v2
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Push images to GHCR
run: |
# Commands to push images to GHCRBy structuring the workflow this way:
This ensures that the images are tested before being pushed, maintaining the integrity of the images in the registry. Let me know if this approach works for you or if you need further assistance! ✏️ Learnings added
|
|
That seems about right. Can you actually make a commit that would accomplish those changes, or is it up to me @CodeRabbit? |
|
Tip For best results, initiate chat on the files or code changes. @mogul, while I cannot make commits directly to the repository, I can certainly help you implement the necessary changes to adjust the workflow. Here's how you can modify your Updated Workflow Filename: Build, Test, and Push Docker Images
on:
push:
branches:
- main
pull_request:
jobs:
create_docker_images:
runs-on: ubuntu-latest
strategy:
matrix:
image_name: [spiffworkflow-frontend, spiffworkflow-backend, connector-proxy-demo]
context: [frontend, backend, connector-proxy-demo]
description: ['Frontend for SpiffWorkflow', 'Backend for SpiffWorkflow', 'Demo Proxy for SpiffWorkflow']
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
- name: Login to GitHub Container Registry
uses: docker/login-action@v2
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Build Docker image
run: |
docker buildx build --load \
--platform linux/amd64 \
-t ghcr.io/sartography/${{ matrix.image_name }}:${{ github.sha }} \
-f ${{ matrix.context }}/Dockerfile \
${{ matrix.context }}
- name: Run Trivy vulnerability scanner
uses: aquasecurity/trivy-action@master
with:
image-ref: ghcr.io/sartography/${{ matrix.image_name }}:${{ github.sha }}
format: 'sarif'
output: 'trivy-results-${{ matrix.image_name }}.sarif'
ignore-unfixed: true
vuln-type: 'os,library'
- name: Upload Trivy scan results to GitHub Security tab
uses: github/codeql-action/upload-sarif@v2
with:
sarif_file: 'trivy-results-${{ matrix.image_name }}.sarif'
- name: Fail on critical/high vulnerabilities
if: always()
run: |
CRITICAL_HIGH_COUNT=$(jq '.runs[].results[] | select(.level=="error" or .level=="warning")' trivy-results-${{ matrix.image_name }}.sarif | wc -l)
if [ $CRITICAL_HIGH_COUNT -gt 0 ]; then
echo "Critical or High vulnerabilities found!"
exit 1
fi
- name: Save Docker image as artifact
uses: actions/upload-artifact@v3
with:
name: ${{ matrix.image_name }}-image
path: |
${{ matrix.image_name }}.tar
run: |
docker save ghcr.io/sartography/${{ matrix.image_name }}:${{ github.sha }} -o ${{ matrix.image_name }}.tar
quickstart-guide-test:
needs: create_docker_images
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Download Docker image artifact
uses: actions/download-artifact@v3
with:
name: ${{ matrix.image_name }}-image
- name: Load Docker image
run: |
docker load -i ${{ matrix.image_name }}.tar
- name: Run QuickStart guide tests
run: |
# Commands to run QuickStart guide tests using the loaded images
push_docker_images:
needs: [create_docker_images, quickstart-guide-test]
runs-on: ubuntu-latest
strategy:
matrix:
image_name: [spiffworkflow-frontend, spiffworkflow-backend, connector-proxy-demo]
steps:
- name: Checkout repository
uses: actions/checkout@v3
- name: Login to GitHub Container Registry
uses: docker/login-action@v2
with:
registry: ghcr.io
username: ${{ github.actor }}
password: ${{ secrets.GITHUB_TOKEN }}
- name: Download Docker image artifact
uses: actions/download-artifact@v3
with:
name: ${{ matrix.image_name }}-image
- name: Load Docker image
run: |
docker load -i ${{ matrix.image_name }}.tar
- name: Push image to GHCR
run: |
docker push ghcr.io/sartography/${{ matrix.image_name }}:${{ github.sha }}Explanation of Changes
Notes
Feel free to integrate these changes into your workflow. Let me know if you need further assistance! |
|
I'm not crazy about exporting and reimporting the images as tar files, and I see a few other problems with that which I'd want to fix. What do you think @burnettk? Fix it here, or fix it in a different PR in future? |
|
let's keep the quickstart guide test after the image push for now. it would be nice to test it before, as CI intended, but right now the docker compose file is just referencing |
|
Okay, in that case I think this is ready to go... I don't have an easy way to test it myself. Want to try merging? |
|
totally! |
|
OK, well, that didn't work very well.😞 |
|
OK, here's the reason... Loading only supports one architecture at a time. PR incoming. |
Addresses [the problem identfied here](#2174 (comment)).
* Only scan amd64-arch image for vulns Addresses [the problem identfied here](#2174 (comment)). * Add comment for future coders Explain why we're only building one arch initially.
|
@mogul after your second PR, the system was working, and the build started failing because of critical and high severity vulnerabilities in backend, frontend, and connector. 🥳 we ratcheted it down to just failing on critical level vulnerabilities, fixed the critical vulnerabilities by updating the Dockerfiles to ensure that updated packages were used, and it fixed the build (and there are corresponding closed items in the code scanning section of github). thank you very much for this contribution. this new tooling and visibility improves our security posture and gives us a strong foundation on which to iterate. |
With a little help from Claude.AI...! This consolidates multiple jobs into a single
create_docker_imagesjob using a matrix strategy. Along the way it removed a couple of (hopefully innocuous) inconsistencies between the three versions of the process.That turned out well so I also added security-scanning between image build and image push. Currently it doesn't push if there are any
criticalorhighfindings; you may want to adjust that. It also doesn't do anything to notify you when that happens; not sure if there's a good way to do that, or if GitHub Security will let you know on its own. 🤔Summary by CodeRabbit
New Features
Improvements