Add GitHub Actions workflow for DockerHub push

[kernelsam]

Pull request questions

Which issue does this address

Issue number: #nnn

Why was change needed

???

What does change improve

???

[github-actions]

🤖 Claude Code Review

Code Review: Docker Push Containers to DockerHub Workflow

✅ Code Quality

Style Guide Compliance

✅ PASS - The workflow follows GitHub Actions best practices and YAML formatting standards:

• Consistent indentation (2 spaces)
• Proper naming conventions using kebab-case
• Clear structure and organization

No Commented-Out Code

✅ PASS - No commented-out code present.

Meaningful Variable Names

✅ PASS - All variable names are descriptive:

• .github/workflows/docker-push-containers-to-dockerhub.yaml:24 - repo-basename clearly indicates repository name extraction
• .github/workflows/docker-push-containers-to-dockerhub.yaml:13 - status output is meaningful

DRY Principle

✅ PASS - The workflow efficiently reuses:

• Step outputs via steps.repo-basename.outputs.repo
• Shared GitHub Action senzing-factory/github-action-docker-buildx-build@v2
• Reusable workflow for Slack notifications

Defects / Logic Errors

❌ ISSUES FOUND:

1. Line 6: Version tag pattern may be too restrictive

   tags:
     - "[0-9]+.[0-9]+.[0-9]+"

   This pattern only matches basic semantic versions (e.g., 1.2.3) but won't match:

   • Pre-release versions: 1.2.3-beta.1, 1.2.3-rc.1
   • Build metadata: 1.2.3+20130313144700

   Recommendation: Consider if you want to support pre-release tags. Looking at CHANGELOG.md:8, you have versions like 0.4.1 which would match, but if you release beta versions as tags, they won't trigger this workflow.

2. Line 35: Missing attest-provenance parameter
   Comparing with the build workflow (.github/workflows/docker-build-container.yaml), this push workflow has sign-image: true but the build workflow doesn't have signing. Consider whether you also want attest-provenance: true for SLSA compliance.

Project Memory Configuration

✅ PASS - The CLAUDE.md configuration is appropriate and doesn't contain local-specific settings.

---

✅ Testing

N/A - GitHub Actions workflows don't typically have unit tests. However:

• The workflow can be tested via workflow_dispatch trigger (not present in this workflow)
• Consider adding workflow_dispatch for manual testing before releases

❌ RECOMMENDATION: Add workflow_dispatch: trigger (like in docker-build-container.yaml:7) to allow manual testing of the workflow.

---

❌ Documentation

README Updates

❌ FAIL - No README or documentation updates explaining:

• When this workflow runs (on semver tag pushes)
• What it does (pushes Docker images to DockerHub)
• How it differs from the existing docker-build-container.yaml

Location: Should document in /home/runner/work/sz-sdk-java-grpc/sz-sdk-java-grpc/.github/workflows/README.md or main README.md

CHANGELOG.md Updates

❌ FAIL - The CHANGELOG.md was not updated to reflect this new workflow.

Recommendation: Add an entry describing the addition of automated DockerHub push on version tags.

Inline Comments

✅ PASS - The workflow is self-documenting with clear step names.

---

✅ Security

No Hardcoded Credentials

✅ PASS - Uses GitHub Secrets:

• .github/workflows/docker-push-containers-to-dockerhub.yaml:32 - ${{ secrets.DOCKERHUB_ACCESS_TOKEN }}
• .github/workflows/docker-push-containers-to-dockerhub.yaml:35 - ${{ secrets.DOCKERHUB_USERNAME }}
• .github/workflows/docker-push-containers-to-dockerhub.yaml:42 - ${{ secrets.SLACK_BOT_TOKEN }}

Input Validation

⚠️ PARTIAL - .github/workflows/docker-push-containers-to-dockerhub.yaml:26 - The basename extraction should be safe, but consider validation:

echo "repo=$(basename ${{ github.repository }})" >> "$GITHUB_OUTPUT"

This assumes github.repository is well-formed. In practice, GitHub ensures this, so it's acceptable.

Proper Error Handling

✅ PASS - Uses always() condition for Slack notification (line 40) to handle failures.

No Sensitive Data in Logs

✅ PASS - Secrets are properly masked by GitHub Actions.

License Files Check

✅ PASS - No .lic files or AQAAAD strings found in the diff. The existing matches in the repository are:

• PDF documents (Contributor License Agreements) - acceptable
• Build resource files - not part of this PR

---

Summary

Critical Issues

None - workflow is functionally sound.

Recommendations for Improvement

1. Add to CHANGELOG.md - Document this new workflow
2. Consider version pattern - Decide if pre-release versions should trigger DockerHub pushes
3. Add workflow_dispatch - Enable manual testing
4. Consider SLSA attestation - Add attest-provenance: true for supply chain security
5. Document the workflow - Update README to explain the release process

Overall Assessment

The workflow is well-structured and secure. The main gaps are in documentation. The code quality is good, following GitHub Actions best practices. The workflow correctly:

• Uses proper permissions scoping
• Implements failure notifications
• Securely handles credentials
• Uses timeout protection
• Includes image signing

---

Automated code review analyzing defects and coding standards