
Some checks failed
CI - 4NK_node / Code Quality (push) Failing after 37s
CI - 4NK_node / Unit Tests (push) Failing after 36s
CI - 4NK_node / Integration Tests (push) Successful in 33s
CI - 4NK_node / Security Tests (push) Failing after 32s
CI - 4NK_node / Docker Build & Test (push) Failing after 15s
CI - 4NK_node / Documentation Tests (push) Successful in 10s
CI - 4NK_node / Security Audit (push) Successful in 8s
CI - 4NK_node / Release Guard (push) Has been skipped
CI - 4NK_node / Performance Tests (push) Successful in 34s
CI - 4NK_node / Notify (push) Failing after 2s
CI - 4NK_node / Publish Release (push) Has been skipped
286 lines
6.4 KiB
Markdown
286 lines
6.4 KiB
Markdown
# Configuration Gitea - 4NK_node
|
||
|
||
Ce guide explique comment configurer le projet 4NK_node spécifiquement pour Gitea (git.4nkweb.com).
|
||
|
||
## 🎯 Configuration Gitea
|
||
|
||
### Repository Configuration
|
||
|
||
Le projet est hébergé sur : **https://git.4nkweb.com/4nk/4NK_node**
|
||
|
||
### Branches Principales
|
||
|
||
- **`main`** - Branche principale, code stable
|
||
- **`develop`** - Branche de développement (optionnelle)
|
||
- **`feature/*`** - Branches de fonctionnalités
|
||
- **`fix/*`** - Branches de corrections
|
||
|
||
### Protection des Branches
|
||
|
||
Configurez les protections suivantes sur Gitea :
|
||
|
||
1. **Branche `main`** :
|
||
- ✅ Require pull request reviews before merging
|
||
- ✅ Require status checks to pass before merging
|
||
- ✅ Require branches to be up to date before merging
|
||
- ✅ Restrict pushes that create files
|
||
- ✅ Restrict pushes that delete files
|
||
|
||
2. **Branche `develop`** (si utilisée) :
|
||
- ✅ Require pull request reviews before merging
|
||
- ✅ Require status checks to pass before merging
|
||
|
||
## 🔧 Configuration CI/CD
|
||
|
||
### Option 1 : Gitea Actions (Recommandé)
|
||
|
||
Si votre instance Gitea supporte Gitea Actions :
|
||
|
||
```yaml
|
||
# .gitea/workflows/ci.yml
|
||
name: CI - 4NK_node
|
||
|
||
on:
|
||
push:
|
||
branches: [ main, develop ]
|
||
pull_request:
|
||
branches: [ main, develop ]
|
||
|
||
jobs:
|
||
test:
|
||
runs-on: ubuntu-latest
|
||
steps:
|
||
- uses: actions/checkout@v3
|
||
- name: Setup Rust
|
||
uses: actions-rs/toolchain@v1
|
||
with:
|
||
toolchain: stable
|
||
- name: Run tests
|
||
run: |
|
||
cd sdk_relay
|
||
cargo test
|
||
```
|
||
|
||
### Option 2 : Runner Externe
|
||
|
||
Configurez un runner CI/CD externe (Jenkins, GitLab CI, etc.) :
|
||
|
||
```bash
|
||
# Exemple avec Jenkins
|
||
pipeline {
|
||
agent any
|
||
stages {
|
||
stage('Checkout') {
|
||
steps {
|
||
checkout scm
|
||
}
|
||
}
|
||
stage('Test') {
|
||
steps {
|
||
sh 'cd sdk_relay && cargo test'
|
||
}
|
||
}
|
||
stage('Build') {
|
||
steps {
|
||
sh 'docker-compose build'
|
||
}
|
||
}
|
||
}
|
||
}
|
||
```
|
||
|
||
#### Publication automatique des releases
|
||
|
||
- Définir un secret de repository nommé `RELEASE_TOKEN` (scope: write:repository) dans Gitea.
|
||
- Le workflow `.gitea/workflows/ci.yml` publie automatiquement une release lors d’un push de tag `v*` en utilisant ce secret.
|
||
- Le corps de la release référence `CHANGELOG.md`. Pour des notes plus détaillées, mettez à jour le changelog avant de créer le tag.
|
||
|
||
### Option 3 : GitHub Actions (Migration)
|
||
|
||
Si vous souhaitez utiliser GitHub Actions avec un miroir :
|
||
|
||
1. Créez un repository miroir sur GitHub
|
||
2. Configurez un webhook pour synchroniser automatiquement
|
||
3. Utilisez le workflow GitHub Actions existant
|
||
|
||
## 📋 Templates Gitea
|
||
|
||
### Issues Templates
|
||
|
||
Les templates d'issues sont stockés dans `.gitea/ISSUE_TEMPLATE/` :
|
||
|
||
- `bug_report.md` - Pour signaler des bugs
|
||
- `feature_request.md` - Pour proposer des fonctionnalités
|
||
|
||
### Pull Request Template
|
||
|
||
Le template de PR est dans `.gitea/PULL_REQUEST_TEMPLATE.md`
|
||
|
||
## 🔗 Intégrations Gitea
|
||
|
||
### Webhooks
|
||
|
||
Configurez des webhooks pour :
|
||
|
||
1. **Notifications** - Slack, Discord, Email
|
||
2. **CI/CD** - Déclenchement automatique des builds
|
||
3. **Deployment** - Déploiement automatique
|
||
|
||
### API Gitea
|
||
|
||
Utilisez l'API Gitea pour l'automatisation :
|
||
|
||
```bash
|
||
# Exemple : Créer une release
|
||
curl -X POST "https://git.4nkweb.com/api/v1/repos/4nk/4NK_node/releases" \
|
||
-H "Authorization: token YOUR_TOKEN" \
|
||
-H "Content-Type: application/json" \
|
||
-d '{
|
||
"tag_name": "v1.0.0",
|
||
"name": "Release v1.0.0",
|
||
"body": "Description de la release"
|
||
}'
|
||
```
|
||
|
||
## 🏷️ Labels et Milestones
|
||
|
||
### Labels Recommandés
|
||
|
||
- **bug** - Problèmes et bugs
|
||
- **enhancement** - Nouvelles fonctionnalités
|
||
- **documentation** - Amélioration de la documentation
|
||
- **good first issue** - Pour les nouveaux contributeurs
|
||
- **help wanted** - Besoin d'aide
|
||
- **priority: high** - Priorité élevée
|
||
- **priority: low** - Priorité basse
|
||
- **status: blocked** - Bloqué
|
||
- **status: in progress** - En cours
|
||
- **status: ready for review** - Prêt pour review
|
||
|
||
### Milestones
|
||
|
||
- **v1.0.0** - Version stable initiale
|
||
- **v1.1.0** - Améliorations et corrections
|
||
- **v2.0.0** - Nouvelles fonctionnalités majeures
|
||
|
||
## 🔐 Sécurité Gitea
|
||
|
||
### Permissions
|
||
|
||
1. **Repository** :
|
||
- Public pour l'open source
|
||
- Issues et PR activés
|
||
- Wiki activé (optionnel)
|
||
|
||
2. **Collaborateurs** :
|
||
- Maintainers : Write access
|
||
- Contributors : Read access
|
||
- Public : Read access
|
||
|
||
### Secrets
|
||
|
||
Stockez les secrets sensibles dans les variables d'environnement Gitea :
|
||
|
||
- `DOCKER_USERNAME`
|
||
- `DOCKER_PASSWORD`
|
||
- `GITEA_TOKEN`
|
||
- `SLACK_WEBHOOK_URL`
|
||
|
||
## 📊 Monitoring et Analytics
|
||
|
||
### Gitea Analytics
|
||
|
||
- **Traffic** - Vues du repository
|
||
- **Contributors** - Contributeurs actifs
|
||
- **Issues** - Statistiques des issues
|
||
- **Pull Requests** - Statistiques des PR
|
||
|
||
### Intégrations Externes
|
||
|
||
- **Codecov** - Couverture de code
|
||
- **SonarCloud** - Qualité du code
|
||
- **Dependabot** - Mise à jour des dépendances
|
||
|
||
## 🚀 Workflow de Contribution
|
||
|
||
### 1. Fork et Clone
|
||
|
||
```bash
|
||
# Fork sur Gitea
|
||
# Puis clone
|
||
git clone https://git.4nkweb.com/votre-username/4NK_node.git
|
||
cd 4NK_node
|
||
|
||
# Ajouter l'upstream
|
||
git remote add upstream https://git.4nkweb.com/4nk/4NK_node.git
|
||
```
|
||
|
||
### 2. Développement
|
||
|
||
```bash
|
||
# Créer une branche
|
||
git checkout -b feature/nouvelle-fonctionnalite
|
||
|
||
# Développer
|
||
# ...
|
||
|
||
# Commiter
|
||
git commit -m "feat: ajouter nouvelle fonctionnalité"
|
||
|
||
# Pousser
|
||
git push origin feature/nouvelle-fonctionnalite
|
||
```
|
||
|
||
### 3. Pull Request
|
||
|
||
1. Créer une PR sur Gitea
|
||
2. Remplir le template
|
||
3. Attendre les reviews
|
||
4. Merge après approbation
|
||
|
||
## 🔧 Configuration Avancée
|
||
|
||
### Gitea Configuration
|
||
|
||
```ini
|
||
# gitea.ini
|
||
[repository]
|
||
DEFAULT_BRANCH = main
|
||
PUSH_CREATE_DELETE_PROTECTED_BRANCH = true
|
||
|
||
[repository.pull-request]
|
||
ENABLE_WHITELIST = true
|
||
WHITELIST_USERS = admin,maintainer
|
||
```
|
||
|
||
### Webhooks Configuration
|
||
|
||
```yaml
|
||
# webhook.yml
|
||
url: "https://your-ci-server.com/webhook"
|
||
content_type: "application/json"
|
||
secret: "your-secret"
|
||
events:
|
||
- push
|
||
- pull_request
|
||
- issues
|
||
```
|
||
|
||
## 📚 Ressources
|
||
|
||
### Documentation Gitea
|
||
|
||
- [Gitea Documentation](https://docs.gitea.io/)
|
||
- [Gitea API](https://docs.gitea.io/en-us/api-usage/)
|
||
- [Gitea Actions](https://docs.gitea.io/en-us/actions/)
|
||
|
||
### Outils Utiles
|
||
|
||
- **Gitea CLI** - Interface en ligne de commande
|
||
- **Gitea SDK** - SDK pour l'automatisation
|
||
- **Gitea Runner** - Runner pour les actions
|
||
|
||
---
|
||
|
||
**Configuration Gitea terminée ! Le projet est prêt pour l'open source sur git.4nkweb.com** 🚀
|