feat(ignore matcher): support for .dockerignore for build context#673
feat(ignore matcher): support for .dockerignore for build context#673
Conversation
|
CodeAnt AI is reviewing your PR. Thanks for using CodeAnt! 🎉We're free for open-source projects. if you're enjoying it, help us grow by sharing. Share on X · |
codeant-ai
bot
added
the
size:L
Nitpicks 🔍
|
✅ Object Smoke Tests & Coverage ReportTest Results✅ All smoke tests passed Coverage Results
Coverage Requirement: 100% function coverage (all public methods must be called in smoke tests) ✅ All tests passed and all object methods are covered! View detailed coverage reportCoverage reports are available in the workflow artifacts. Lines/branches/statements coverage is tracked but not required to be 100%. |
![codeant-ai[bot]](https://avatars.githubusercontent.com/in/646884?s=60&v=4){kind=small}
| private patterns: CompiledPattern[]; | ||
|
|
||
| constructor(patterns: string[]) { | ||
| this.patterns = patterns.map((raw) => new CompiledPattern(raw)); |
There was a problem hiding this comment.
Suggestion: The DockerIgnoreMatcher constructor stores patterns exactly as passed in, without applying the same normalization as createIgnoreMatcher, so when it's used directly (as in your tests) patterns with leading slashes or trailing slashes (e.g. /foo, /foo/bar/) will never match normalized file paths like foo/bar, breaking the documented Docker-style semantics. [logic error]
Severity Level: Minor
| this.patterns = patterns.map((raw) => new CompiledPattern(raw)); | |
| const cleanedPatterns = normalizePatterns(patterns); | |
| this.patterns = cleanedPatterns.map((raw) => new CompiledPattern(raw)); |
Why it matters? ⭐
This is a real logic bug. createIgnoreMatcher already calls normalizePatterns before constructing DockerIgnoreMatcher, but the class is public and can be constructed directly (e.g. in tests or other call sites). If callers pass patterns like '/foo' or './bar/', those will not match normalized file paths ('foo' / 'bar') because the class never normalizes inputs. Normalizing in the constructor keeps behavior consistent and matches the documented Docker semantics.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/lib/ignore-matcher.ts
**Line:** 124:124
**Comment:**
*Logic Error: The `DockerIgnoreMatcher` constructor stores patterns exactly as passed in, without applying the same normalization as `createIgnoreMatcher`, so when it's used directly (as in your tests) patterns with leading slashes or trailing slashes (e.g. `/foo`, `/foo/bar/`) will never match normalized file paths like `foo/bar`, breaking the documented Docker-style semantics.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.|
|
||
| if (normalized.startsWith('./')) normalized = normalized.slice(2); | ||
| if (!normalized) normalized = '.'; | ||
|
|
There was a problem hiding this comment.
Suggestion: The matcher currently treats .dockerignore like any other file, so unless explicitly excluded by a pattern it will be included in the uploaded context, which diverges from Docker CLI behavior where the .dockerignore file itself is always excluded from the build context. [logic error]
Severity Level: Minor
| // Always ignore the .dockerignore file itself, matching Docker CLI behavior. | |
| if (normalized === '.dockerignore') { | |
| return true; | |
| } |
Why it matters? ⭐
Docker's CLI always excludes the .dockerignore file from the build context. The current implementation applies only the provided patterns and therefore will include '.dockerignore' unless a user pattern excludes it. Adding a small explicit check to always ignore '.dockerignore' reproduces Docker behavior and prevents accidental inclusion of the ignore file in contexts or archives produced by the tooling.
Prompt for AI Agent 🤖
This is a comment left during a code review.
**Path:** src/lib/ignore-matcher.ts
**Line:** 133:133
**Comment:**
*Logic Error: The matcher currently treats `.dockerignore` like any other file, so unless explicitly excluded by a pattern it will be included in the uploaded context, which diverges from Docker CLI behavior where the `.dockerignore` file itself is always excluded from the build context.
Validate the correctness of the flagged issue. If correct, How can I resolve this? If you propose a fix, implement it and please make it concise.
|
CodeAnt AI finished reviewing your PR. |
✅ Object Smoke Tests & Coverage ReportTest Results✅ All smoke tests passed Coverage Results
Coverage Requirement: 100% function coverage (all public methods must be called in smoke tests) ✅ All tests passed and all object methods are covered! View detailed coverage reportCoverage reports are available in the workflow artifacts. Lines/branches/statements coverage is tracked but not required to be 100%. |
…with what docker does internally
✅ Object Smoke Tests & Coverage ReportTest Results✅ All smoke tests passed Coverage Results
Coverage Requirement: 100% function coverage (all public methods must be called in smoke tests) ✅ All tests passed and all object methods are covered! View detailed coverage reportCoverage reports are available in the workflow artifacts. Lines/branches/statements coverage is tracked but not required to be 100%. |
✅ Object Smoke Tests & Coverage ReportTest Results✅ All smoke tests passed Coverage Results
Coverage Requirement: 100% function coverage (all public methods must be called in smoke tests) ✅ All tests passed and all object methods are covered! View detailed coverage reportCoverage reports are available in the workflow artifacts. Lines/branches/statements coverage is tracked but not required to be 100%. |
|
| Metric | Coverage | Required | Status |
|---|---|---|---|
| Functions | 28.03% | 100% | ❌ |
| Lines | 29.29% | - | ℹ️ |
| Branches | 20.58% | - | ℹ️ |
| Statements | 28.84% | - | ℹ️ |
Coverage Requirement: 100% function coverage (all public methods must be called in smoke tests)
View detailed coverage report
Coverage reports are available in the workflow artifacts. Lines/branches/statements coverage is tracked but not required to be 100%.
2 participants
Description
.dockerignorefiles and provides scaffolding for other.ignorefile types.Motivation
Changes
mobygolang project ignore logic.Testing
Breaking Changes
Checklist
feat:orfeat(scope):)CodeAnt-AI Description
Add local directory build contexts with .dockerignore support
What Changed
Impact
✅ Can attach local directory as build context✅ Respects .dockerignore excludes during uploads✅ Fewer accidental files included in blueprint builds💡 Usage Guide
Checking Your Pull Request
Every time you make a pull request, our system automatically looks through it. We check for security issues, mistakes in how you're setting up your infrastructure, and common code problems. We do this to make sure your changes are solid and won't cause any trouble later.
Talking to CodeAnt AI
Got a question or need a hand with something in your pull request? You can easily get in touch with CodeAnt AI right here. Just type the following in a comment on your pull request, and replace "Your question here" with whatever you want to ask:
This lets you have a chat with CodeAnt AI about your pull request, making it easier to understand and improve your code.
Example
Preserve Org Learnings with CodeAnt
You can record team preferences so CodeAnt AI applies them in future reviews. Reply directly to the specific CodeAnt AI suggestion (in the same thread) and replace "Your feedback here" with your input:
This helps CodeAnt AI learn and adapt to your team's coding style and standards.
Example
Retrigger review
Ask CodeAnt AI to review the PR again, by typing:
Check Your Repository Health
To analyze the health of your code repository, visit our dashboard at https://app.codeant.ai. This tool helps you identify potential issues and areas for improvement in your codebase, ensuring your repository maintains high standards of code health.