BEAM: Gleam is unknown (gleam.toml, .gleam, gleam test/format), erlang.mk is not a build system (rebar.config is its generated artifact), Earthly targets

Aperta
  • Qualcosa non va?
#264 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, python
Ambito
build-system, ci-cd

Direzione di ricerca

The issue spans three separate detection gaps: Gleam files and gleam.toml, erlang.mk versus the generated rebar.config, and Earthly targets in CI. Start with the corpus expected results under corpus/ (projects.toml, and the gleam-lang/stdlib, ninenines/cowboy and elixir-ecto/ecto entries) and the detection code they exercise. Done means those three projects produce the expected build systems, test and format results, and no silent gaps, with the corpus results updated to match.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

gleam-lang/stdlib: 42 .gleam files unrecognised, judged as Erlang + JavaScript from its FFI shims; gleam test and gleam format --check in every job → tests-run and code-formatting FAIL. cowboy: build_systems: ["rebar3"] from a rebar.config erlang.mk generates for Hex; deps are pinned in the Makefile, outputs are ebin/, deps/, .erlang.mk/ (all ignored), compiled with -Werror by erlang.mk → three wrong WARNs. ecto's integration tests run through earthly +integration-test (a committed Earthfile running mix test), neither read nor unknown.

Evidence from the corpus audit

gleam-lang/stdlib / detection (and tests-run, code-formatting, static-analysis, platform-matrix)
  • kind: UNSUPPORTED (DETECTION)
  • actual: map: languages Erlang, JavaScript, build_systems [], unrecognised .gleam x42; tests-run FAIL "BEAM: no
    tests found ...; JavaScript/TypeScript: no tests found"; code-formatting FAIL "CI never runs erlfmt ... prettier"
  • expected: a Gleam (BEAM) project with build system gleam (gleam.toml), tests-run PASS (gleam test in every
    job), code-formatting PASS (gleam format --check), and no JavaScript/TypeScript judgement for the 5 FFI .mjs
    files
  • evidence: gleam.toml:1: name = "gleam_stdlib"; .github/workflows/ci.yml:32: - run: gleam test --target erlang;
    .github/workflows/ci.yml:33: - run: gleam format --check src test; ci.yml:51: gleam test --target javascript --runtime node; test/gleam_stdlib_test.gleam exists; grep -rli gleam project_validator docs README.md returns
    nothing. The 42 .gleam files are the whole product; the detected "Erlang" (5 .erl) and "JavaScript" (5 .mjs)
    are FFI shims.
  • repro: gleam.toml + src/a.gleam + test/a_test.gleam + workflow run: gleam test and run: gleam format --check src test
  • confidence: high
ninenines/cowboy / detection (build system), dependency-management, vcs-ignore, warnings-as-errors
  • kind: DETECTION (UNSUPPORTED: erlang.mk)
  • actual: map build_systems: ["rebar3"]; dependency-management WARN "declared in rebar.config (rebar3) but not
    locked"; vcs-ignore WARN ".gitignore does not ignore the _build directory"; warnings-as-errors FAIL "warnings are
    not treated as errors in CI configuration or rebar.config"
  • expected: build system erlang.mk (the rebar.config is an artifact erlang.mk generates for Hex); deps are pinned
    by tag in the Makefile; _build/ is rebar3's tree, erlang.mk's outputs (ebin/, deps/, .erlang.mk/) are all
    ignored; erlang.mk compiles with -Werror by default.
  • evidence: Makefile:60: include erlang.mk; Makefile:89-91: # Generate rebar.config on build. / app:: rebar.config;
    Makefile:18-20: DEPS = cowlib ranch / dep_cowlib = git https://github.com/ninenines/cowlib 2.22.0;
    .gitignore: .erlang.mk, deps, ebin/*.beam; erlang.mk:1626: ERLC_OPTS ?= -Werror +debug_info +warn_export_vars +warn_shadow_vars \; grep -rli erlang.mk project_validator docs returns nothing. erlang.mk is
    the build tool of cowboy, ranch, gun, cowlib and most ninenines/RabbitMQ-adjacent Erlang.
  • repro: Makefile with PROJECT = x + include erlang.mk, a committed erlang.mk, a generated rebar.config
  • confidence: medium (the judgements are defensible for a rebar3 user; the detection is what is wrong)
elixir-ecto/ecto / tests-run (integration tests under Earthly)
  • kind: UNSUPPORTED
  • actual: tests-run PASS (from the unit-test job); the integration-test job's earthly ... +integration-test is
    neither read nor reported as unknown (ecto.txt has no ERROR at all)
  • expected: either read the committed Earthfile target (it runs mix test and mix test.all), or an ERROR "the
    command earthly ... is not read" in strict mode; today the job silently contributes nothing.
  • evidence: .github/workflows/ci.yml:80: run: earthly -P --ci --build-arg ELIXIR_BASE=${{matrix.elixirbase}} +integration-test; Earthfile:32-39: integration-test: ... RUN mix test; Earthfile:79: mix test.all;;
    grep -rli earthly project_validator docs returns nothing.
  • repro: workflow run: earthly +test with an Earthfile target test: / RUN mix test
  • confidence: medium (Earthly is niche outside the Elixir core projects; the silent part is the real point)

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

Lingua principale
Python
Stelle
4
Fork
1
Merge medio
10h 41m
PR unite (30g)
79

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cpp-best-practices/project_validator

Tutte le issue di cpp-best-practices/project_validator

Issue simili

Altre issue su Python

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.