Skip to content

stable/8.8: EC2 integration tests fail — connectors start.sh 404 since camunda/connectors moved it #3069

Description

@leiicamundi

Symptom

Every aws_compute_ec2_single_region_tests.yml run on stable/8.8 fails. TestAllInOneScript, TestCloudWatchFeature and TestCamundaUpgrade all die the same way:

curl: (22) The requested URL returned error: 404
chmod: cannot access '/opt/camunda/connectors/start.sh': No such file or directory
sed: can't read /opt/camunda/connectors/start.sh: No such file or directory

Seen on run 31711299726, job 94485985984 (job: Run integration tests - arm64 - ec2-single-region - no-domain).

Cause

generic/compute/debian/procedure/camunda-install.sh:176 on stable/8.8:

curl -fL https://raw.githubusercontent.com/camunda/connectors/main/bundle/default-bundle/start.sh -o "${MNT_DIR}/connectors/start.sh"

That URL is an unpinned reference to another repository's default branch. On 2026-08-10, camunda/connectors reorganised its tree in 81a466b2chore(structure): simplify project structure by introducing an 'apps' and the file moved:

before bundle/default-bundle/start.sh
after apps/bundle/default-bundle/start.sh

Confirmed just now:

$ curl -o /dev/null -w '%{http_code} (%{size_download} bytes)' \
    https://raw.githubusercontent.com/camunda/connectors/main/bundle/default-bundle/start.sh
404 (14 bytes)

$ curl -o /dev/null -w '%{http_code} (%{size_download} bytes)' \
    https://raw.githubusercontent.com/camunda/connectors/main/apps/bundle/default-bundle/start.sh
200 (995 bytes)

Nothing changed in this repository. A file moved in another one, and @main followed it.

The 404 is not fatal to curl -fL in a way the script notices, so it proceeds to chmod and sed a file that does not exist, and the failure surfaces two commands later.

The fix already exists on main and stable/8.9

#2505fix(generic-debian): vendor connectors launcher to avoid Spring Boot jar mismatch, merged 2026-05-22 — removed the download entirely and writes the launcher inline:

# The connector-runtime-bundle is a Spring Boot uber-jar with its dependencies
# under BOOT-INF/lib/, so it can only be launched via "java -jar". The upstream
# start.sh from camunda/connectors@main is unpinned and historically used a
# flat-classpath invocation that broke whenever the bundle layout changed
# (e.g. the 8.9.4 release), making every fresh install fail with a JVM
# class-resolution error. Vendor a minimal self-contained launcher.
sudo -u "${USERNAME}" tee "${MNT_DIR}/connectors/start.sh" > /dev/null <<'LAUNCH'
#!/bin/bash
set -eu
SCRIPT_DIR="$(cd "$(dirname "$(readlink -f "$0")")" && pwd)"
# shellcheck disable=SC2086
exec java ${JAVA_OPTS:-} -jar "${SCRIPT_DIR}/connectors.jar"
LAUNCH

It was written for a different reason — the upstream launcher used a flat classpath that broke on the 8.9.4 bundle layout — and removing the unpinned fetch was a side effect. That side effect is what protects main and stable/8.9 from today's breakage.

It was never backported to stable/8.8. That is the whole bug.

Affected branches

branch state
main vendored launcher (#2505) — unaffected
stable/8.9 vendored launcher (#2505) — unaffected
stable/8.8 broken — still curls the moved URL
stable/8.7 generic/compute/debian/procedure/camunda-install.sh does not exist — unaffected
stable/8.6 same — unaffected

Suggested fix

Backport #2505's launcher hunk to stable/8.8. Preferred over repointing the URL at apps/bundle/default-bundle/start.sh, for two reasons:

  1. it converges 8.8 with main and 8.9 rather than creating a third variant;
  2. repointing keeps the @main dependency, so the next reorganisation upstream breaks it again. The vendored launcher has no upstream dependency at all.

Worth checking while there whether any other unpinned raw.githubusercontent.com/.../main/... fetches remain in the procedures — this class of failure is silent until a test happens to run.

Not a regression from recent work

The failure predates and is unrelated to #3054, which merely happened to trigger the workflow. The same job was already failing on renovate/main-... branches at 07:59 and 08:04 on 2026-08-13, before any of that work landed.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions