MAJ de la doc determine bumpType & ajout de la doc pour dockerLogin et versionBumper

determineBumpType/README.md

@@ -1,10 +1,62 @@
-# Action  "determineBumpType"
+# Action "Determine bump type from commit message"
 
 ## Description
-Une action permettant de trouver le type de bump à effectuer (Major, Minor, Patch). 
-  
-L'action cherche à trouver les chaines suivante dans le message de commit : [MAJOR] ou [MINOR]. Si aucune de ces chaines n'est trouvé, alors le type de bump est "PATCH".
 
-## Paramètre obligatoire
+Une action composite permettant de déterminer le type de bump de version
+(`MAJOR`, `MINOR`, `PATCH`) à effectuer à partir du message de commit.
 
-- COMMIT_MESSAGE : Ce paramètre doit contenir le message du commit à parser.
+L'action recherche les chaînes suivantes dans le message de commit :
+
+- `[MAJOR]` → bump `MAJOR`.
+- `[MINOR]` → bump `MINOR`.
+- Aucune des deux → bump `PATCH` (valeur par défaut).
+
+> Note : `[MAJOR]` est prioritaire sur `[MINOR]` si les deux sont présents dans
+> le message.
+
+Le résultat est exposé via la sortie `bumpType`, qui peut alimenter directement
+l'action `versionBumper`.
+
+## Paramètres
+
+| Paramètre        | Obligatoire | Défaut | Description                          |
+| ---------------- | ----------- | ------ | ------------------------------------ |
+| `COMMIT_MESSAGE` | Oui         | —      | Message du commit à parser.          |
+
+## Sorties
+
+| Sortie     | Description                                                        |
+| ---------- | ----------------------------------------------------------------- |
+| `bumpType` | Type de bump détecté : `MAJOR`, `MINOR` ou `PATCH`.               |
+
+## Exemple d'utilisation
+
+```yaml
+steps:
+  - name: Déterminer le type de bump
+    id: bump
+    uses: ./determineBumpType
+    with:
+      COMMIT_MESSAGE: ${{ github.event.head_commit.message }}
+
+  - name: Bump de la version
+    uses: ./versionBumper
+    with:
+      bumpType: ${{ steps.bump.outputs.bumpType }}
+```
+
+## Points d'attention
+
+- **Sortie via `$FORGEJO_OUTPUT`** : l'action écrit dans `$FORGEJO_OUTPUT`. Elle
+  est donc prévue pour s'exécuter sur un runner Forgejo. Pour la récupérer, il
+  faut donner un `id` à l'étape et lire `steps.<id>.outputs.bumpType`.
+- **Recherche sensible à la casse** : les marqueurs recherchés sont exactement
+  `[MAJOR]` et `[MINOR]` (en majuscules et avec les crochets). Une variante
+  comme `[major]` ou `MAJOR` (sans crochets) ne sera pas reconnue et donnera
+  `PATCH`.
+- **Priorité** : `[MAJOR]` l'emporte sur `[MINOR]` lorsque les deux marqueurs
+  sont présents.
+- **Comportement par défaut** : tout message ne contenant aucun marqueur
+  retourne `PATCH` — il n'y a jamais d'échec lié à un message "non reconnu".
+- **Message multi-lignes** : le `COMMIT_MESSAGE` peut contenir plusieurs lignes ;
+  pensez à bien passer le message complet (ex. `head_commit.message`).

dockerLogin/README.md

