chore(diagram-converter): deploy latest version

[venetrius]

related to: /issues/417

Pull Request Template

The PR adds a Github Action to deploy the Diagram Converter (which happens manually today)
Testing plan:

• Merge changes
• Run action as Dry run, observe failure
• Set up OpenId Connect secrets in Github
• Run action as Dry run - iterate if required
• After it deemed to work properly the general release workflow could call this GHA as a step

Description

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactoring (no functional changes)
• Test-only changes (no production code changes)

Testing Checklist

Black-Box Testing Requirements

• Tests follow black-box testing approach: verify behavior through observable outputs (logs, C8 API queries, real-world skip scenarios)
• Tests DO NOT access implementation details (DbClient, IdKeyMapper, ..impl.. packages except logging constants)
• Architecture tests pass (ArchitectureTest validates these rules)

Test Coverage

• Added tests for new functionality
• Updated tests for modified functionality
• All tests pass locally

Architecture Compliance

Run architecture tests to ensure compliance:

mvn test -Dtest=ArchitectureTest

If architecture tests fail, refactor your tests to use:

• LogCapturer for log assertions
• camundaClient.new*SearchRequest() for C8 queries
• Real-World skip scenarios (e.g., migrate children without parents)

Documentation

• Updated TESTING_GUIDELINES.md if adding new test patterns
• Added Javadoc comments for public APIs
• Updated README if user-facing changes

Checklist

• Code follows project style guidelines
• Self-reviewed the code
• Added comments for complex logic
• No new compiler warnings
• Dependent changes have been merged

Related Issues

[Copilot]

Pull request overview

Adds a manual GitHub Actions workflow to deploy a released Diagram Converter webapp artifact by building a container image, pushing it to AWS ECR, and triggering an ECS service redeploy.

Changes:

• Introduces a workflow_dispatch deployment pipeline with RELEASE_VERSION and optional IS_DRY_RUN.
• Downloads the released webapp JAR from GitHub Releases and builds/pushes a multi-arch Docker image to ECR.
• Triggers an ECS force-new-deployment, waits for stabilization, and runs post-deploy verification/health checks.

Comments suppressed due to low confidence (1)

.github/workflows/deploy-diagram-converter.yml:121

• The version tag expression is duplicated in multiple places (build tags, and should also be used in verification). To reduce the risk of inconsistencies like dry-run/tag mismatches, consider defining a single env var for the effective versioned tag (e.g., normal vs -dry-run) and reusing it across steps.

      - name: Build and push multi-platform Docker image
        uses: docker/build-push-action@v6
        with:
          context: ./docker-context
          platforms: linux/amd64,linux/arm64
          push: true
          tags: |
            ${{ steps.ecr-login.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ inputs.IS_DRY_RUN && format('{0}-dry-run', env.RELEASE_VERSION) || env.RELEASE_VERSION }}
            ${{ steps.ecr-login.outputs.registry }}/${{ env.ECR_REPOSITORY }}:${{ inputs.IS_DRY_RUN && 'dry-run' || 'latest' }}
          cache-from: type=gha

[HeleneW-dot]

Looks good, just requesting changes for the question re the latest tag.

Can we also update the confluence pages?

Do we need to merge before we can do a test dry run?

[HeleneW-dot]

Question: I dont see a step that creates the diagram converter tag in the release guide or the diagram converter guide. Or is the diagram converter tag the same as for the data migrator and it would be created when the data migrator release is built here?

[venetrius]

All migration tooling shares the same tag. I verified the logic by running this script:

#!/usr/bin/env bash
#
# Test the gh CLI steps from deploy-diagram-converter.yml locally.
#
# Prerequisites:
#   brew install gh
#   gh auth login
#
# Usage:
#   .github/scripts/test-deploy-locally.sh <RELEASE_VERSION>
#
# Example:
#   .github/scripts/test-deploy-locally.sh 0.2.0
#

set -euo pipefail

RELEASE_VERSION="${1:?Usage: $0 <RELEASE_VERSION>}"
REPO="camunda/camunda-7-to-8-data-migrator"

echo "=== Step 1: Validate version format ==="
if [[ ! "${RELEASE_VERSION}" =~ ^[0-9]+\.[0-9]+\.[0-9]+$ ]]; then
  echo "❌ Invalid version format '${RELEASE_VERSION}'. Expected semantic version (e.g., 0.2.0)."
  exit 1
fi
echo "✅ Version format OK: ${RELEASE_VERSION}"

echo ""
echo "=== Step 2: Verify release exists ==="
if ! gh release view "${RELEASE_VERSION}" --repo "${REPO}" > /dev/null 2>&1; then
  echo "❌ Release '${RELEASE_VERSION}' not found at https://github.com/${REPO}/releases"
  exit 1
fi
echo "✅ Release '${RELEASE_VERSION}' exists"

echo ""
echo "=== Step 3: Download release artifact ==="
SCRIPT_DIR="$(cd "$(dirname "${BASH_SOURCE[0]}")" && pwd)"
OUTPUT_DIR="${SCRIPT_DIR}/docker-context"
mkdir -p "${OUTPUT_DIR}"

echo "Downloading webapp JAR from release ${RELEASE_VERSION} into ${OUTPUT_DIR}..."
gh release download "${RELEASE_VERSION}" \
  --repo "${REPO}" \
  --pattern "camunda-7-to-8-diagram-converter-webapp-${RELEASE_VERSION}.jar" \
  --dir "${OUTPUT_DIR}" \
  --clobber

JAR_FILE="${OUTPUT_DIR}/camunda-7-to-8-diagram-converter-webapp-${RELEASE_VERSION}.jar"
if [[ -f "${JAR_FILE}" ]]; then
  cp "${JAR_FILE}" "${OUTPUT_DIR}/app.jar"
  echo "✅ Artifact downloaded and copied to app.jar"
  ls -lh "${OUTPUT_DIR}/"
else
  echo "❌ Expected JAR not found in download directory"
  ls -lh "${OUTPUT_DIR}/"
  exit 1
fi

echo ""
echo "=== All checks passed ✅ ==="
echo "The gh CLI commands from the workflow work correctly for release ${RELEASE_VERSION}."
echo "JAR available at:"
echo "  ${JAR_FILE}"
echo "  ${OUTPUT_DIR}/app.jar"

[HeleneW-dot]

If we release a patch for an older minor version does this mean it would always be tagged as latest?

[venetrius]

That is a good question.
We only have a single version of the diagram converter hosted, and there is no plan to have more. Currently we manually deploy if a new patch is released for the last minor.
I will add a new option to the release workflow Deploy diagram converter? (Only for latest minor) so the deployment only runs when intended.

[HeleneW-dot]

Ah I see. So if we release a patch of an older minor, we can skip the diagram converter step? Can we also add this to the release guide

[venetrius]

Yes, that is correct. Will add it to the release guide.

[HeleneW-dot]

Can we also add image tags to this overview?

[venetrius]

Updated.

[HeleneW-dot]

Meant to request changes as above

[venetrius]

Looks good, just requesting changes for the question re the latest tag.

Can we also update the confluence pages?

👍 Updated the issue description to highlight this as a step. Will do it after all the PR-s are merged and tested.

Do we need to merge before we can do a test dry run?

Yes, otherwise is does not show up at https://github.com/camunda/camunda-7-to-8-migration-tooling/actions and can't be triggered.

[HeleneW-dot]

Lgtm lets merge and do a test run. I think it would also make sense to "review" the confluence page once updated to make sure the process is clear in combination with the workflow