lot2
This commit is contained in:
233
docs/pedagogie/fiche-depot-soutenance.md
Normal file
233
docs/pedagogie/fiche-depot-soutenance.md
Normal file
@@ -0,0 +1,233 @@
|
||||
# Fiche — dépôt de soutenance, branche `soutenance`, PC école
|
||||
|
||||
> **Lot 1** du [plan de préparation](00-plan-preparation-soutenance.md).
|
||||
> **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` :
|
||||
|
||||
```yaml
|
||||
assets:
|
||||
- .env
|
||||
```
|
||||
|
||||
→ chemin **obligatoire pour l’exécution** :
|
||||
|
||||
```text
|
||||
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 :**
|
||||
|
||||
```bash
|
||||
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).
|
||||
|
||||
```text
|
||||
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)
|
||||
|
||||
```bash
|
||||
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
|
||||
|
||||
```bash
|
||||
# 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](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](00-plan-preparation-soutenance.md)
|
||||
- Sujet sécurité : [swifty-companion.md](../sujets/swifty-companion.md) § IV
|
||||
- PDF : [originaux/swifty_companion_subject.pdf](../sujets/originaux/swifty_companion_subject.pdf)
|
||||
Reference in New Issue
Block a user