Update and rename ghcr.yml to container_image.yaml

[venkatamutyala]

PR Type

enhancement, configuration changes

---

Description

• Introduced a new GitHub Actions workflow to automate the process of building, tagging, and publishing Docker images to GHCR.io.
• The new workflow includes steps for setting up QEMU, Docker buildx, logging into the registry, extracting Docker metadata, and building/pushing Docker images.
• Removed the old workflow file ghcr.yml to replace it with the updated container_image.yaml.

---

Changes walkthrough 📝

	Relevant files
Enhancement	container_image.yaml Add GitHub Actions workflow for Docker image publishing    .github/workflows/container_image.yaml Added a new GitHub Actions workflow for publishing Docker images to GHCR.io. Configured environment variables for registry and image name. Included steps for setting up QEMU, Docker buildx, and logging into the registry. Added steps for extracting Docker metadata and building/pushing Docker images. +56/-0
Configuration changes	ghcr.yml Remove outdated Docker image workflow                                        .github/workflows/ghcr.yml Removed the old GitHub Actions workflow for building and pushing Docker images. +0/-10

---

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[codiumai-pr-agent-free]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 2 🔵🔵⚪⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Security Consideration The workflow is using a GitHub token with write permissions to packages, which might be more than necessary for some operations. Potential Improvement The workflow runs on every push, which might lead to unnecessary builds and pushes for non-main branches. Version Pinning While the workflow uses specific commit hashes for actions, it's worth reviewing if these are the latest stable versions.

[codiumai-pr-agent-free]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Score
Security	Add a vulnerability scanning step before pushing the Docker image Add a step to scan the Docker image for vulnerabilities before pushing it to the registry. This can be done using tools like Trivy or Snyk, which can be easily integrated into GitHub Actions workflows. This step will help ensure that you're not pushing images with known security vulnerabilities. .github/workflows/container_image.yaml [46-56] -- name: Build and push Docker image - id: build-and-push +- name: Build Docker image + id: build uses: docker/build-push-action@ca052bb54ab0790a636c9b5f226502c73d547a25 # v5.4.0 with: context: . - push: ${{ github.event_name != 'pull_request' }} + push: false tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} - provenance: false cache-from: type=gha cache-to: type=gha,mode=max +- name: Scan image for vulnerabilities + uses: aquasecurity/trivy-action@master + with: + image-ref: ${{ steps.meta.outputs.tags }} + format: 'table' + exit-code: '1' + ignore-unfixed: true + vuln-type: 'os,library' + severity: 'CRITICAL,HIGH' + +- name: Push Docker image + if: success() && github.event_name != 'pull_request' + uses: docker/build-push-action@ca052bb54ab0790a636c9b5f226502c73d547a25 # v5.4.0 + with: + context: . + push: true + tags: ${{ steps.meta.outputs.tags }} + labels: ${{ steps.meta.outputs.labels }} + Apply this suggestion Suggestion importance[1-10]: 9 Why: Introducing a vulnerability scanning step significantly enhances the security of the Docker images by ensuring that known vulnerabilities are detected and addressed before deployment. This is a crucial addition for maintaining secure software practices.	9
	Enable Docker content trust to ensure only signed images are pushed Enable Docker content trust by setting the DOCKER_CONTENT_TRUST environment variable to 1. This ensures that only signed images are pushed to the registry, enhancing the security and integrity of your container images. .github/workflows/container_image.yaml [46-56] - name: Build and push Docker image id: build-and-push uses: docker/build-push-action@ca052bb54ab0790a636c9b5f226502c73d547a25 # v5.4.0 + env: + DOCKER_CONTENT_TRUST: 1 with: context: . push: ${{ github.event_name != 'pull_request' }} tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} provenance: false cache-from: type=gha cache-to: type=gha,mode=max Apply this suggestion Suggestion importance[1-10]: 8 Why: Enabling Docker content trust adds a layer of security by ensuring that only signed images are pushed to the registry, which helps in maintaining the integrity and authenticity of the images.	8
Best practice	Refine the workflow trigger conditions to run only on specific events or branches Consider adding a condition to the on trigger to limit when this workflow runs. For example, you might want to run this workflow only on pushes to specific branches or on release events. This can help reduce unnecessary workflow runs and save on GitHub Actions usage. .github/workflows/container_image.yaml [3] -on: [push] +on: + push: + branches: [main, develop] + release: + types: [published] Apply this suggestion Suggestion importance[1-10]: 8 Why: This suggestion improves the efficiency of the workflow by limiting its execution to specific branches or release events, which can save resources and reduce unnecessary runs. It is a best practice for managing CI/CD workflows.	8
	Generate and publish a Software Bill of Materials (SBOM) for the Docker image Consider adding a step to generate and push a Software Bill of Materials (SBOM) for the Docker image. This can be done using tools like Syft, which can generate SBOMs in various formats. Publishing an SBOM alongside your image enhances transparency and helps users understand the components and dependencies of your container. .github/workflows/container_image.yaml [46-56] - name: Build and push Docker image id: build-and-push uses: docker/build-push-action@ca052bb54ab0790a636c9b5f226502c73d547a25 # v5.4.0 with: context: . push: ${{ github.event_name != 'pull_request' }} tags: ${{ steps.meta.outputs.tags }} labels: ${{ steps.meta.outputs.labels }} provenance: false cache-from: type=gha cache-to: type=gha,mode=max +- name: Generate SBOM + uses: anchore/sbom-action@v0 + with: + image: ${{ steps.meta.outputs.tags }} + artifact-name: image-sbom.spdx.json + output-file: ./image-sbom.spdx.json + +- name: Upload SBOM + uses: actions/upload-artifact@v3 + with: + name: image-sbom + path: ./image-sbom.spdx.json + Apply this suggestion Suggestion importance[1-10]: 7 Why: Generating and publishing an SBOM increases transparency and helps users understand the components and dependencies of the Docker image. This is a valuable practice for compliance and security auditing.	7

💡 Need additional feedback ? start a PR chat