Skip to content
Snippets Groups Projects
Commit 4cf00489 authored by Ethan Robert's avatar Ethan Robert
Browse files

Added instructions for gitea

parent 1288fe4a
No related branches found
No related tags found
No related merge requests found
assets/admin-runners.png

136 KiB

assets/gitea-full-repo.png

374 KiB

assets/gitea-home.png

288 KiB

assets/gitea-new-repo.png

241 KiB

assets/gitea-profile.png

208 KiB

assets/gitea-register.png

239 KiB

assets/gitea-repo.png

257 KiB

...@@ -162,4 +162,162 @@ docker-compose pull ...@@ -162,4 +162,162 @@ docker-compose pull
docker-compose up -d docker-compose up -d
``` ```
Et tout est mis à jour automatiquement. Et tout est mis à jour automatiquement.
\ No newline at end of file
# Tests d'utilisation
Il est maintenant temps de tester notre installation en essayant d'utiliser le service Gitea disponible sur le port 3000.
Commençons donc par créer un nouvel utilisateur à partir de l'interface.
![Page d'accueil de Gitea](assets/gitea-home.png)
![Inscription d'un nouvel utilisateur](assets/gitea-register.png)
On arrive donc dans notre page de profil, où il n'existe pour l'instant aucun dépôt. Crééons-en donc un !
![Page de profil vierge Gitea](assets/gitea-profile.png)
Créons donc un nouveau dépôt pour y déposer la source des rapports de cette SAÉ.
On commence donc par cliquer sur + > Nouveau dépôt. On entre le nom du dépôt (ici, ce sera les rapports pour S2.03), une description si besoin, puis on clique sur "Créer" pour finaliser la création du dépôt. Exactement comme sur Gitlab ou GitHub.
![Nouveau dépôt sur Gitea](assets/gitea-new-repo.png)
On arrive ainsi sur une nouvelle page indiquant que le nouveau dépôt est crée.
On souhaite maintenant y ajouter du code. Il est l'heure de **manipuler un peu le terminal de la machine hôte**.
Comme le dépôt local existe déjà, et possède déjà une **remote**, qui pointe vers le serveur Gitlab de l'université, il faudra simplement en ajouter une nouvelle
```bash
git remote add gitea http://10.21.215.74:3000/robert/S2.03
```
Une fois cela fait, on peut simplement envoyer les modifications sur gitea.
```
git push gitea main
```
L'argument `gitea` indique que l'on souhaite bel et bien envoyer le code sur la remote `gitea`, que l'on vient juste de créer.
Git nous demande d'entrere un nom d'utilisateur ainsi qu'un mot de passe pour l'authentification, et une fois cela entré, il suffit d'attendre et de valider l'envoi des changements sur le serveur distant.
Une fois cela fait, on met simplement à jour la page, et on a cette fois-ci accès au code complet de la SAÉ.
![Le dépôt S2.03 une fois les changements envoyés](assets/gitea-full-repo.png)
Tout ceci semble fonctionner plutôt bien. On peut donc affirmer que le serveur Gitea est opérationnel et fonctionne bien.
# CI/CD, Actions : Pour aller plus loin
Les hébergeurs de code Git intègrent souvent des outils d'intégration et déploiement en continu (CI/CD pour Continuous Integration/Continuous Deployment).
## Définitions et principes
L'**intégration continue** consiste à automatiquement intégrer des modifications de code dans un dépôt partagé (ex: dépôt git), et à compiler et tester automatiquement le logiciel pour s'assurer qu'il continue de fonctionner comme prévu.
Le **déploiement continu**, dans le même temps, est la pratique consistant à déployer (compiler et envoyer en *release*) automatiquement de nouvelles versions du projet une fois qu'elles ont **passé les étapes de construction et de test** (intégration). Cela permet de publier plus rapidement les nouvelles fonctionnalités, pour **éviter de devoir tout faire manuellement**.
### Pipeline CI/CD
L'intégration continue et le déploiement continu réunis s'appellement **le pipeline CI/CD**. Il s'agit d'une combinaison d'outils (au sens informatique du terme, donc des *commandes*), de pratiques et de processus qui **fonctionnent ensemble pour intégrer, tester, et déployer en continu les changements de code**.
Sa mise en oeuvre passe souvent par plusieurs pratiques :
- Compilation automatique de code dans des environnements contrôlés (machines virtuelles)
- Tests du projet, donc à la fois des tests unitaires, et fonctionnels (exécution surveillée du projet dans des conteneurs automatisés pour vérifier son bon fonctionnement)
- Publication automatisée des nouvelles versions sur le serveur de distribution.
La raison pour laquelle les plateformes de gestion de code intègrent souvent ces ensembles d'outils est leur **grande omnipotence**. En effet, la plupart de ces plateformes réunissent :
- Un dépôt partagé de code
- Une documentation éditable (wiki)
- Un système de distribution de versions fixes (tags, releases)
- Pour certains, un serveur web (GitHub Pages, Gitlab Pages).
Il est donc parfaitement logique que ces plateformes mettent à disposition un système permettant de **relier cet ensemble d'outils via du scripting**.
## Utilisation sur Gitea
Fort heureusement, Gitea possède tout ce qu'il faut, par le biais de ses *Actions* (comme sur GitHub), pour faire fonctionner des pipelines basiques de CI/CD.
### Installation du *runner*
La première étape consiste à installer un *runner*. Il s'agit d'un programme ayant pour but d'exécuter des commandes, afin de mener à bien des tâches automatisées.
#### Téléchargement de `act_runner`
Il faut donc tout d'abord récupérer un `act_runner` depuis la [page des releases officielle](https://gitea.com/gitea/act_runner/releases). Il existe une bonne quantité de choix de binaires, suivant le système d'exploitation et l'architecture du processeur de la machine hôte. Nous choisirons ici `act_runner-linux-arm64`.
L'idée est de placer ce programme dans un endroit où le service Gitea pourra y avoir accès. Il servira à exécuter toutes les commandes des pipelines CI/CD.
Le "home directory" `~` de l'utilisateur `git` fera parfaitement l'affaire.
```bash
# Connection en tant que git
su - git
cd ~
# Téléchargement de l'act_runner
wget https://gitea.com/gitea/act_runner/releases/download/v0.2.11/act_runner-0.2.11-linux-arm64
mv act_runner-0.2.11-linux-arm64 act_runner
# Ajout des permissions exécutable et vérifications
chmod +x act_runner
./act_runner --version
```
#### Enregistrement du programme
Pour permettre à Gitea d'utiliser `act_runner`, il faut tout d'abord **récupérer un token d'enregistrement**.
Connectons-nous à notre utilisateur Gitea (le premier crée, l'administrateur), et rendons-nous à cette adresse :
> `https://localhost:3000/-/admin/actions/runners`
On a alors accès à la page d'administration des actions, depuis laquelle on peut obtenir une liste de runners enregistrés.
![Administration - runners Gitea](assets/admin-runners.png)
Pour en créer un, il faut lui passer un **token d'enregistrement**, qu'on vient récupérer ici.
En haut à droite, cliquer sur le bouton bleu **Créer un nouvel exécuteur**, et copier le champ "registration token" qui s'affiche.
On retourne ensuite dans le terminal, et on entre :
```bash
# Enregistrement du runner
./act_runner register
```
On entre ensuite simplement le token copié plus tôt, et le tour est joué !
*(Source : [Gitea Documentation](https://docs.gitea.com/usage/actions/act-runner))*
### Utilisation des Gitea Actions
Les Gitea Actions fonctionnent de manière assez similaire à celles de GitHub ou à Gitlab CI, c'est-à-dire avec un fichier `.yml`, dont voici un exemple :
```yml
name: Gitea Actions Demo
run-name: ${{ gitea.actor }} is testing out Gitea Actions
on: [push]
jobs:
Explore-Gitea-Actions:
runs-on: ubuntu-latest
steps:
- run: echo "The job was automatically triggered by a ${{ gitea.event_name }} event."
- run: echo "This job is now running on a ${{ runner.os }} server hosted by Gitea!"
- run: echo "The name of your branch is ${{ gitea.ref }} and your repository is ${{ gitea.repository }}."
- name: Check out repository code
uses: actions/checkout@v4
- run: echo "The ${{ gitea.repository }} repository has been cloned to the runner."
- run: echo "The workflow is now ready to test your code on the runner."
- name: List files in the repository
run: |
ls ${{ gitea.workspace }}
- run: echo "This job's status is ${{ job.status }}."
```
À l'instar de GitHub, il suffit de placer ce fichier dans `.gitea/workflows/exemple.yml`, et les changements seront **automatiquement pris en compte**.
Le workflow sera ainsi exécuté selon le fichier YML à chaque push.
*(Source : [Gitea Documentation](https://docs.gitea.com/usage/actions/quickstart))*
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Please register or to comment