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

Offen
  • Stimmt etwas nicht?
#264 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
4/5
Geschätzter Aufwand
3-5 Tage
Anfängerfreundlichkeit
25/100
Issue-Typ
Bug
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, python
Bereich
build-system, ci-cd

Rechercherichtung

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.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

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

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.