Haskell: shelltestrunner, treefmt --ci (fourmolu/hlint/actionlint), nix-built wrapper commands (postgrest-*)

Ouverte
#266 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
25/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
github-actions, haskell, python
Domaine
ci-cd, tooling

Piste de recherche

Start with project_validator/ecosystems/nix.py around line 83, the only place the payload shows treefmt, then grep project_validator/ for pytest, sphinx-build and shelltest to find where recognised test and lint commands are listed. The nix wrapper case needs a design decision about how to treat opaque nix-provided commands, so agree on that before coding. Done means the corpus results for PostgREST and hledger change as expected.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

hledger's 585 functional tests are shelltest files (*.test, unrecognised) run by every workflow; PostgREST runs fourmolu, hlint and actionlint through treefmt --ci (treefmt-nix config), and its spec/hasql/io tests, pytest, sphinx-build -b linkcheck and weeder through nix-built postgrest-* wrappers from a composite action's tools: input → code-formatting, static-analysis, ci-lint, tests-run and link-check all wrong. treefmt is a common multiplexer in Nix-managed repos (treefmt.toml / treefmt-nix).

Evidence from the corpus audit

PostgREST/postgrest / code-formatting, static-analysis, ci-lint (treefmt)
  • kind: UNSUPPORTED
  • actual: code-formatting FAIL Haskell: fourmolu.yaml is defined but CI does not run ormolu, fourmolu or stylish-haskell; static-analysis FAIL Haskell: no static analyzer runs; ci-lint WARN CI does not lint its GitHub Actions configuration
  • expected: all three are run by treefmt --ci (fails on unformatted files) with the treefmt-nix configuration enabling fourmolu, hlint and actionlint. treefmt (treefmt.toml / treefmt-nix) is a common multiplexer in Nix-managed repos; the validator knows the word only as a Nix formatter.
  • evidence: .github/workflows/check.yaml:33-34: - name: Run treefmt / run: treefmt --ci; nix/treefmt.nix:26: programs.actionlint.enable = true;; :29-30: programs.fourmolu.enable = true; / programs.hlint.enable = true;; .github/actionlint.yml (actionlint config present); project_validator/ecosystems/nix.py:83: must take it: nixfmt, alejandra and treefmt do). (only mention)
  • repro: treefmt.toml with [formatter.fourmolu] command = "fourmolu" options = ["--mode","check"] and a step run: treefmt --ci
  • confidence: high
PostgREST/postgrest / tests-run, link-check, static-analysis (nix wrapper commands)
  • kind: UNSUPPORTED
  • actual: tests-run FAIL Haskell: tests found in 1 file(s), but no CI configuration runs cabal test (or stack test); Documentation site: ... no CI runs sphinx-build; Python: tests found in 14 file(s), but no CI configuration runs pytest; link-check WARN no link check found in CI configuration; static-analysis Haskell: no static analyzer runs
  • expected: these all run, through nix-built postgrest-* wrapper scripts provided by the ./.github/actions/setup-nix composite action's tools: input: spec/hasql/io tests, pytest, sphinx-build -b linkcheck (scheduled workflow named Linkcheck), weeder. The commands are opaque to the validator (their bodies are in nix/tools/*.nix), so this is a gap rather than a parser bug; a "nix-provided command" notion (or reading checkedShellScript bodies in nix/tools) would be needed.
  • evidence: .github/workflows/test.yaml:103-116: run: postgrest-with-${{ matrix.pgVersion }} postgrest-test-spec ... run: postgrest-with-${{ matrix.pgVersion }} postgrest-test-io -vv; nix/tools/tests.nix:116: ${ioTestPython}/bin/pytest --ignore=test/io/test_big_schema.py --ignore=test/io/test_replica.py -v test/io; .github/workflows/linkcheck.yaml:3-5,25: schedule: / - cron: '1 2 * * 3' ... run: postgrest-docs-linkcheck; nix/tools/docs.nix:175: ${python}/bin/sphinx-build --color -b linkcheck . ../.docs-build; nix/tools/tests.nix:168: docs = "Run spec and io tests while collecting hpc coverage data. First runs weeder to detect dead code.";
  • repro: unclear (needs reading nix shell-script derivations)
  • confidence: medium
simonmichael/hledger / tests-run (shelltestrunner)
  • kind: UNSUPPORTED
  • actual: Haskell tests-run PASS via stack install --test, but the 585 functional tests are invisible: .map.json unrecognised_suffixes: {"suffix": ".test", "files": 585}
  • expected: shelltestrunner (shelltest) is the standard functional-test runner for Haskell CLIs (hledger, pandoc-adjacent tools); recognising shelltest <dir> and *.test files would make the Haskell test picture complete.
  • evidence: .github/workflows/ci.yml:351: COLUMNS=80 $stack exec -- shelltest --execdir -j16 hledger/test -x /_ -x ledger-compat/ledger-baseline -x ledger-compat/ledger-regress -x ledger-compat/ledger-collected; hledger/test/cli/addons.test; grep -rn -i shelltest project_validator/ → no match
  • repro: n/a (gap)
  • confidence: medium

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

Langage dominant
Python
Étoiles
4
Forks
1
Merge moyen
10 h 41 min
PR mergées (30 j)
79

Préparer son environnement

Ce projet ne fournit ni conteneur de développement, ni Dockerfile, ni guide de contribution : l'installation est à votre charge. Commencez par son README, et consultez notre guide de la première contribution pour les étapes générales.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de cpp-best-practices/project_validator

Toutes les issues de cpp-best-practices/project_validator

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.