Files

2026-10-21 08:49:37 +02:00

8.3 KiB

Raw Blame History

Fiche — dépôt de soutenance, branche `soutenance`, PC école

Lot 1 du plan de préparation.
Validé : branche soutenance = même contenu que Vogosphere ; travail quotidien sur main ; .env local uniquement ; .env.example dans le rendu Git.

1. Ce que dit le sujet (sécurité — éliminatoire)

Traduction du PDF v4, chapitre IV (encadré page 5) :

Les identifiants, clés API, variables d’environnement, etc. doivent être stockés localement dans un fichier .env et ignorés par git. Des identifiants exposés publiquement entraînent l’échec direct du projet.

À retenir pour le rendu :

Fichier	Dans le Git école (Vogosphere) ?
`.env` (avec vrais secrets)	NON — jamais
`.env.example` (modèle vide + explications)	OUI
`.gitignore` qui ignore `.env`	OUI

Le correcteur crée son .env sur sa machine à partir de .env.example + son app OAuth Intra (ou la tienne en démo, sans committer les valeurs).

2. Où mettre le `.env` pour que l’app tourne

Flutter charge le fichier déclaré dans pubspec.yaml :

assets:
  - .env

→ chemin obligatoire pour l’exécution :

swiftyCompanion/swifty_companion/.env

Fichier	Rôle
`swifty_companion/.env`	Secrets réels — machine locale (portable, école en démo) — gitignore
`swiftyCompanion/.env.example`	Modèle à la racine du paquet rendu — versionné
`swiftyCompanion/.env` (racine paquet)	Inutile pour Flutter — à ne pas utiliser pour éviter la confusion (tu peux le supprimer en local)

Procédure correcteur / toi :

cd swiftyCompanion/swifty_companion
cp ../.env.example .env
# Éditer .env : CLIENT_ID, CLIENT_SECRET, REDIRECT_URI
flutter pub get
flutter run -d <device>

(Le lot 2 enrichira .env.example avec commentaires détaillés par variable.)

3. Contenu exact du dépôt école (Vogosphere)

Racine du dépôt Intra = contenu du dossier swiftyCompanion/ (pas le repo perso entier).

swiftyCompanion/                 ← racine Git Vogosphere
├── README.md
├── .gitignore
├── .env.example
└── swifty_companion/            ← projet Flutter
    ├── pubspec.yaml
    ├── lib/
    ├── android/
    ├── test/
    └── …

Ne doit pas apparaître dans Vogosphere :

docs/ (sujet traduit, pédagogie, fiches orale)
tout .env avec secrets
dépôt Gitea perso, liens vers guides internes

4. Deux Git, deux rôles

Dépôt	Remote typique	Contenu
Perso	Gitea privé	`docs/` + `swiftyCompanion/` (travail)
École	Vogosphere	uniquement `swiftyCompanion/` à la racine

Sur le portable, tu continues à coder sur main (perso). Quand le rendu est prêt, tu mets à jour la branche soutenance (voir §5) — c’est la référence « propre » pour présenter et pour préparer le push école.

5. Branche `soutenance` (portable)

Objectif

Même arbre utile que Vogosphere : tout sous swiftyCompanion/ à jour et fonctionnel.
Tu peux continuer à développer sur main ; soutenance ne bouge que quand tu décides de figer une version pour correction.
En soutenance sur ton PC : tu ouvres le projet dans swiftyCompanion/swifty_companion/ (pas besoin d’afficher docs/ à l’écran).

Méthode recommandée (monorepo perso)

cd ~/projets/42School/swifty_companion

# 1) Finir les modifs sur main (swiftyCompanion + éventuellement docs)
git checkout main
git status   # rien de secret à committer

# 2) Mettre à jour soutenance (merge depuis main)
git checkout soutenance    # créer une fois : git checkout -b soutenance
git merge main           # ou cherry-pick des commits rendu uniquement

# 3) Vérifier que seul le paquet rendu est cohérent
cd swiftyCompanion/swifty_companion
flutter analyze && flutter test
# .env présent en local, absent du git :
git -C ../.. ls-files | rg '\.env'   # doit montrer seulement .env.example

