Site d'accueil du cloud-rennais
  • JavaScript 43.5%
  • HTML 41.8%
  • CSS 13.6%
  • Shell 1%
  • Dockerfile 0.1%
Find a file
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Malo TERNAND a931855c00
All checks were successful
Build and publish image / docker (push) Successful in 29s
Merge pull request 'ci: trust FreeIPA CA for registry.crs.bzh' (#2) from fix/registry-ipa-ca into main
Reviewed-on: #2
2026-10-24 14:59:35 +02:00
.forgejo ci: trust FreeIPA CA for registry.crs.bzh 2026-10-24 14:57:57 +02:00
scripts Add site scaffold, CI, and Forgejo API tooling 2026-09-23 13:44:45 +02:00
src Add qsite page under /qsite 2026-10-24 14:47:54 +02:00
.dockerignore Add site scaffold, CI, and Forgejo API tooling 2026-09-23 13:44:45 +02:00
.env.example Add site scaffold, CI, and Forgejo API tooling 2026-09-23 13:44:45 +02:00
.gitignore Add site scaffold, CI, and Forgejo API tooling 2026-09-23 13:44:45 +02:00
Dockerfile Add site scaffold, CI, and Forgejo API tooling 2026-09-23 13:44:45 +02:00
nginx.conf Add site scaffold, CI, and Forgejo API tooling 2026-09-23 13:44:45 +02:00
README.md Trust the internal CA via buildkitd config, not the docker driver 2026-09-23 13:53:59 +02:00

Home

Site d'accueil du cloud-rennais (cloud-rennais.fr).

Structure

  • src/ — le site statique (HTML/CSS/JS), servi tel quel par nginx.
  • Dockerfile / nginx.conf — image de prod servant src/ sur le port 8080.
  • .forgejo/workflows/docker-publish.yml — CI Forgejo Actions : build l'image et la publie sur registry.crs.bzh à chaque push sur main.
  • scripts/forgejo.sh — appelle l'API REST Forgejo (lu dans .env) pour inspecter/gérer des choses côté Forgejo (CI, PR, infos repo...).

Développement local

Ouvrir directement src/index.html dans un navigateur, ou servir le dossier avec n'importe quel serveur statique.

Pour tester l'image telle qu'elle sera déployée :

docker build -t home:local .
docker run --rm -p 8080:8080 home:local

API Forgejo (token)

Le git push/pull reste en SSH, inchangé. Le token dans .env sert uniquement à interroger/piloter l'API REST Forgejo : voir pourquoi une CI a échoué, lister/ouvrir une PR, modifier des réglages du dépôt, récupérer des infos, etc.

  1. cp .env.example .env puis renseigner FORGEJO_URL, FORGEJO_REPO et FORGEJO_TOKEN (token Forgejo avec le scope repo, et read:organization si besoin). .env est ignoré par git.

  2. Utiliser ./scripts/forgejo.sh <METHODE> <chemin> [args curl...], par exemple :

    ./scripts/forgejo.sh GET pulls
    ./scripts/forgejo.sh GET actions/tasks
    ./scripts/forgejo.sh POST pulls -d '{"title":"mon changement","head":"ma-branche","base":"main"}'
    

    <chemin> est relatif à /api/v1/repos/<FORGEJO_REPO>/.

CI / Registry

La CI (.forgejo/workflows/docker-publish.yml) build et pousse registry.crs.bzh/cloud-rennais/home:latest et :<sha> à chaque push sur main, ou manuellement via workflow_dispatch. registry.crs.bzh est un registry local sans authentification (réseau interne), donc pas de login ni de secret à configurer.

Le registry sert du TLS avec un certificat auto-signé en interne (.forgejo/ca/registry.crs.bzh.crt, wildcard *.crs.bzh). Le job CI n'a pas le CLI docker (juste le binaire buildx autonome), donc il ne peut pas utiliser le driver docker classique ni le trust store de l'hôte (/etc/docker/certs.d) : le build passe par un conteneur buildkit isolé. Le workflow génère un buildkitd.toml qui référence ce certificat ([registry."registry.crs.bzh"] ca = [...]) et le passe à docker/setup-buildx-action via config: — buildx copie alors le certificat dans le conteneur builder et adapte la config en conséquence. Rien à faire côté hôte.