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

Aberta
  • Algo errado?
#264 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
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
25/100
Tipo de issue
Bug
Clareza
Razoavelmente clara
Status de atividade
Ativa
Stack de tecnologia
github-actions, python
Domínio
build-system, ci-cd

Direção de pesquisa

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.

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

Descrição

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

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.