Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Proposal: Add an LLGo test workflow only when a binding project has tests

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

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
github-actions, go
Ambito
ci-cd, tooling

Direzione di ricerca

Start with the project template that #974 introduced and the generation path that llcppg -init runs, then read the existing llcppg CI workflow at .github/workflows/llgo.yml as the reference setup. The open question, whether this belongs in ordinary generation or in an explicit template-sync command, needs a maintainer decision before any code. Done means a project with no *_test.go gets no workflow, one with tests gets it, and regeneration never overwrites a customized file.

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

Descrizione

feature proposal

Summary

Add an llgo.yml workflow to the llcppg project template. When llcppg applies the template to a binding project, it should create .github/workflows/llgo.yml only if the target Go module contains at least one *_test.go file. The workflow runs llgo test ./... on pushes and pull requests. Projects without tests should not receive the workflow file.

Motivation

The template introduced in #974 gives new binding repositories a consistent starting point. Once a project adds tests, those tests should run automatically in CI using LLGo, as llcppg itself does. Adding a test workflow to every new repository would create a CI job that has nothing to test. Making the workflow conditional keeps the initial repository small while enabling CI when tests exist.

Proposed behavior

  • Keep llgo.yml as a source file in the template. Materialize it at .github/workflows/llgo.yml in the target repository only when a *_test.go file exists under the target Go module.
  • Check after generation has written its files, so the decision reflects the project’s current contents. A fresh llcppg -init repository has no tests and therefore receives no workflow.
  • If tests are added later, the next template synchronization or generation run adds the workflow. The command should report when it does so.
  • If no tests exist, leave .github/workflows/llgo.yml absent. Do not delete an existing workflow: it may contain project-specific changes.
  • Do not overwrite an existing llgo.yml when applying the template.

The generated workflow should set up the required Go, LLVM, and LLGo toolchain, then run llgo test ./... from the module root. Its setup can follow the existing [llcppg CI workflow](https://github.com/goplus/llcppg/blob/main/.github/workflows/llgo.yml), adapted so it works in a generated binding repository.

Testing plan

Verify that a project with no *_test.go receives no workflow; a project with a test in the module root or a subpackage receives llgo.yml; and running generation again does not overwrite a customized workflow. Finally, run the generated workflow against a small binding project with a passing test.

Open question

Should adding the workflow be part of ordinary generation, or should template synchronization have an explicit command? Checking only during llcppg -init would miss the common case where tests are written after initialization.

Lingua principale
Go
Stelle
39
Fork
13
Merge medio
1h 28m
PR unite (30g)
256

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 goplus/llcppg

Tutte le issue di goplus/llcppg

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.