Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 51.45%. Comparing base (1aa6bb0) to head (c8a009a).
⚠️ Report is 10 commits behind head on develop.

@@             Coverage Diff             @@
##           develop    #2123      +/-   ##
===========================================
- Coverage    51.47%   51.45%   -0.02%     
===========================================
  Files          881      881              
  Lines       153865   153865              
===========================================
- Hits         79198    79175      -23     
- Misses       69495    69516      +21     
- Partials      5172     5174       +2     

@claude Any issues you can see with this new workflow? Any improvements you'd suggest?

Claude finished @adamdossa's task in 1m 24s —— View job

Workflow Review Complete

I've reviewed the new GHCR publishing workflow. Here's my analysis:

✅ What's Good

1. Security Best Practices

   • Uses GITHUB_TOKEN for authentication (no hardcoded secrets)
   • Minimal permissions granted (contents: read, packages: write)
   • Implements build attestations for supply chain security
   • Uses official Docker actions with pinned major versions

2. Build Configuration

   • Multi-platform builds (linux/amd64, linux/arm64) ✓
   • Uses Docker Buildx for efficient builds
   • QEMU setup for cross-platform compilation

3. Tagging Strategy

   • Automatic tag extraction from git tags
   • Triggers only on version tags (v*..), not on branch pushes

⚠️ Issues & Improvements

1. Missing Dockerfile Specification

Issue: The workflow doesn't specify which Dockerfile to use (line 49-57).

Current behavior: Will use the default Dockerfile in the root, which is a multi-stage build that compiles from source.

Concern: The existing release workflow (.github/workflows/release.yml) uses GoReleaser with Dockerfile.release, which expects pre-built binaries and includes genesis files. This creates two different Docker image build strategies:

• GHCR workflow: Builds from source using Dockerfile
• DockerHub workflow (via GoReleaser): Uses pre-built binaries with Dockerfile.release

Recommendation: Decide on a consistent approach:

• Option A: Use the same Dockerfile for both (current setup) but ensure genesis files aren't needed
• Option B: Align with GoReleaser by adding a build step and using Dockerfile.release:

  - name: Build bor binary
    run: make bor
  
  - name: Build and push Docker image
    uses: docker/build-push-action@v6
    with:
      context: .
      file: Dockerfile.release
      push: true
      tags: ${{ steps.image_tag.outputs.tags }}
      labels: ${{ steps.image_tag.outputs.labels }}
      platforms: linux/amd64,linux/arm64

2. Missing Genesis Files

Issue: The default Dockerfile (used by this workflow) doesn't include genesis files, but Dockerfile.release (used by GoReleaser) copies three genesis files:

• builder/files/genesis-amoy.json
• builder/files/genesis-mainnet-v1.json
• builder/files/genesis-testnet-v4.json

Impact: Users pulling from GHCR won't have genesis files available, while DockerHub images will include them.

Recommendation: Either:

• Update Dockerfile to include genesis files if needed
• Or document that GHCR images require external genesis files

3. No Build Caching

Issue: The workflow rebuilds from scratch every time, which can be slow for large Go codebases.

Recommendation: Add layer caching:

- name: Build and push Docker image
  uses: docker/build-push-action@v6
  with:
    context: .
    push: true
    tags: ${{ steps.image_tag.outputs.tags }}
    labels: ${{ steps.image_tag.outputs.labels }}
    platforms: linux/amd64,linux/arm64
    cache-from: type=gha
    cache-to: type=gha,mode=max

4. IMAGE_NAME Casing Inconsistency

Minor: Line 13 uses IMAGE_NAME: 0xPolygon/bor (uppercase 'P'), while GoReleaser uses lowercase 0xpolygon/bor (line 114, 130 in .goreleaser.yml).

Impact: GitHub Container Registry is case-sensitive, so this will create a different image name: ghcr.io/0xPolygon/bor vs 0xpolygon/bor on DockerHub.

Recommendation: Match GoReleaser's casing for consistency:

IMAGE_NAME: 0xpolygon/bor

5. Missing latest Tag

Issue: GoReleaser creates a latest tag (line 151), but this workflow only creates version-specific tags.

Recommendation: Add latest tag for the most recent release:

- name: Extract tags for image
  id: image_tag
  uses: docker/metadata-action@v5
  with:
    images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
    tags: |
      type=ref,event=tag
      type=raw,value=latest,enable={{is_default_branch}}

6. Workflow Name Mismatch

Minor: Line 1 has name: build_and_publish_to_ghcr.yml (includes .yml extension), but workflow names shouldn't include the file extension.

Recommendation: Remove extension:

name: Build and Publish to GHCR

7. No PR Trigger for Testing

Issue: The workflow only runs on tags, making it hard to test changes to the workflow itself.

Recommendation: Add a workflow_dispatch trigger for manual testing:

on:
  push:
    branches-ignore:
      - '**'
    tags:
      - 'v*.*.*'
      - 'v*.*.*-*'
  workflow_dispatch:  # Allow manual triggering for testing

8. Missing Provenance/SBOM Flags

Note: GoReleaser explicitly disables provenance and SBOM with --provenance=false --sbom=false (lines 122-123, 138-139), but this workflow uses attestations instead.

Recommendation: This is actually better than GoReleaser's approach (attestations are the modern standard), but document this difference if both images should have identical metadata.

🔍 SonarQube Security Hotspots

The 5 security hotspots flagged by SonarQube are likely false positives for workflow files (they often flag Docker credentials, which are properly handled here via GITHUB_TOKEN).

Summary

The workflow is fundamentally sound with good security practices. The main concerns are:

1. Dockerfile inconsistency with existing release process (different build strategy)
2. Missing genesis files compared to DockerHub images
3. Image naming casing differs from DockerHub
4. Missing latest tag for convenience

My recommendation: Align this workflow with the existing GoReleaser setup to ensure GHCR and DockerHub images are functionally identical, or explicitly document the differences if intentional.

Addressing the comments from Claude:

1. Missing Dockerfile Specification - Since we use the default dockerfile we do not need to explicitly mention it in the workflow, it gets picked up automatically.
2. Missing Genesis Files - The node operators need to download this file (depending on the network)after they pull the image, so we do not need to add this step here.
3. No Build Caching - I tested this on our tester repos and it does not make any difference on the time it takes to build and publish the image on GHCR. Hence I removed these lines to minimise the number of lines on the workflow file.
4. IMAGE_NAME Casing Inconsistency - We want it to be consistent with the repo name and so I kept it this way.
5. Missing latest Tag - The latest tag will be added to the latest image when published on GHCR.
6. Workflow Name Mismatch - I used the naming standards we keep on pos-ops, this will not break anything.
7. No PR Trigger for Testing - We already tested it on the tester repos and it triggers when a new tag is created.
8. Missing Provenance/SBOM Flags - Claude says we did it in a better way.

Quality Gate failed

Failed conditions
5 Security Hotspots

See analysis details on SonarQube Cloud