chore(ci+cd): improve docker build

[doronkopit5]

Important

Enhances Docker build process with multi-platform support and caching, and fixes a logging typo in pipeline.rs.

• CI/CD:
  • Adds docker-build-test job in ci.yml for multi-platform Docker builds (amd64, arm64).
  • Updates docker.yml to include caching in Docker build steps.
• Dockerfile:
  • Introduces multi-stage build with cargo-chef for dependency caching.
  • Switches runtime base image to Alpine for smaller size and adds non-root user for security.
• Code:
  • Fixes minor logging typo in chat_completions() in pipeline.rs.

^{This description was created by for e767cb4. You can customize this summary. It will automatically update as commits are pushed.}

[doronkopit5]

just to test and see times
i'll remove before merge

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 1cae0db in 1 minute and 50 seconds. Click for details.

• Reviewed 132 lines of code in 3 files
• Skipped 0 files when reviewing.
• Skipped posting 7 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/ci.yml:73

• Draft comment:
  Add a trailing newline at the end of this file for formatting consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While missing trailing newlines can cause issues with some tools and is generally considered good practice, this is a very minor formatting issue. It would likely be caught by linters or formatters. The CI workflow includes 'cargo fmt --check' which would catch this if it was important for the project. The missing newline could potentially cause issues with some tools. Also, it's a real change introduced in this PR. However, this is exactly the kind of minor formatting issue that should be caught by automated tools rather than manual review comments. The PR already includes formatting checks. This comment should be deleted as it's a minor formatting issue that would be caught by automated tools if it matters for this project.

2. .github/workflows/ci.yml:64

• Draft comment:
  Confirm that 'push: false' in the docker build step is intentional for the CI workflow (i.e. not pushing images).
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

3. .github/workflows/docker.yml:60

• Draft comment:
  Caching configuration (cache-from and cache-to) has been added; ensure this aligns with your build optimization strategy.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

4. Dockerfile:18

• Draft comment:
  Switching the runtime to Alpine may cause issues if the binary was built against glibc. Ensure the binary is compiled for musl (or is statically linked) to run on Alpine.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% This is a legitimate technical concern - Rust binaries built against glibc won't run on Alpine's musl libc. However, the Dockerfile already includes 'libgcc' in the Alpine packages, suggesting the author is aware of and handling compatibility. The comment is speculative ("may cause issues") and asks for verification ("Ensure the binary...") rather than definitively pointing out a problem. The compatibility issue could be a real problem that breaks the container at runtime. The addition of libgcc might not be sufficient. While the concern is valid, the comment violates our rules by being speculative and asking for verification rather than pointing out a definite issue. If there was a compatibility problem, it would be caught immediately during testing. Delete the comment because it is speculative and asks for verification rather than pointing out a definite issue that needs fixing.

5. Dockerfile:39

• Draft comment:
  Add a trailing newline at the end of the Dockerfile for consistency.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While having a trailing newline is a common convention, this is an extremely minor formatting issue. It doesn't affect functionality and would likely be caught by any linting tools if it was important to the team. The rules specifically say not to make comments about obvious or unimportant things. A missing trailing newline could cause issues with some tools or shell scripts that expect it. It's a widely accepted Unix convention. While true, this is still too minor to warrant a PR comment. If it's important to the team, it should be enforced by automation rather than manual review comments. Delete this comment as it's too minor and doesn't meet the bar for useful PR feedback.

6. Dockerfile:15

• Draft comment:
  Consider using a .dockerignore to prevent copying unnecessary files via 'COPY . .' in the builder stage to improve cache effectiveness.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

7. .github/workflows/ci.yml:73

• Draft comment:
  The file is missing a trailing newline at the end. Please add a newline at the end of the file to adhere to standard file formatting conventions.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While missing newlines at end of files can cause issues in some contexts, this is a very minor formatting issue that would likely be caught by standard formatters or linters. The PR makes substantial changes to the CI workflow, adding Docker build capabilities. The newline issue is trivial in comparison and doesn't affect functionality. The comment is technically correct - the file is missing a newline. And some tools do complain about missing newlines. However, this is exactly the kind of minor, obvious issue that should be caught by automated tools rather than manual review comments. The PR already includes a formatting check step that would catch this if it matters. This comment should be deleted as it's too minor and would be better handled by automated formatting tools. The PR includes 'cargo fmt --check' which would catch formatting issues if they matter.

Workflow ID: wflow_u6KSnYIJYkMABFVm

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed 79c92c6 in 49 seconds. Click for details.

• Reviewed 18 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/ci.yml:24

• Draft comment:
  Removed redundant 'build' job. Confirm that the checkout step isn’t lost, as it's already in the 'build-and-test' job.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

Workflow ID: wflow_tbdPNK7EXhNwSWSo

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed 9c2d664 in 1 minute and 26 seconds. Click for details.

• Reviewed 27 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/ci.yml:67

• Draft comment:
  The Docker build step sets 'push: false'. Confirm that building without pushing is intended for this workflow.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_yFm0hlcc2AQNPnDh

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Job naming is a bit confusing—this new 'build-and-test' job only performs Docker-related actions. Consider renaming it (e.g., to 'docker-build') so its purpose is clear since tests already run in the 'build' job.

Suggested change

	build-and-test:
	docker-build:

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed 8a25545 in 1 minute and 46 seconds. Click for details.

• Reviewed 56 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. .github/workflows/ci.yml:44

• Draft comment:
  The QEMU setup step was removed. Ensure this is intentional for cross-architecture builds.
• Reason this comment was not posted:
  Comment looked like it was already resolved.

2. .github/workflows/ci.yml:47

• Draft comment:
  Login steps may be unnecessary if 'push' is false. Remove them to optimize the workflow if not used.
• Reason this comment was not posted:
  Confidence changes required: 50% <= threshold 50% None

3. .github/workflows/ci.yml:82

• Draft comment:
  Add a newline at the end of the file for consistency.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

4. .github/workflows/ci.yml:28

• Draft comment:
  The job name 'Docker Build and' appears to be incomplete. Consider updating it to something more descriptive (e.g., 'Docker Build and Test') to clearly convey its purpose.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 20% vs. threshold = 50% While the name is technically incomplete, this is a very minor issue. It doesn't affect functionality, and the job ID already clearly indicates the purpose. This feels like an overly pedantic comment that doesn't add significant value. According to the rules, we should not make comments that are obvious or unimportant. The incomplete name could potentially cause confusion for other developers reading the workflow file. It does look unprofessional. While true, this is still a very minor cosmetic issue. The job's purpose is clear from context and the job ID. This doesn't meet the bar of "clearly a code change required." Delete this comment as it's too minor and doesn't meet the criteria of requiring a clear code change.

Workflow ID: wflow_ifBhTZqAt17EmoLR

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Job name 'Docker Build and' appears truncated. Consider using a complete, descriptive name.

Suggested change

	name: Docker Build and
	name: Docker Build and Test

[ellipsis-dev]

Caution

Changes requested ❌

Reviewed e767cb4 in 1 minute and 13 seconds. Click for details.

• Reviewed 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. src/pipelines/pipeline.rs:105

• Draft comment:
  Typographical error: The error message string in tracer.log_error on line 105 ends with an unnecessary trailing whitespace ('No matching model found '). Please remove the extra space to maintain consistency with other similar log messages.
• Reason this comment was not posted:
  Marked as duplicate.

Workflow ID: wflow_68veeNwGEAIsUK9O

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[ellipsis-dev]

Extra trailing space in log message; remove it to match other endpoints.

Suggested change

	tracer.log_error("No matching model found ".to_string());
	tracer.log_error("No matching model found".to_string());