Présentation : git checkout soutenance, lancer flutter run depuis swifty_companion/.

Travail après soutenance : retour sur main, nouvelles features ; avant rendu final, re-merge vers soutenance.

Alternative (si tu préfères un repo Git uniquement dans `swiftyCompanion/`)

git init dans swiftyCompanion/, remote Vogosphere.
Branche main = école, branche dev optionnelle.
Le monorepo perso ne versionne plus le code Flutter (plus lourd à maintenir). Tu as choisi le monorepo + branche soutenance — la méthode ci-dessus suffit.

6. Ton scénario PC école (push Vogosphere)

C’est le flux que tu as décrit — formalisé pour ne rien oublier.

Prérequis

Branche soutenance à jour sur Gitea ou dossier swiftyCompanion/ prêt sur clé USB / copie.
.env sur la clé ou la machine école pour la démo (fichier local, pas dans le commit).
URL du dépôt Vogosphere (Intra 42).

Étapes sur le PC école

# A — Récupérer le travail (une fois)
cd ~
git clone https://ton-gitea/.../swifty_companion.git
cd swifty_companion
git checkout soutenance

# B — Préparer le dossier de rendu (contenu école pur)
# Option simple : le rendu EST le sous-dossier swiftyCompanion
cd ~/chemin/attendu/par/l/ecole   # répertoire de rendu du sujet
rm -rf ./*   # seulement si dossier vide / dédié — attention !
cp -a ~/swifty_companion/swiftyCompanion/. .

# C — Retirer le dépôt perso de la machine école (optionnel mais ton choix)
rm -rf ~/swifty_companion

# D — Git ÉCOLE uniquement dans le répertoire de rendu
cd ~/chemin/attendu/par/l/ecole
git init
git remote add origin <url-vogosphere-swifty_companion>
git add .
git status   # VÉRIFIER : pas de .env, pas de docs/

git commit -m "Rendu Swifty Companion"
git push -u origin main

Contrôles avant `git push` (checklist)

git status ne liste aucun .env
.env.example est présent et sans vraies clés
Pas de dossier docs/ du dépôt perso
flutter test OK dans swifty_companion/
README à la racine du clone Vogosphere (pas un niveau au-dessus)

7. Portable = démo = même binaire « logique » que l’école

Action	Portable (`soutenance`)	Vogosphere
Code Flutter	`swiftyCompanion/swifty_companion/`	idem
Secrets	`.env` local	jamais poussé
Doc longue oral	`docs/pedagogie/` (perso)	absent
README correcteur	`swiftyCompanion/README.md`	idem

8. Point « DEBUG » dans l’app (éclaircissement)

Ce n’est pas un fichier .env ni un secret.

Dans search_screen.dart, un bouton « DEBUG : simuler token expiré » n’apparaît que si kDebugMode est vrai (build debug, ex. flutter run). Il n’existe pas dans un APK release (flutter build apk --release).

Question	Réponse
Le sujet l’interdit ?	Non — rien dans le PDF sur les boutons de debug.
Risque en soutenance ?	L’évaluateur peut le voir en `flutter run` ; tu peux l’expliquer pour le bonus refresh, ou le retirer avant rendu final si tu veux une UI plus « propre ».
Décision à prendre (lot 4 ou avant push)	Garder (démo bonus) ou retirer le bouton — les deux sont défendables.

→ Détails oraux : fiche-soutenance-orale.md (lot 3, à rédiger).

9. Commentaires en français dans le code

Le sujet n’impose pas la langue des commentaires. Français = OK (lot 4).

10. Prochaines étapes (autres lots)

Lot	Document / action
2	README rendu + `.env.example` commenté (sans ton « IA »)
3	`fiche-soutenance-orale.md` — déroulé minute par minute + commandes
4	Commentaires `lib/` + décision finale bouton DEBUG

11. Liens

Plan global : 00-plan-preparation-soutenance.md
Sujet sécurité : swifty-companion.md § IV
PDF : originaux/swifty_companion_subject.pdf

8.3 KiB Raw Blame History Unescape Escape

Fiche — dépôt de soutenance, branche soutenance, PC école