Julia: `format(".")` + `git diff` + `exit(1)` is a formatting gate; biome via biome_jll in a julia -e one-liner

Aberta Para iniciantes
  • Algo errado?
#267 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 1 dia

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
2/5
Tempo estimado
1-3 horas
Facilidade para iniciantes
62/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
julia, python
Domínio
ci-cd, tooling

Direção de pesquisa

O falso negativo vem da regex _FAILS em project_validator/ecosystems/julia.py (por volta da linha 169), que só aceita || exit(1) ou @assert format. Comece pelo workflow do JuMP.jl em corpus/ .github/workflows/format_check.yml, linhas 18-31, e verifique como o perfil julia lê a verificação de formatação de código nele. Está concluído quando esse workflow é classificado como PASS para code-formatting, as expectativas existentes do corpus julia continuam válidas e a suíte de testes passa. O item do Biome do Documenter.jl tem baixa confiança e pode ficar de fora desta correção.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

JuMP.jl's format-check job runs format(".") and exits 1 when git diff is non-empty — exactly the "fails on a changed file" criterion the Julia profile documents — but the recogniser accepts only the literal || exit(1) or @assert format: FAIL "CI runs JuliaFormatter but only to rewrite files". Documenter.jl's make check-js runs biome check through the biome_jll wrapper inside a julia -e one-liner → code-formatting/static-analysis WARN.

Evidence from the corpus audit

jump-dev/JuMP.jl / code-formatting
  • kind: FALSE_NEGATIVE
  • actual: FAIL: CI runs JuliaFormatter but only to rewrite files; nothing fails when they are not formatted
  • expected: PASS: the format-check job runs format(".") and then exits 1 when git diff is non-empty, which is exactly the "fails on a file it changed" criterion the Julia profile documents; the recogniser only accepts the literal || exit(1) or @assert format.
  • evidence: .github/workflows/format_check.yml:18-31: shell: julia --color=yes {0} / run: | / ... / format("."; verbose = true) / out = String(read(Cmd(\git diff`)))/ if isempty(out)/ exit(0)/ end/ @error "Some files have not been formatted !!!"/ write(stdout, out)/ exit(1); project_validator/ecosystems/julia.py:169: _FAILS = re.compile(r"||\sexit\s(\s1\s)|@assert\s+format")`
  • repro: the 12-line julia step above in a workflow with shell: julia --color=yes {0}
  • confidence: high
JuliaDocs/Documenter.jl / code-formatting, static-analysis (Biome via biome_jll)
  • kind: UNSUPPORTED
  • actual: code-formatting WARN .prettierrc, biome.jsonc is defined but CI does not run prettier, deno fmt, oxfmt, dprint or biome; static-analysis WARN biome is configured (biome.jsonc) but does not run
  • expected: CI's "Biome (JS code formatting)" job runs make check-js, whose recipe runs biome check through the Julia biome_jll wrapper and exits with biome's status. The Makefile target is followed (no unread reason) but the biome invocation inside a julia one-liner is not recognised.
  • evidence: .github/workflows/CI.yml:315-324: biome: / name: Biome (JS code formatting) ... - run: make install-biome / - run: make check-js; Makefile:37-38: check-js: / julia --project=$(BIOME) -e 'using biome_jll; exit(run(ignorestatus(\$$(biome_jll.biome()) check`)).exitcode)'`
  • repro: Makefile target with the recipe above + run: make check-js
  • confidence: low (exotic; listed for completeness)

Found by the regression-corpus audit (235 real repositories, one or more per ecosystem profile; corpus and expected results in corpus/). Evidence is quoted from the audited checkouts at the commits pinned in corpus/projects.toml; <checkouts>/<owner>__<repo> is such a checkout.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Linguagem predominante
Python
Estrelas
4
Forks
1
Merge médio
10h 41min
PRs com merge (30d)
79

Preparar o ambiente

Este projeto não oferece contêiner de desenvolvimento, Dockerfile nem guia de contribuição, então a configuração fica por sua conta: comece pelo README e veja nosso guia da primeira contribuição para os passos gerais.

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de cpp-best-practices/project_validator

Todas as issues de cpp-best-practices/project_validator

Issues semelhantes

Mais issues de Python

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.