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 81a466b2 — chore(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
#2505 — fix(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:
- it converges 8.8 with
main and 8.9 rather than creating a third variant;
- 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.
Symptom
Every
aws_compute_ec2_single_region_tests.ymlrun onstable/8.8fails.TestAllInOneScript,TestCloudWatchFeatureandTestCamundaUpgradeall die the same way:Seen on run 31711299726, job 94485985984 (job:
Run integration tests - arm64 - ec2-single-region - no-domain).Cause
generic/compute/debian/procedure/camunda-install.sh:176onstable/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/connectorsreorganised its tree in81a466b2— chore(structure): simplify project structure by introducing an 'apps' and the file moved:bundle/default-bundle/start.shapps/bundle/default-bundle/start.shConfirmed just now:
Nothing changed in this repository. A file moved in another one, and
@mainfollowed it.The 404 is not fatal to
curl -fLin a way the script notices, so it proceeds tochmodandseda file that does not exist, and the failure surfaces two commands later.The fix already exists on main and stable/8.9
#2505 — fix(generic-debian): vendor connectors launcher to avoid Spring Boot jar mismatch, merged 2026-05-22 — removed the download entirely and writes the launcher inline:
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
mainandstable/8.9from today's breakage.It was never backported to
stable/8.8. That is the whole bug.Affected branches
mainstable/8.9stable/8.8stable/8.7generic/compute/debian/procedure/camunda-install.shdoes not exist — unaffectedstable/8.6Suggested fix
Backport #2505's launcher hunk to
stable/8.8. Preferred over repointing the URL atapps/bundle/default-bundle/start.sh, for two reasons:mainand 8.9 rather than creating a third variant;@maindependency, 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.