- JavaScript 43.5%
- HTML 41.8%
- CSS 13.6%
- Shell 1%
- Dockerfile 0.1%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
|
All checks were successful
Build and publish image / docker (push) Successful in 29s
Reviewed-on: #2 |
||
| .forgejo | ||
| scripts | ||
| src | ||
| .dockerignore | ||
| .env.example | ||
| .gitignore | ||
| Dockerfile | ||
| nginx.conf | ||
| README.md | ||
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 servantsrc/sur le port 8080..forgejo/workflows/docker-publish.yml— CI Forgejo Actions : build l'image et la publie surregistry.crs.bzhà chaque push surmain.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.
-
cp .env.example .envpuis renseignerFORGEJO_URL,FORGEJO_REPOetFORGEJO_TOKEN(token Forgejo avec le scoperepo, etread:organizationsi besoin)..envest ignoré par git. -
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.