Create docker-image.yml

[gitworkflows]

User description

What kind of change does this PR introduce?

• Bugfix
• [*] New Feature
• Feature Improvement
• Refactoring
• Documentation
• Other, please describe:

Description:

Checklist:

• I have read the CONTRIBUTING document.
• My changes don't require a change to the documentation, or if they do, I've added all required information.

---

PR Type

Enhancement

---

Description

• Added a new GitHub Actions workflow to automate the publishing of Docker images.
• The workflow triggers on push to the master branch and manual dispatch.
• Steps include setting up Docker Buildx, caching Docker layers, logging into Docker Hub, and building/pushing the Docker image.

---

Changes walkthrough 📝

	Relevant files
Enhancement	docker-image.yml Add GitHub Actions workflow for Docker image publishing    .github/workflows/docker-image.yml Added a GitHub Actions workflow to publish Docker images. Configured the workflow to trigger on push to the master branch and manual dispatch. Included steps for setting up Docker Buildx, caching Docker layers, logging into Docker Hub, and building/pushing the Docker image. +42/-0

---

💡 PR-Agent usage:
Comment /help on the PR to get a list of all available PR-Agent tools and their descriptions

Summary by Sourcery

Introduce a new GitHub Actions workflow to automate the building and publishing of a Docker image to Docker Hub when changes are pushed to the master branch.

CI:

• Add a GitHub Actions workflow to build and publish a Docker image on push to the master branch.

[sourcery-ai]

Reviewer's Guide by Sourcery

This pull request introduces a new GitHub Actions workflow file named 'docker-image.yml' to automate the process of building and publishing a Docker image. The workflow is triggered on pushes to the master branch or manually via workflow_dispatch. It sets up Docker Buildx, utilizes caching for Docker layers, logs into Docker Hub using secrets, and then builds and pushes the Docker image with the tag 'ml-buildkit:latest'.

File-Level Changes

Files	Changes
.github/workflows/docker-image.yml	Set up a new GitHub Actions workflow for building and publishing a Docker image
.github/workflows/docker-image.yml	Configure workflow triggers for manual dispatch and pushes to the master branch
.github/workflows/docker-image.yml	Set up Docker Buildx for multi-platform image building
.github/workflows/docker-image.yml	Implement caching for Docker layers to improve build performance
.github/workflows/docker-image.yml	Add step to log in to Docker Hub using secrets for authentication
.github/workflows/docker-image.yml	Configure Docker image build and push with specific tags and caching options

---

Tips

• Trigger a new Sourcery review by commenting @sourcery-ai review on the pull request.
• Continue your discussion with Sourcery by replying directly to review comments.
• You can change your review settings at any time by accessing your dashboard:
  • Enable or disable the Sourcery-generated pull request summary or reviewer's guide;
  • Change the review language;
• You can always contact us if you have any questions or feedback.

[codiumai-pr-agent-free]

PR Reviewer Guide 🔍

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

🧪 No relevant tests

🔒 No security concerns identified

⚡ No key issues to review

[codiumai-pr-agent-free]

PR Code Suggestions ✨

Category	Suggestion	Score
Security	Add a vulnerability scanning step before pushing the Docker image To enhance the security of the Docker image build process, consider adding a step to scan the Docker image for vulnerabilities before pushing it to Docker Hub. .github/workflows/docker-image.yml [34-42] - name: Build and push Docker image uses: docker/build-push-action@v6.7.0 with: context: . file: ./Dockerfile push: true tags: ${{ secrets.DOCKER_USERNAME }}/ml-buildkit:latest cache-from: type=local,src=/tmp/.buildx-cache cache-to: type=local,dest=/tmp/.buildx-cache +- name: Scan Docker image + uses: aquasecurity/trivy-action@v0.0.25 + with: + image-ref: ${{ secrets.DOCKER_USERNAME }}/ml-buildkit:latest + format: table Apply this suggestion Suggestion importance[1-10]: 10 Why: Adding a vulnerability scanning step enhances the security of the Docker image build process, which is crucial for maintaining a secure deployment pipeline.	10
Best practice	Specify a more specific version for the actions/checkout action Consider specifying a more specific branch or tag for the actions/checkout action to ensure stability and reproducibility of the workflow. Using a specific version or tag instead of a major version can prevent unexpected changes when new versions are released. .github/workflows/docker-image.yml [15] -uses: actions/checkout@v4 +uses: actions/checkout@v4.0.0 Apply this suggestion Suggestion importance[1-10]: 8 Why: Using a specific version for the actions/checkout action ensures stability and reproducibility by preventing unexpected changes from new major releases.	8
Enhancement	Enhance the specificity of the cache key in the caching step To avoid potential cache collisions which can lead to unexpected behavior, consider adding more specificity to the cache key by including additional variables like branch name or other identifiers. .github/workflows/docker-image.yml [24-26] -key: ${{ runner.os }}-buildx-${{ github.sha }} +key: ${{ runner.os }}-buildx-${{ github.sha }}-${{ github.ref }} restore-keys: | - ${{ runner.os }}-buildx- + ${{ runner.os }}-buildx-${{ github.ref }}- Apply this suggestion Suggestion importance[1-10]: 7 Why: Adding more specificity to the cache key helps avoid potential cache collisions, improving the reliability of the caching mechanism.	7

[sourcery-ai]

Hey @gitworkflows - I've reviewed your changes - here's some feedback:

Overall Comments:

• Consider adding a versioned tag (e.g., based on git tags or commits) alongside the 'latest' tag for better version tracking and easier rollbacks.
• The workflow currently triggers on every push to the master branch. Depending on your release process, you might want to consider a more specific trigger, such as tags or releases, to avoid unnecessary builds.

Here's what I looked at during the review

• 🟡 General issues: 2 issues found
• 🟡 Security: 1 issue found
• 🟢 Testing: all looks good
• 🟢 Complexity: all looks good
• 🟢 Documentation: all looks good

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment to tell me if it was helpful.}

[sourcery-ai]

🚨 suggestion (security): Consider using major version numbers for GitHub Actions

Using major version numbers (e.g., @v4 instead of @v4.x.x) allows for automatic updates to patch versions, which often include important bug fixes and security patches. This applies to all action versions in the workflow.

[sourcery-ai]

suggestion (performance): Consider adding a date to the cache key

Adding a date (e.g., $(date +%Y-%m-%d)) to the cache key ensures periodic cache invalidation, preventing issues with stale caches while maintaining performance benefits.

          key: ${{ runner.os }}-buildx-${{ github.sha }}-${{ github.run_number }}-${{ github.run_attempt }}-${{ steps.date.outputs.date }}

[sourcery-ai]

suggestion: Consider using a more specific tagging strategy

Using only the 'latest' tag can lead to issues with reproducibility and versioning. Consider incorporating the git SHA (e.g., ${GITHUB_SHA::8}) or a semantic version in addition to or instead of 'latest'.

Suggested change

	tags: ${{ secrets.DOCKER_USERNAME }}/ml-buildkit:latest
	tags: |
	${{ secrets.DOCKER_USERNAME }}/ml-buildkit:latest
	${{ secrets.DOCKER_USERNAME }}/ml-buildkit:${{ github.sha }}