8000 Fix unix permissions by aadant · Pull Request #10 · Altinity/clickhouse-sink-connector · GitHub
[go: up one dir, main page]

Skip to content

Fix unix permissions - #10

Merged
subkanthi merged 1 commit into
Altinity:mainfrom
aadant:fix_unix_permissions
Jul 19, 2022
Merged

subkanthi merged 1 commit into
Altinity:mainfrom
aadant:fix_unix_permissions

Conversation

@aadant
@aadant aadant commented Jul 19, 2022 •
Copy link
Copy Markdown
Collaborator

Just applied

find . | grep .sh$ | xargs -I {} chmod +x {}

@subkanthi
subkanthi merged commit 7e822f1 into Altinity:main Jul 19, 2022
@aadant
aadant deleted the fix_unix_permissions branch July 19, 2022 23:29
subkanthi added a commit that referenced this pull request Aug 11, 2022
minguyen9988 added a commit that referenced this pull request Aug 22, 2026
…e build (#1392)

The `build-kafka-lightweight / build` job on PR #1304 failed and took six
downstream jobs with it (publish-lightweight-jar, checksum-tests-lightweight,
java-tests-kafka, java-tests-lightweight, and both testflows jobs were all
SKIPPED behind it). Maven itself was fine; the failure is in the Docker image
build:

  #10 [ 5/11] RUN 'curl' '-L' '--output'
      '/kafka/libs/kafka-connect-avro-converter-7.2.1.jar'
      'https://packages.confluent.io/maven/io/confluent/kafka-connect-avro-converter/7.2.1/kafka-connect-avro-converter-7.2.1.jar'
  #10 0.202 curl: (35) OpenSSL SSL_connect: Connection reset by peer in
            connection to packages.confluent.io:443
  ERROR: failed to solve: ... did not complete successfully: exit code: 35

(run 32575512953, head 44d32d3)

The URL is not broken -- it returns HTTP 200 on retry. A single transient TLS
reset from packages.confluent.io aborted the whole image build, because the
seven downloads in this Dockerfile run as a bare `curl -L` with no retry.

A second, more dangerous defect in the same lines
-------------------------------------------------
`curl -L` without `--fail` treats an HTTP error as SUCCESS: it exits 0 and
writes the error BODY to the output path. Verified on curl 7.76.1, the same
version the base image ships:

  $ curl -L --output bad.jar <404 url>; echo $?
  0
  $ ls -l bad.jar
  353 bytes
  $ head -c 60 bad.jar
  <?xml version="1.0" encoding="UTF-8"?><Error><Code>NoSuchKe...

So a 404 or 403 from the artifact host produces a ~350-byte XML document named
*.jar and the image builds "successfully" with a corrupt dependency. That
failure would surface far downstream, as a puzzling ClassNotFound or a zip
error, rather than at the download that caused it.

The fix
-------
All seven downloads now use:

  --fail                 exit non-zero on an HTTP error instead of writing the
                         error body to a .jar
  --retry 5
  --retry-connrefused
  --retry-all-errors     retry the transient resets rather than failing the
                         build on the first one
  --connect-timeout 30
  --max-time 600         bound a hung connection so the job fails fast

Kept as separate RUN layers so the existing layer-cache behaviour is unchanged.

Version gate
------------
`--retry-all-errors` requires curl >= 7.71. This Dockerfile is
FROM debezium/connect-base:1.9.5.Final, which ships curl 7.76.1 (verified by
running `curl --version` inside quay.io/debezium/connect-base:1.9.5.Final), so
the flag is supported. Worth stating explicitly because a host with an older
curl rejects the flag outright with "option --retry-all-errors: is unknown",
which would turn a robustness fix into a hard build break.

Scope
-----
Six Dockerfiles in the repo contain curl invocations, but the CI workflows
build only Dockerfile-sink-on-debezium-base-image, so only that file is
changed here.

Verification (curl 7.76.1, matching the base image)
---------------------------------------------------
  case                                   exit   result
  ----                                   ----   ------
  real jar, new flags                    0      8645-byte jar written
  404 url, old flags (-L only)           0      353-byte XML error page
                                                written as .jar  <- the defect
  404 url, new flags                     22     no file written; stderr shows
                                                6 attempts (1 + 5 retries),
                                                confirming the retry loop runs

No Java or connector behaviour is touched by this change.

Co-authored-by: OmniWatcher <dba@jumptrading.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

0