feat: add reusable build-and-push-to-ECR workflow

[ashwinimanoj-habuild]

Summary

• Adds a composite action for building Docker images and pushing to ECR
• Tags images with full git SHA, short SHA, and latest for backwards compatibility with ECS
• aws-account-id is a required input since it differs per environment
• All logic extracted into standalone scripts (testable locally, lintable with shellcheck)

Structure

.github/actions/build-push-ecr/
  action.yml              # composite action — inputs, outputs, steps
  scripts/
    validate.sh            # input validation
    set-metadata.sh        # ECR repo URI, tags, dockerfile
    ensure-ecr-repo.sh    # auto-create ECR repo with scan-on-push
    check-existing-image.sh  # skip build if SHA already in ECR
    notify-clickup.sh      # success/failure notifications via jq

Features

• BuildKit + GHA cache for fast cached builds via docker/build-push-action
• ECR auto-creation — new services don't need manual repo setup
• Skip redundant builds — if SHA tag already exists in ECR, build is skipped
• Atomic push — docker/build-push-action pushes all tags in one manifest operation
• Failure notifications — ClickUp notified on both success and failure
• Input validation — service-name, environment, account-id, dockerfile path all validated
• OCI labels — images tagged with source repo, commit SHA, and CI run URL for traceability
• Actions pinned to SHA — all third-party actions pinned to immutable commit SHAs

Usage

steps:
  - uses: actions/checkout@v4

  - uses: habuildserver/.github/.github/actions/build-push-ecr@main
    id: build
    with:
      service-name: chat-service
      environment: development
      aws-account-id: '963127282571'
      sdk-token: ${{ secrets.SDK_TOKEN }}

  - run: echo "Pushed ${{ steps.build.outputs.image-uri }}"

Migration path

Each service replaces its inline build+push steps with a single composite action call. ECS deploys keep working (latest tag), while K8s/ArgoCD uses the SHA tag.

[Anshulhabuild]

Summary

This pull request introduces a reusable GitHub Actions workflow that builds a Docker image and pushes it to Amazon ECR. It supports a variety of repo configurations (single-service, mono-repo, and workers) and includes optional notifications to ClickUp. Overall, the workflow is designed to be flexible and parameter-driven, allowing the configuration of build arguments, Dockerfile location, and AWS credentials dynamically.

✅ Good Practices

• The workflow provides clear usage examples and detailed inline documentation at the top, making it easy for other developers to integrate and understand.
• Input validation is implemented early in the workflow (e.g., verifying that the service name matches a regex and that the environment is one of a fixed set), which helps catch configuration mistakes early.
• The use of AWS OIDC for credential configuration (via aws-actions/configure-aws-credentials) promotes secure, short-lived credentials.
• The workflow leverages Docker tagging best practices by tagging images with both the Git SHA (for reproducibility) and latest (for ease of deployment).
• The conditional steps, such as configuring npm for private packages and sending notifications to ClickUp, are well-contained with clear conditions.

🚨 Critical Issues

• None of the steps appear to create significant security vulnerabilities. However, it is crucial to ensure that any token used (e.g., SDK_TOKEN, CLICKUP_TOKEN) is properly masked and that the credentials are rotated regularly.
• The direct use of secrets in build arguments (like passing SDK_TOKEN into the Docker build) should be carefully monitored to avoid inadvertently exposing these secrets in logs if not handled securely within the Dockerfile.

⚠️ Suggestions

• Consider adding error handling or more informative logging for the Docker build step, so that failures in building or pushing images are easier to diagnose.
• In the "Notify ClickUp" step, if the curl command fails, a final log or alert could be helpful even if the error is deemed non-blocking.
• The determination of the Dockerfile location using an inline expression might be abstracted into a separate script or step to improve clarity, especially for maintainers not already familiar with GitHub Actions expressions.

📝 Minor Issues

• The environment variable mappings in the steps are clear, but adding additional inline comments for variables (like ECR_REPO and SHA_TAG) might improve readability for new contributors.
• The regex for the service name only allows lowercase letters and hyphens; ensure this aligns with how service names are defined across the project.
• The condition for checking submodules uses a ternary-style pattern in the inputs, which might be simplified or more explicitly documented to avoid misunderstandings.
• Consider using double quotes for all environment variable usages in shell scripts to further guard against potential word splitting or globbing issues.

Questions

• Is there a specific reason for the default notify-clickup input being set to true? Under what circumstances might a user want to disable this, aside from leaving the CLICKUP_TOKEN secret empty?
• Are there plans to include additional error handling if the Docker push commands fail, or is the current level of logging deemed sufficient for troubleshooting?
• For the dynamic Dockerfile determination in the "Set image metadata" step, would it be beneficial to validate that the provided Dockerfile path exists before proceeding with the build?

These comments should guide further refinements and potential discussion points. Overall, the changes improve the CI/CD process in a clear and flexible manner.