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

CI/CD: optional GITHUB_TOKEN for composer, functional tests never send email, registry secret apply (template !12)

Cerrado
  • ¿Algo no está bien?
#180 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
58/100
Tipo de issue
Documentación
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
docker, github-actions, helm, kubernetes, php
Área
ci-cd, devops, documentation

Línea de trabajo

Update content/6.deployment/3.ci-cd.md, especially the variables table at line 73, the bin/devops/setup.sh section around line 147, and run_test_functional around line 167; compare with content/6.deployment/1.docker.md at line 224. Document the token, email-safe test setup, registry secret, Helm defaults, removed VARNISH_TOKEN, and stale GitHub deploy statement using the issue details. Done when the CI/CD guide consistently describes these behaviors and no longer lists the unused variable.

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

Descripción

Template MR !12 (components-web-app#123, merged as 1a530d4) changed CI in ways content/6.deployment/3.ci-cd.md should cover.

1. Optional GITHUB_TOKEN for composer (new row in the variables table, plus a note in the bin/devops/setup.sh section, line 147)

  • Without it, composer's ~180 downloads from github.com are anonymous: 60 requests an hour per IP. On a shared runner, installs fail part way through with a 429.
  • A fine-grained token with no permissions is enough. setup.sh turns it into COMPOSER_AUTH and sets COMPOSER_MAX_PARALLEL_HTTP=6. Unset stays unset (an empty token is rejected outright, which is worse than anonymous).
  • build_api passes it to the API image build as the composer_auth build secret, never a build arg, so it stays out of the image history. The build log's github rate limit for this build: line prints 60 (anonymous) or 5000 (token applied).
  • GitHub Actions maps its own secrets.GITHUB_TOKEN on the build step, so nothing needs setting there.
  • Keep this consistent with content/6.deployment/1.docker.md:224, which already mentions GITHUB_TOKEN for local composer update.

2. Functional tests never send real email (the functional tests row at line 73, and run_test_functional at line 167)

  • Every CI variable reaches the test job, and a real environment variable beats api/.env.test, so a project's live MAILER_DSN would deliver any email a test sends (a contact form, a password reset).
  • run_test_functional unsets MAILER_DSN and MAILER_EMAIL, and api/.env.test sets MAILER_DSN=null://null: mail is built and Symfony's mailer assertions still see it, but nothing is delivered. Both halves are needed: without the .env.test line, tests fall back to .env's smtp-relay host, which CI doesn't have, and error.
  • The job also generates a test JWT keypair (lexik:jwt:generate-keypair --skip-if-exists), so tests that sign in work in CI.

3. Smaller changes

  • The registry pull secret is now kubectl applyd, not replace --forced (concurrent releases in one namespace raced with "already exists"). The first deploy after the change prints a harmless one-off warning about a missing last-applied-configuration annotation.
  • helm lint and helm template now pass on the chart's own defaults (jwt-passphrase defaults to "").
  • VARNISH_TOKEN (chart apiSecretToken) is gone: nothing read it. If the docs list it anywhere, remove it.

While there, unrelated: line 416 says "GitHub deploys don't pass these variables" (MAILER_DSN, MAILER_EMAIL, ORPHAN_SCAN*), but line 411 says they do. Since template #102 they do, so 416 looks stale.

Lenguaje dominante
Vue
Estrellas
0
Forks
0
Sin PR fusionados en 30 d

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 components-web-app/docs

Todos los issues de components-web-app/docs

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.