Repository navigation
fix(cli): preserve Unicode in deployment ignore patterns - #2136
Merged
Merged
Conversation
🟢 Tier S · Ready to merge
The CLI ignore-pattern translator now decodes complete UTF-8 characters before quoting literal and escaped pattern characters. The CLI end-to-end conformance harness checks the uploaded deployment archive against Unicode
📂 Walkthrough · 3
Reviewed |
2 tasks done
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #2129.
Literal Unicode characters in deployment ignore patterns were converted one UTF-8 byte at a time into separate characters (
ébecameé). Files explicitly excluded by.gitignoreor the resource'signorearray could therefore be uploaded. Unicode negations could also fail to restore source files excluded by a preceding rule.Preserve each complete UTF-8 character when translating literal and escaped pattern characters, while retaining the existing glob and bracket-class handling. Add a CLI regression that inspects the actual multipart deployment tar received by a local HTTP server for both
.gitignoreand config rules. It covers accented and Japanese paths, wildcard extensions, escaped Unicode, negation, and ASCII/bracket-class controls.Staging verification
Verified on 2026-10-23 using an existing staging login against
https://fra.cloud.staging.appwrite.io/v1, in a disposable project. Compared the unmodified generated CLI fromce0b4844cwith the fixed generated CLI, both built with Go 1.26.5.For each binary, uploaded once through
functions create-deployment --code ./fn --activate=falseusing.gitignore, and once throughpush function --activate=false --async --force --no-logsusing the config'signorearray. Downloaded each deployment's source archive withfunctions get-deployment-download --type sourceand inspected its entries.Patterns included
données/,secret-é.env,*.café,日本/**/*.key,\é.env,secret-e.env,[é].txt,*.log,!résumé.log, andsrc/*.tmp.données/prod.env,secret-é.env,x.café,日本/a/b.key,é.envrésumé.logsecret-e.env,é.txt,src/temp-é.tmpindex.js,src/visible-é.jsBoth deployment paths produced these results. After the fix, the archives contain only
index.js,résumé.log, andsrc/visible-é.js, plus.gitignorefor the direct deployment case. This also confirms the issue's blanket “non-ASCII patterns never match” wording has exceptions: bracket classes such as[é]already work.Only dummy file contents were uploaded; the function was disabled and all four deployments used
activate=false. Deleted the disposable project afterward and verified it could no longer be fetched.Validation
php example.php cli; generated output passesgofmt -lwithout formatting after generation.go build,go vet ./..., andgo test ./...pass.vendor/bin/phpunit tests/e2e/CLIGo126Test.phppasses (1 test, 26 assertions).composer refactor:check,composer lint-twig, PHP CodeSniffer, and scoped PHPStan ontests/e2e/CLIGo126Test.phppass.Related: appwrite-labs/cloud#6667