@@ -0,0 +1,47 @@
+# Action "Docker login to registry"
+
+## Description
+
+Une action composite permettant de se connecter au registry Docker de Pixao en
+utilisant les secrets de Forgejo.
+
+Le registry utilisé est celui intégré à Forgejo : son adresse est donc
+identique à l'URL de l'instance Forgejo.
+
+L'action exécute simplement un `docker login` en passant le mot de passe via
+`--password-stdin` (le mot de passe n'apparaît donc pas dans la ligne de
+commande).
+
+## Paramètres
+
+| Paramètre           | Obligatoire | Défaut            | Description                                                                                      |
+| ------------------- | ----------- | ----------------- | ------------------------------------------------------------------------------------------------ |
+| `REGISTRY_URL`      | Non         | `192.168.20.225`  | Adresse du registry (identique à l'URL Forgejo car on utilise le registry intégré à ce dernier). |
+| `REGISTRY_USER`     | Oui         | —                 | Utilisateur pour se connecter au registry.                                                       |
+| `REGISTRY_PASSWORD` | Oui         | —                 | Mot de passe de l'utilisateur.                                                                    |
+
+## Exemple d'utilisation
+
+```yaml
+steps:
+  - name: Connexion au registry
+    uses: ./dockerLogin
+    with:
+      REGISTRY_USER: ${{ secrets.REGISTRY_USER }}
+      REGISTRY_PASSWORD: ${{ secrets.REGISTRY_PASSWORD }}
+      # REGISTRY_URL est optionnel, la valeur par défaut pointe vers le registry Pixao
+```
+
+## Points d'attention
+
+- **Docker requis** : le runner qui exécute cette action doit disposer de la
+  commande `docker` et avoir accès au démon Docker.
+- **Secrets Forgejo** : `REGISTRY_USER` et `REGISTRY_PASSWORD` doivent être
+  fournis via les secrets de Forgejo et **jamais** écrits en clair dans le
+  workflow.
+- **URL par défaut** : la valeur par défaut de `REGISTRY_URL`
+  (`192.168.20.225`) est spécifique à l'infrastructure Pixao. Si vous changez
+  d'environnement, pensez à surcharger ce paramètre.
+- **Persistance de la session** : le `docker login` reste valable pour les
+  étapes suivantes du même job. Il faut se reconnecter dans chaque job qui en a
+  besoin.

versionBumper/README.md

@@ -0,0 +1,73 @@
+# Action "Version Bumper"
+
+## Description
+
+Une action composite permettant de récupérer et d'incrémenter la version
+contenue dans le fichier `.version` à la racine du dépôt.
+
+La version suit le format [SemVer](https://semver.org/lang/fr/) :
+`MAJOR.MINOR.PATCH` (ex. `1.4.2`). Selon le type de bump demandé, l'action
+incrémente la partie correspondante :
+
+- `MAJOR` : `1.4.2` → `2.0.0` (réinitialise minor et patch).
+- `MINOR` : `1.4.2` → `1.5.0` (réinitialise patch).
+- `PATCH` : `1.4.2` → `1.4.3`.
+
+L'action configure ensuite un utilisateur git, écrit la nouvelle version dans
+`.version`, puis **commit et push** le changement.
+
+> Astuce : le type de bump peut être déterminé automatiquement à partir du
+> message de commit grâce à l'action `determineBumpType`, dont la sortie peut
+> alimenter le paramètre `bumpType`.
+
+## Paramètres
+
+| Paramètre  | Obligatoire | Défaut  | Description                                              |
+| ---------- | ----------- | ------- | ------------------------------------------------------- |
+| `bumpType` | Non         | `PATCH` | Type de bump de version : `MAJOR`, `MINOR` ou `PATCH`.  |
+
+## Exemple d'utilisation
+
+```yaml
+steps:
+  - name: Bump de la version
+    uses: ./versionBumper
+    with:
+      bumpType: MINOR
+```
+
+Combiné avec `determineBumpType` :
+
+```yaml
+steps:
+  - name: Déterminer le type de bump
+    id: bump
+    uses: ./determineBumpType
+    with:
+      COMMIT_MESSAGE: ${{ github.event.head_commit.message }}
+
+  - name: Bump de la version
+    uses: ./versionBumper
+    with:
+      bumpType: ${{ steps.bump.outputs.bumpType }}
+```
+
+## Points d'attention
+
+- **Fichier `.version` requis** : le fichier `.version` doit exister à la racine
+  du dépôt et contenir une version valide au format `MAJOR.MINOR.PATCH`. Sinon
+  le `cat` échoue ou produit une version incohérente.
+- **Valeurs sensibles à la casse** : le paramètre `bumpType` est comparé en
+  majuscules (`MAJOR`, `MINOR`, `PATCH`). Une valeur comme `minor` ou `Patch`
+  ne déclenchera aucune des étapes et **aucun bump ne sera effectué**.
+- **Commit & push automatiques** : l'action pousse directement sur la branche
+  courante. Le runner doit donc disposer des droits d'écriture (token avec
+  permission `contents: write` / accès push configuré).
+- **`[skip ci]`** : le message de commit contient `[skip ci]` afin d'éviter de
+  redéclencher un pipeline en boucle. Vérifiez que votre CI respecte bien cette
+  convention.
+- **Checkout complet** : assurez-vous que l'étape de checkout permet le push
+  (branche correctement positionnée, pas en état *detached HEAD*).
+- **Échec si rien à committer** : l'étape `Commit & push` échoue si aucun
+  changement n'a été ajouté (par exemple si `bumpType` est invalide), car
+  `git commit` n'a rien à committer.