|
|
|
@ -1,177 +0,0 @@ |
|
|
|
*** |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
titre : "Versions et builds" |
|
|
|
|
|
|
|
description : "NocoDB crée Docker et des binaires pour chaque PR" |
|
|
|
|
|
|
|
balises : \['Ingénierie'] |
|
|
|
|
|
|
|
------------------------- |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Constructions de NocoDB |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Il existe 3 types de builds Docker dans NocoDB |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Versions de publication[nocodb/nocodb](https://hub.docker.com/r/nocodb/nocodb): construit lors de la version NocoDB. |
|
|
|
|
|
|
|
* Constructions quotidiennes[nocodb/nocodb-daily](https://hub.docker.com/r/nocodb/nocodb-daily): construit toutes les 6 heures à partir de la branche Develop. |
|
|
|
|
|
|
|
* Constructions en temps opportun[nocodb/nocodb-timely](https://hub.docker.com/r/nocodb/nocodb-timely): construit pour chaque PR et PR déclenchés manuellement. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Vous trouverez ci-dessous un aperçu de la façon de réaliser ces builds et de ce qui se passe dans les coulisses. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Versions de publication |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Comment faire un build de release ? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Cliquez sur[Action de publication de NocoDB](https://github.com/nocodb/nocodb/actions/workflows/release-nocodb.yml) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Vous devriez voir l'écran ci-dessous |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Changement`Use workflow from`à`Branch: master`. Si vous choisissez la mauvaise branche, le workflow sera terminé. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Il y aurait alors deux cas : vous pouvez soit laisser la balise cible et la balise précédente vides, soit saisir manuellement une valeur. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* La balise cible signifie la version de déploiement cible, tandis que la balise précédente signifie la dernière version à ce jour. La balise précédente est utilisée uniquement pour la note de version - affichant les différences de fichier/validation entre deux balises. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Marquage |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
La convention de dénomination suivrait étant donné que la balise de version réelle est`0.100.0` |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* `0.100.0-beta.0`(première version de la pré-version) |
|
|
|
|
|
|
|
* `0.100.0-beta.1`(inclure les modifications de correction de bogues en plus de la version précédente) |
|
|
|
|
|
|
|
* `0.100.0-beta.2`(inclure les modifications de correction de bogues en plus de la version précédente) |
|
|
|
|
|
|
|
* et ainsi de suite ... |
|
|
|
|
|
|
|
* `0.100.0`(version réelle) |
|
|
|
|
|
|
|
* `0.100.1`(version de correction de bug mineur) |
|
|
|
|
|
|
|
* `0.100.2`(version de correction de bug mineur) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Cas 1 : laisser les entrées vides |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Si la balise précédente est vide, la valeur sera récupérée à partir de[dernier](https://github.com/nocodb/nocodb/releases/latest) |
|
|
|
|
|
|
|
* Si la balise cible est vide, la valeur sera la balise précédente plus un. Exemple : 0.90.11 (balise précédente) + 0.0.1 = 0.90.12 (balise cible) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Cas 2 : saisie manuelle |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pourquoi? Parfois, nous pouvons gâcher le déploiement de NPM. Comme NPM ne nous permet pas de redéployer à nouveau vers la même balise, dans ce cas, nous ne pouvons pas simplement utiliser la balise précédente + 1. Par conséquent, nous devons plutôt utiliser la balise précédente + 2 et nous la configurons manuellement. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Après cela, cliquez`Run workflow`commencer |
|
|
|
|
|
|
|
* Vous pouvez voir le résumé pour l'état global du travail. |
|
|
|
|
|
|
|
* Une fois`release-draft-note`et`release-executables`est terminé, alors allez à[sorties](https://github.com/nocodb/nocodb/releases), modifiez le brouillon de note et enregistrez-le en tant que brouillon pour le moment. |
|
|
|
|
|
|
|
* Exemple : ajout d'un en-tête, mettez à jour le contenu si nécessaire et cliquez sur`Auto-generate release notes`pour inclure plus d'informations. |
|
|
|
|
|
|
|
* Une fois`release-docker`est terminé, puis testez-le d'abord localement. On s'attendra à ce que vous voyiez`Upgrade Available`notification dans l'interface utilisateur car nous n'avons pas publié la note de version. (la version est récupérée à partir de là) |
|
|
|
|
|
|
|
* Une fois que tout est terminé, publiez alors la release note et le déploiement est considéré comme TERMINÉ. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Comment fonctionne l'action de libération ? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### valider la branche |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pour vérifier si`github.ref`est maître. A défaut, les autres succursales ne seront pas acceptées. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### entrée de processus |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Pour enrichir la balise cible ou la balise précédente si nécessaire. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### pr-à-master |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Automatisez un PR de la branche de développement à la branche principale afin que nous connaissions les différences réelles entre la balise précédente et la balise actuelle. Nous choisissons la branche master pour une base de déploiement. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### version-npm |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Créez le frontend et le backend et publiez-les sur NPM. Les modifications lors de la construction, telles que le changement de version, seront validées et poussées vers une branche temporaire et un PR automatisé sera créé et fusionné avec la branche principale. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notez qu'une fois que vous publiez avec une certaine balise, vous ne pouvez plus publier avec la même balise. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### version-projet-note |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Générez un brouillon de note de version. Certaines actions doivent être effectuées après cette étape. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### version-docker |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Créez une image Docker et publiez-la sur Docker Hub. Cela peut prendre environ 15 à 30 minutes. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### problèmes clôturés |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Problèmes ouverts marqués d'une étiquette`Status: Fixed`et`Status: Resolved`sera fermé automatiquement par le bot avec un commentaire mentionnant que le correctif est inclus dans quelle version. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Exemple: |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### publier des documents |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Publish Documentation |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### chemin de mise à jour du SDK |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`nocodb-sdk`est utilisé en frontend et backend. Cependant, dans la branche de développement, la valeur serait`file:../nocodb-sdk`à des fins de développement (afin que les modifications apportées dans nocodb-sdk en développement soient incluses dans le frontend et le backend). Lors du déploiement, la valeur sera remplacée par la balise cible. Ce travail consiste à les mettre à jour. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### synchronisation pour développer |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Une fois le déploiement terminé, de nouvelles modifications seront apportées à la branche master. Ce travail consiste à synchroniser les modifications à développer afin que les deux branches n'aient aucune différence. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Constructions quotidiennes |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Que sont les builds quotidiens ? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* NocoDB crée toutes les 6 heures à partir des branches de développement et publie sous nocodb/nocodb-daily |
|
|
|
|
|
|
|
* Ceci afin que nous puissions facilement essayer ce qui se trouve dans la branche de développement. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Images Docker |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Les images Docker seront créées et poussées vers Docker Hub (voir[nocodb/nocodb-daily](https://hub.docker.com/r/nocodb/nocodb-daily/tags)pour la liste complète). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Constructions en temps opportun |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Que sont les builds opportuns ? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NocoDB a des actions github qui créent un docker et des binaires pour chaque PR ! Et ceux-ci peuvent être trouvés sous forme de**commenter le dernier commit**du PR. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Exemple ci-dessous |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Accédez à un PR et cliquez sur le commentaire. |
|
|
|
|
|
|
|
<img width="1111" alt="Screenshot 2023-01-23 at 15 46 36" src="https://user-images.githubusercontent.com/5435402/214083736-80062398-3712-430f-9865-86b110090c91.png" /> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* Cliquez sur le lien pour copier l'image du docker et l'exécuter localement. |
|
|
|
|
|
|
|
<img width="1231" alt="Screenshot 2023-01-23 at 15 46 55" src="https://user-images.githubusercontent.com/5435402/214083755-945d9485-2b9e-4739-8408-068bdf4a84b7.png" /> |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
C'est pour |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* réduire le temps de cycle des demandes d'extraction |
|
|
|
|
|
|
|
* permettre aux rapporteurs/réviseurs de problèmes de vérifier le correctif sans configurer leurs machines locales |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Images Docker |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Lorsqu'une demande d'extraction non brouillon est créée, rouverte ou synchronisée, une construction en temps opportun pour Docker serait déclenchée pour les modifications incluses uniquement dans les chemins suivants. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* `packages/nocodb-sdk/**` |
|
|
|
|
|
|
|
* `packages/nc-gui/**` |
|
|
|
|
|
|
|
* `packages/nc-plugin/**` |
|
|
|
|
|
|
|
* `packages/nocodb/**` |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Les images Docker seront créées et poussées vers Docker Hub (voir[nocodb/nocodb-timely](https://hub.docker.com/r/nocodb/nocodb-timely/tags)pour la liste complète). Une fois l'image prête, le bot GitHub ajoutera un commentaire avec la commande dans la pull request. L'étiquette serait`<NOCODB_CURRENT_VERSION>-pr-<PR_NUMBER>-<YYYYMMDD>-<HHMM>`. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
## Exécutables ou binaires |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
De même, nous fournissons une version en temps opportun des exécutables pour les utilisateurs non-Docker. Le code source sera construit, conditionné sous forme de fichiers binaires et transféré vers GitHub (voir[nocodb/nocodb-timely](https://github.com/nocodb/nocodb-timely/releases)pour la liste complète). |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Actuellement, nous prenons uniquement en charge les cibles suivantes : |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* `node16-linux-arm64` |
|
|
|
|
|
|
|
* `node16-macos-arm64` |
|
|
|
|
|
|
|
* `node16-win-arm64` |
|
|
|
|
|
|
|
* `node16-linux-x64` |
|
|
|
|
|
|
|
* `node16-macos-x64` |
|
|
|
|
|
|
|
* `node16-win-x64` |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Une fois les exécutables prêts, le bot GitHub ajoutera un commentaire avec les commandes dans la pull request. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
NocoDB crée Docker et Binaries pour chaque PR. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
C'est pour |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
* réduire le temps de cycle des demandes d'extraction |
|
|
|
|
|
|
|
* permettre aux rapporteurs/réviseurs de problèmes de vérifier le correctif sans configurer leurs machines locales |
|
|
|
|
Anbarasu
8 months ago
committed by
GitHub