Code duplication (DRY violations) in reusable workflows

[shawn-hurley]

Description

Both global-ci.yml and global-ci-bundle.yml contain significant code duplication between API and UI test jobs, with TODO comments noting this issue.

Locations

• .github/workflows/global-ci.yml
• .github/workflows/global-ci-bundle.yml

Details

TODO comments acknowledging the issue:

• global-ci-bundle.yml:298 - "TODO Should DRY this"
• global-ci-bundle.yml:424 - "TODO Should DRY this"
• global-ci.yml:197 - "TODO Should DRY this"
• global-ci.yml:341 - "TODO Should DRY this"

Duplicated code blocks:

Both API and UI test jobs repeat the following setup steps:

1. Docker buildx setup

   - name: set up docker buildx
     uses: docker/setup-buildx-action@v2

2. Minikube start (with version-specific conditionals in global-ci.yml)

   - name: start minikube
     uses: konveyor/tackle2-operator/.github/actions/start-minikube@...

3. Artifact download

   - name: Download artifact
     uses: actions/download-artifact@v4

4. Image loading

   - name: Load images
     run: |
       eval $(minikube -p minikube docker-env)
       for image in $(find "${IMAGES_PATH}" -type f -name "*.tar"); do
         docker load --input ${image}
       done

5. Bundle creation/installation (in global-ci-bundle.yml)

   - name: Make bundle
   - name: Push bundle
   - name: Install konveyor

6. Konveyor installation (in global-ci.yml with version conditionals)

   - name: install konveyor (multiple conditional steps)

Impact

• Maintenance burden: Changes must be made in multiple places (2 jobs × 2 workflows = 4 locations)
• Drift risk: Jobs can drift apart if updates aren't applied consistently
• Harder reviews: More code to review and understand
• Longer workflows: Duplicated YAML increases file size
• Already drifting: Issue API tests missing java-provider-image configuration in global-ci.yml #139 shows API/UI jobs already have different configurations (java-provider-image)

Recommendation

Option 1: Create composite action (preferred)

Extract common setup into .github/actions/setup-test-environment/action.yml:

• Docker buildx setup
• Minikube start
• Artifact download and loading
• Konveyor installation

Option 2: Use job-level reusable workflow

Create .github/workflows/setup-konveyor.yml that both test jobs can call.

Option 3: Use YAML anchors (limited in GitHub Actions)

GitHub Actions has limited support, but could work for some shared config.

Example composite action structure:

name: Setup Konveyor Test Environment
inputs:
  operator_tag:
    description: Operator version
    required: true
  component_name:
    description: Component to test
    required: false
  # ... other inputs
runs:
  using: composite
  steps:
    - name: set up docker buildx
      # ...
    - name: start minikube
      # ...
    # etc.

Then both jobs would just use:

- name: Setup test environment
  uses: ./.github/actions/setup-test-environment
  with:
    operator_tag: ${{ inputs.operator_tag }}
    # ... other inputs

Benefits of fixing:

• Single source of truth for setup logic
• Consistent behavior between API and UI tests
• Easier maintenance and updates
• Reduced chance of configuration drift
• Shorter, more readable workflow files

Related Files

• .github/workflows/global-ci.yml:197-275 (API test setup)
• .github/workflows/global-ci.yml:341-422 (UI test setup)
• .github/workflows/global-ci-bundle.yml:298-355 (API test setup)
• .github/workflows/global-ci-bundle.yml:424-481 (UI test setup)