Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#994 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
github-actions, go
Área
ci-cd, tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
39
Forks
13
Merge medio
1 h 28 min
PR fusionados (30 d)
256

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de goplus/llcppg

Todos los issues de goplus/llcppg

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.