From 82b0530ade166bf3ad91f001e902c344f9dfc162 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 08:46:34 +0100 Subject: [PATCH 01/16] feat(ci): allow hotfixes with release-please --- .github/workflows/cd.yml | 1 + 1 file changed, 1 insertion(+) diff --git a/.github/workflows/cd.yml b/.github/workflows/cd.yml index e84ee6cc7..4c5f65bc2 100644 --- a/.github/workflows/cd.yml +++ b/.github/workflows/cd.yml @@ -4,6 +4,7 @@ on: push: branches: - main + - hotfix/* env: REGISTRY: ghcr.io From eaaca769cf43db22ba1b9ac3928f15fba9cce951 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 08:51:28 +0100 Subject: [PATCH 02/16] chore(ci): rename cd workflow to create-or-update-release --- .github/workflows/{cd.yml => create-or-update-release.yml} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename .github/workflows/{cd.yml => create-or-update-release.yml} (98%) diff --git a/.github/workflows/cd.yml b/.github/workflows/create-or-update-release.yml similarity index 98% rename from .github/workflows/cd.yml rename to .github/workflows/create-or-update-release.yml index 4c5f65bc2..bb6d71bf9 100644 --- a/.github/workflows/cd.yml +++ b/.github/workflows/create-or-update-release.yml @@ -1,4 +1,4 @@ -name: CD +name: create-or-update-new-release on: push: From f80b3b1164f9d084398b645d193c401c71c35820 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 08:52:12 +0100 Subject: [PATCH 03/16] chore(ci): move release-please job file to dedicated jobs directory This will allow us to to mix up workflows and the jobs they are using internally. --- .github/{workflows/release.yml => jobs/release-please.yml} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename .github/{workflows/release.yml => jobs/release-please.yml} (100%) diff --git a/.github/workflows/release.yml b/.github/jobs/release-please.yml similarity index 100% rename from .github/workflows/release.yml rename to .github/jobs/release-please.yml From ffe1a5f30bb8bae624b5666da8bb6701c3f3cbca Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 08:55:15 +0100 Subject: [PATCH 04/16] chore(ci): rename ci to explicit continuous-integration workflow --- .github/workflows/{ci.yml => continuous-integration.yml} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename .github/workflows/{ci.yml => continuous-integration.yml} (100%) diff --git a/.github/workflows/ci.yml b/.github/workflows/continuous-integration.yml similarity index 100% rename from .github/workflows/ci.yml rename to .github/workflows/continuous-integration.yml From 783831b7dc12455004afd84e33f7629b54a10cbd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 08:56:55 +0100 Subject: [PATCH 05/16] chore(ci): rename preview to explicit create-preview-release.yml workflow --- .github/workflows/{preview.yml => create-preview-release.yml} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename .github/workflows/{preview.yml => create-preview-release.yml} (100%) diff --git a/.github/workflows/preview.yml b/.github/workflows/create-preview-release.yml similarity index 100% rename from .github/workflows/preview.yml rename to .github/workflows/create-preview-release.yml From 5b846be3c976898afc3a8802b1cd84fc3ab196cf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 09:00:10 +0100 Subject: [PATCH 06/16] chore(ci): move all jobs (not workflows) to dedicated directory Again to avoid confusion between workflows, and the jobs that are used by them --- .../workflows/{build.yml => job-build.yml} | 0 .../workflows/{cache.yml => job-cache.yml} | 0 .../workflows/{label.yml => job-label.yml} | 0 .github/workflows/{lint.yml => job-lint.yml} | 0 .github/workflows/{npm.yml => job-npm.yml} | 0 .../{playwright.yml => job-playwright.yml} | 0 .../job-release-please.yml} | 0 .github/workflows/{scan.yml => job-scan.yml} | 0 ...-component.yml => job-tests-component.yml} | 0 ...{tests-deploy.yml => job-tests-deploy.yml} | 0 .../{tests-e2e.yml => job-tests-e2e.yml} | 0 .../{tests-unit.yml => job-tests-unit.yml} | 0 ...ml => workflow-continuous-integration.yml} | 20 +++++++++---------- ... => workflow-create-or-update-release.yml} | 8 ++++---- ...ml => workflow-create-preview-release.yml} | 0 15 files changed, 14 insertions(+), 14 deletions(-) rename .github/workflows/{build.yml => job-build.yml} (100%) rename .github/workflows/{cache.yml => job-cache.yml} (100%) rename .github/workflows/{label.yml => job-label.yml} (100%) rename .github/workflows/{lint.yml => job-lint.yml} (100%) rename .github/workflows/{npm.yml => job-npm.yml} (100%) rename .github/workflows/{playwright.yml => job-playwright.yml} (100%) rename .github/{jobs/release-please.yml => workflows/job-release-please.yml} (100%) rename .github/workflows/{scan.yml => job-scan.yml} (100%) rename .github/workflows/{tests-component.yml => job-tests-component.yml} (100%) rename .github/workflows/{tests-deploy.yml => job-tests-deploy.yml} (100%) rename .github/workflows/{tests-e2e.yml => job-tests-e2e.yml} (100%) rename .github/workflows/{tests-unit.yml => job-tests-unit.yml} (100%) rename .github/workflows/{continuous-integration.yml => workflow-continuous-integration.yml} (92%) rename .github/workflows/{create-or-update-release.yml => workflow-create-or-update-release.yml} (94%) rename .github/workflows/{create-preview-release.yml => workflow-create-preview-release.yml} (100%) diff --git a/.github/workflows/build.yml b/.github/workflows/job-build.yml similarity index 100% rename from .github/workflows/build.yml rename to .github/workflows/job-build.yml diff --git a/.github/workflows/cache.yml b/.github/workflows/job-cache.yml similarity index 100% rename from .github/workflows/cache.yml rename to .github/workflows/job-cache.yml diff --git a/.github/workflows/label.yml b/.github/workflows/job-label.yml similarity index 100% rename from .github/workflows/label.yml rename to .github/workflows/job-label.yml diff --git a/.github/workflows/lint.yml b/.github/workflows/job-lint.yml similarity index 100% rename from .github/workflows/lint.yml rename to .github/workflows/job-lint.yml diff --git a/.github/workflows/npm.yml b/.github/workflows/job-npm.yml similarity index 100% rename from .github/workflows/npm.yml rename to .github/workflows/job-npm.yml diff --git a/.github/workflows/playwright.yml b/.github/workflows/job-playwright.yml similarity index 100% rename from .github/workflows/playwright.yml rename to .github/workflows/job-playwright.yml diff --git a/.github/jobs/release-please.yml b/.github/workflows/job-release-please.yml similarity index 100% rename from .github/jobs/release-please.yml rename to .github/workflows/job-release-please.yml diff --git a/.github/workflows/scan.yml b/.github/workflows/job-scan.yml similarity index 100% rename from .github/workflows/scan.yml rename to .github/workflows/job-scan.yml diff --git a/.github/workflows/tests-component.yml b/.github/workflows/job-tests-component.yml similarity index 100% rename from .github/workflows/tests-component.yml rename to .github/workflows/job-tests-component.yml diff --git a/.github/workflows/tests-deploy.yml b/.github/workflows/job-tests-deploy.yml similarity index 100% rename from .github/workflows/tests-deploy.yml rename to .github/workflows/job-tests-deploy.yml diff --git a/.github/workflows/tests-e2e.yml b/.github/workflows/job-tests-e2e.yml similarity index 100% rename from .github/workflows/tests-e2e.yml rename to .github/workflows/job-tests-e2e.yml diff --git a/.github/workflows/tests-unit.yml b/.github/workflows/job-tests-unit.yml similarity index 100% rename from .github/workflows/tests-unit.yml rename to .github/workflows/job-tests-unit.yml diff --git a/.github/workflows/continuous-integration.yml b/.github/workflows/workflow-continuous-integration.yml similarity index 92% rename from .github/workflows/continuous-integration.yml rename to .github/workflows/workflow-continuous-integration.yml index a9cad426b..d872d8042 100644 --- a/.github/workflows/continuous-integration.yml +++ b/.github/workflows/workflow-continuous-integration.yml @@ -63,7 +63,7 @@ jobs: run: echo "Exposing env vars" npm-check: - uses: ./.github/workflows/npm.yml + uses: ./.github/workflows/job-npm.yml if: ${{ github.base_ref == 'main' && needs.path-filter.outputs.packages == 'true' }} needs: - path-filter @@ -78,14 +78,14 @@ jobs: NPM_TOKEN: ${{ secrets.NPM_TOKEN }} lint: - uses: ./.github/workflows/lint.yml + uses: ./.github/workflows/job-lint.yml needs: - expose-vars with: NODE_VERSION: ${{ needs.expose-vars.outputs.NODE_VERSION }} unit-tests: - uses: ./.github/workflows/tests-unit.yml + uses: ./.github/workflows/job-tests-unit.yml if: ${{ needs.path-filter.outputs.apps == 'true' || needs.path-filter.outputs.packages == 'true' || needs.path-filter.outputs.ci == 'true' }} needs: - path-filter @@ -98,7 +98,7 @@ jobs: SONAR_PROJECT_KEY: "${{ secrets.SONAR_PROJECT_KEY }}" component-tests: - uses: ./.github/workflows/tests-component.yml + uses: ./.github/workflows/job-tests-component.yml if: ${{ needs.path-filter.outputs.apps == 'true' || needs.path-filter.outputs.packages == 'true' || needs.path-filter.outputs.ci == 'true' }} needs: - path-filter @@ -108,7 +108,7 @@ jobs: BROWSERS: "${{ github.base_ref == 'main' && 'chrome,firefox' || 'firefox' }}" build: - uses: ./.github/workflows/build.yml + uses: ./.github/workflows/job-build.yml needs: - expose-vars with: @@ -123,7 +123,7 @@ jobs: ARGOCD_TOKEN: ${{ secrets.ARGOCD_TOKEN }} build-label: - uses: ./.github/workflows/label.yml + uses: ./.github/workflows/job-label.yml needs: - expose-vars - build @@ -131,7 +131,7 @@ jobs: CONF_PATH: ./.github/labeler/build.yml playwright-tests: - uses: ./.github/workflows/playwright.yml + uses: ./.github/workflows/job-playwright.yml if: ${{ needs.path-filter.outputs.apps == 'true' || needs.path-filter.outputs.packages == 'true' || needs.path-filter.outputs.ci == 'true' || needs.path-filter.outputs.e2e == 'true' }} needs: - path-filter @@ -142,7 +142,7 @@ jobs: TAG: pr-${{ github.event.pull_request.number || github.event.number }} cypress-tests: - uses: ./.github/workflows/tests-e2e.yml + uses: ./.github/workflows/job-tests-e2e.yml if: ${{ needs.path-filter.outputs.apps == 'true' || needs.path-filter.outputs.packages == 'true' || needs.path-filter.outputs.ci == 'true' || needs.path-filter.outputs.e2e == 'true' }} needs: - playwright-tests @@ -155,7 +155,7 @@ jobs: BROWSERS: "${{ github.base_ref == 'main' && 'chrome,firefox' || 'firefox' }}" deploy-tests: - uses: ./.github/workflows/tests-deploy.yml + uses: ./.github/workflows/job-tests-deploy.yml if: ${{ (needs.path-filter.outputs.apps != 'true' && needs.path-filter.outputs.packages != 'true' && needs.path-filter.outputs.ci != 'true') || (!github.event.pull_request.draft && github.base_ref == 'main') }} needs: - path-filter @@ -165,7 +165,7 @@ jobs: TAG: pr-${{ github.event.pull_request.number || github.event.number }} scan-vuln: - uses: ./.github/workflows/scan.yml + uses: ./.github/workflows/job-scan.yml needs: - expose-vars - build diff --git a/.github/workflows/create-or-update-release.yml b/.github/workflows/workflow-create-or-update-release.yml similarity index 94% rename from .github/workflows/create-or-update-release.yml rename to .github/workflows/workflow-create-or-update-release.yml index bb6d71bf9..8a546f590 100644 --- a/.github/workflows/create-or-update-release.yml +++ b/.github/workflows/workflow-create-or-update-release.yml @@ -29,10 +29,10 @@ jobs: run: echo "Exposing env vars" release: - uses: ./.github/workflows/release.yml + uses: ./.github/workflows/job-release-please.yml build-amd64: - uses: ./.github/workflows/build.yml + uses: ./.github/workflows/job-build.yml if: ${{ needs.release.outputs.release-created == 'true' }} needs: - expose-vars @@ -49,7 +49,7 @@ jobs: USE_QEMU: ${{ needs.expose-vars.outputs.USE_QEMU == 'true' }} build-arm64: - uses: ./.github/workflows/build.yml + uses: ./.github/workflows/job-build.yml if: ${{ needs.release.outputs.release-created == 'true' }} needs: - expose-vars @@ -66,7 +66,7 @@ jobs: USE_QEMU: ${{ needs.expose-vars.outputs.USE_QEMU == 'true' }} npm-publish: - uses: ./.github/workflows/npm.yml + uses: ./.github/workflows/job-npm.yml if: ${{ needs.release.outputs.release-created == 'true' }} needs: - expose-vars diff --git a/.github/workflows/create-preview-release.yml b/.github/workflows/workflow-create-preview-release.yml similarity index 100% rename from .github/workflows/create-preview-release.yml rename to .github/workflows/workflow-create-preview-release.yml From 4d8c6cf67c9bf16349be7c938c54c5365fd08e7f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 09:24:25 +0100 Subject: [PATCH 07/16] chore(doc): update main README to fix/update how releases are performed --- README.md | 29 +++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 9172218f3..def632a4d 100644 --- a/README.md +++ b/README.md @@ -399,15 +399,17 @@ La gestion des dépendances est effectuée à l'aide de [pnpm](https://pnpm.io/) └── README.md ``` -# Workflow Git +# Organisation avec Git -Une PR doit être faite à partir de la branche `main` à jour (utiliser `rebase` si besoin) avant la demande de fusion (PR). Les PR sont mergées dans `main`. +Une requête de fusion ("merge request") doit être faite avec la branche `main` comme destination. + +La branche de base **doit** être à jour avec `origin/main` (utiliser `git pull origin/main && git rebase origin/main` ou l'option de rebasage dans l'interface Web si besoin) avant la demande de fusion (MR). ## Conventions de nommage Cf. [Conventions - MIOM Fabrique Numérique](https://docs.fabrique-numerique.fr/conventions/nommage.html). -Les commits doivent suivre la spécification des [Commits Conventionnels](https://www.conventionalcommits.org/en/v1.0.0/). Cette norme est utilisée pour construire la release, voir ci-après. +Les commits doivent suivre la spécification des [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/). Cette norme est utilisée pour construire la nouvelle version, voir ci-après. Il est possible d'ajouter l'[extension VSCode](https://github.com/vivaxy/vscode-conventional-commits) pour faciliter la création des commits. @@ -415,18 +417,25 @@ Il est possible d'ajouter l'[extension VSCode](https://github.com/vivaxy/vscode- ## Gestion des versions -Le dépôt utilise [Release Please](https://github.com/googleapis/release-please-action) pour automatiquement générer les tags Git ainsi que les releases GitHub. À chaque fois que du code est poussé dans la branche `main`, une pull request est créée en analysant les messages de commits pour déterminer le numéro de version à créer. +### Versionnement de Console + +Le flux de travail qui créé les nouvelles versions s'intitule `create-or-update-release` et est déclenché à chaque nouveau commit sur `main` (soit lorsqu'on fusionne une requête de fusion, soit un commit poussé en outrepassant l'interdiction de pousser sur `main`). + +Le flux de travail utilise [release-please-action](https://github.com/googleapis/release-please-action) pour automatiquement générer les tags Git ainsi que les nouvelles versions sur GitHub. À chaque fois que du code est poussé dans la branche `main`, une requête de fusion de version est créée en analysant les messages de commits pour déterminer le numéro de version à créer (patch/mineur/majeur). Si une requête de fusion de nouvelle version existe déjà, elle est mise à jour afin de refléter les nouveaux changements ajoutés à la future nouvelle version. + +Les types de commits qui déclenchent une nouvelle version (ou mettent à jour la MR de la prochaine version) sont décrit dans la configuration de release-please, [`./release-please-config.json`](./release-please-config.json) + +À chaque fois qu'une requête de fusion de version est fusionnée, les images de conteneur des applications (`client`, `server`, etc.) sont alors créées et hébergées dans la [registry Github associée au dépôt](https://github.com/orgs/cloud-pi-native/packages?repo_name=console). -À chaque fois qu'une pull request de release est fusionnée, les images de conteneur du serveur et du client sont créées et hébergées dans la [registry Github associée au dépôt](https://github.com/orgs/cloud-pi-native/packages?repo_name=console). +### Versionnement du chart Helm `dso-console` -### Versioning du chart dso-console +Le déploiement de `console` se fait préférablement à l'aide de son chart Helm, nommé [`dso-console`](https://github.com/cloud-pi-native/helm-charts/tree/main/charts/dso-console). -Les images de conteneurs peuvent être déployées via le Helm Chart [dso-console](https://github.com/cloud-pi-native/helm-charts/tree/main/charts/dso-console). -La dernière étape du pipeline de release automatise la création d'une version Helm pour la mise à jour de la version des images. Exemple : https://github.com/cloud-pi-native/helm-charts/pull/204. +La dernière étape du flux de travail de création de nouvelles versions (cf. section ci-dessus) est la création automatique d'une requête de fusion dans le dépôt `helm-charts` pour la mise à jour du chart Helm `dso-console`. Une fusion manuelle sur ce dépôt est alors nécessaire pour déclencher la publication de la nouvelle version du chart Helm (embarquant donc la nouvelle version de `console`). Exemple d'une telle requête de fusion de nouvelle version du chart Helm : https://github.com/cloud-pi-native/helm-charts/pull/204. -### Versioning des modules +### Versionnement des modules NPM -Pour publier les versions des modules npm du dépôt un [pipeline](https://github.com/cloud-pi-native/console/actions/workflows/npm.yml) est disponible dans les GitHub Actions, il analysera les numéros de version présents dans les différents fichiers `package.json` pour déterminer si une nouvelle version du module doit être créée et publiée. +La publication des nouvelles versions de modules npm du dépôt est automatique et est inclus dans le flux de travail de création d'une nouvelle version. Il analyse les numéros de version présents dans les différents fichiers `package.json` pour déterminer si une nouvelle version du module doit être créée et publiée. > Il est possible de créer une version de pré-release d'un module npm en modifiant la clé `publishConfig.tag` dans le `package.json` avec par exemple `beta` pour générer une version beta. From 8b58f7f1bf5a846d3e4adf9eaac1bfd39f29d4c6 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 10:35:28 +0100 Subject: [PATCH 08/16] chore(server-nestjs): add application to the version-bumpable ones --- ci/matrix-npm.json | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ci/matrix-npm.json b/ci/matrix-npm.json index 9992e4093..940f7c7e2 100644 --- a/ci/matrix-npm.json +++ b/ci/matrix-npm.json @@ -4,6 +4,10 @@ "name": "@cpn-console/server", "path": "./apps/server" }, + { + "name": "@cpn-console/server-nestjs", + "path": "./apps/server-nestjs" + }, { "name": "@cpn-console/client", "path": "./apps/client" From 416b0d1b0086970c1a246d0a40a6d974312b03f5 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 10:35:59 +0100 Subject: [PATCH 09/16] feat(ci): change release-please config and job to allow for hotfixes --- .github/workflows/job-release-please.yml | 13 +++++++++++-- release-please-config.json | 5 +++++ 2 files changed, 16 insertions(+), 2 deletions(-) diff --git a/.github/workflows/job-release-please.yml b/.github/workflows/job-release-please.yml index 6f90b7b14..b3a5b19ec 100644 --- a/.github/workflows/job-release-please.yml +++ b/.github/workflows/job-release-please.yml @@ -29,11 +29,20 @@ jobs: - name: Checks-out repository uses: actions/checkout@v4 - - name: Pre release new version + - name: Update release-please config for hotfix branches + if: startsWith(github.ref_name, 'hotfix/') + run: | + # Update versioning to always-bump-patch for hotfix branches + jq '.versioning = "always-bump-patch"' release-please-config.json > tmp.json && mv tmp.json release-please-config.json + echo "Updated release-please-config.json versioning to always-bump-patch" + shell: bash + + - name: Create merge request for new release uses: googleapis/release-please-action@v4 id: release with: - target-branch: main + config-file: release-please-config.json + target-branch: ${{ github.ref_name }} token: ${{ secrets.GITHUB_TOKEN }} - name: Edit packages versions diff --git a/release-please-config.json b/release-please-config.json index 698bc932a..aeb0fa2e6 100644 --- a/release-please-config.json +++ b/release-please-config.json @@ -1,4 +1,9 @@ { + "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", + "versioning": "default", + "pull-request-title-pattern": "chore${scope}: Release${component} v${version}", + "release-type": "node", + "changelog-type": "default", "packages": { ".": { "package-name": "console", From 454fc6f1b2983c184424ff0926cb56f0b3e60b69 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 14:19:21 +0100 Subject: [PATCH 10/16] chore(ci): rename workflows --- .github/workflows/workflow-continuous-integration.yml | 2 +- .github/workflows/workflow-create-or-update-release.yml | 2 +- .github/workflows/workflow-create-preview-release.yml | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/.github/workflows/workflow-continuous-integration.yml b/.github/workflows/workflow-continuous-integration.yml index d872d8042..54b70f7c4 100644 --- a/.github/workflows/workflow-continuous-integration.yml +++ b/.github/workflows/workflow-continuous-integration.yml @@ -1,4 +1,4 @@ -name: CI +name: Continuous Integration on: pull_request: diff --git a/.github/workflows/workflow-create-or-update-release.yml b/.github/workflows/workflow-create-or-update-release.yml index 8a546f590..66917d595 100644 --- a/.github/workflows/workflow-create-or-update-release.yml +++ b/.github/workflows/workflow-create-or-update-release.yml @@ -1,4 +1,4 @@ -name: create-or-update-new-release +name: Create/update next release on: push: diff --git a/.github/workflows/workflow-create-preview-release.yml b/.github/workflows/workflow-create-preview-release.yml index 446d10e82..d324550b9 100644 --- a/.github/workflows/workflow-create-preview-release.yml +++ b/.github/workflows/workflow-create-preview-release.yml @@ -1,4 +1,4 @@ -name: Preview comment +name: Add preview comment on: pull_request: From baa7196e29a32112ccdd67f34f6837fee66fd08a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 14:53:23 +0100 Subject: [PATCH 11/16] feat(release-please): allow chore, docs, and other commit types to trigger new releases --- release-please-config.json | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/release-please-config.json b/release-please-config.json index aeb0fa2e6..e354ab14a 100644 --- a/release-please-config.json +++ b/release-please-config.json @@ -4,6 +4,16 @@ "pull-request-title-pattern": "chore${scope}: Release${component} v${version}", "release-type": "node", "changelog-type": "default", + "changelog-sections": [ + { "type": "feat", "hidden": false, "section": "Features" }, + { "type": "feature", "hidden": false, "section": "Features" }, + { "type": "fix", "hidden": false, "section": "Bug Fixes" }, + { "type": "chore", "hidden": false, "section": "Miscellaneous Chores" }, + { "type": "build", "hidden": false, "section": "Miscellaneous Chores" }, + { "type": "docs", "hidden": false, "section": "Docs" }, + { "type": "refactor", "hidden": false, "section": "Refactoring" }, + { "type": "revert", "hidden": false, "section": "Reverted commits" } + ], "packages": { ".": { "package-name": "console", From 550a265109171a742f825329df2bcdd5149c8121 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 16:00:56 +0100 Subject: [PATCH 12/16] chore(ci): rename create-preview-comment to better explicit its purpose --- ...te-preview-release.yml => workflow-create-preview-comment.yml} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename .github/workflows/{workflow-create-preview-release.yml => workflow-create-preview-comment.yml} (100%) diff --git a/.github/workflows/workflow-create-preview-release.yml b/.github/workflows/workflow-create-preview-comment.yml similarity index 100% rename from .github/workflows/workflow-create-preview-release.yml rename to .github/workflows/workflow-create-preview-comment.yml From 16241427d706a88ccf53dbc78d49d901469a8ccf Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 16:01:30 +0100 Subject: [PATCH 13/16] chore(ci): avoid checking out the repository for create-preview-comment --- .github/workflows/workflow-create-preview-comment.yml | 3 --- 1 file changed, 3 deletions(-) diff --git a/.github/workflows/workflow-create-preview-comment.yml b/.github/workflows/workflow-create-preview-comment.yml index d324550b9..0f9e6bdc8 100644 --- a/.github/workflows/workflow-create-preview-comment.yml +++ b/.github/workflows/workflow-create-preview-comment.yml @@ -13,9 +13,6 @@ jobs: if: contains(github.event.pull_request.labels.*.name, 'preview') runs-on: ubuntu-latest steps: - - name: Checks-out repository - uses: actions/checkout@v4 - - name: Generate app url id: generate-url run: | From 84a47398d2771f99178e229503e73302f779add8 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Tue, 27 Jan 2026 16:17:10 +0100 Subject: [PATCH 14/16] docs(README): split release section into its own RELEASE.md file --- README.md | 22 +--------------------- RELEASE.md | 30 ++++++++++++++++++++++++++++++ 2 files changed, 31 insertions(+), 21 deletions(-) create mode 100644 RELEASE.md diff --git a/README.md b/README.md index def632a4d..958c93acb 100644 --- a/README.md +++ b/README.md @@ -417,27 +417,7 @@ Il est possible d'ajouter l'[extension VSCode](https://github.com/vivaxy/vscode- ## Gestion des versions -### Versionnement de Console - -Le flux de travail qui créé les nouvelles versions s'intitule `create-or-update-release` et est déclenché à chaque nouveau commit sur `main` (soit lorsqu'on fusionne une requête de fusion, soit un commit poussé en outrepassant l'interdiction de pousser sur `main`). - -Le flux de travail utilise [release-please-action](https://github.com/googleapis/release-please-action) pour automatiquement générer les tags Git ainsi que les nouvelles versions sur GitHub. À chaque fois que du code est poussé dans la branche `main`, une requête de fusion de version est créée en analysant les messages de commits pour déterminer le numéro de version à créer (patch/mineur/majeur). Si une requête de fusion de nouvelle version existe déjà, elle est mise à jour afin de refléter les nouveaux changements ajoutés à la future nouvelle version. - -Les types de commits qui déclenchent une nouvelle version (ou mettent à jour la MR de la prochaine version) sont décrit dans la configuration de release-please, [`./release-please-config.json`](./release-please-config.json) - -À chaque fois qu'une requête de fusion de version est fusionnée, les images de conteneur des applications (`client`, `server`, etc.) sont alors créées et hébergées dans la [registry Github associée au dépôt](https://github.com/orgs/cloud-pi-native/packages?repo_name=console). - -### Versionnement du chart Helm `dso-console` - -Le déploiement de `console` se fait préférablement à l'aide de son chart Helm, nommé [`dso-console`](https://github.com/cloud-pi-native/helm-charts/tree/main/charts/dso-console). - -La dernière étape du flux de travail de création de nouvelles versions (cf. section ci-dessus) est la création automatique d'une requête de fusion dans le dépôt `helm-charts` pour la mise à jour du chart Helm `dso-console`. Une fusion manuelle sur ce dépôt est alors nécessaire pour déclencher la publication de la nouvelle version du chart Helm (embarquant donc la nouvelle version de `console`). Exemple d'une telle requête de fusion de nouvelle version du chart Helm : https://github.com/cloud-pi-native/helm-charts/pull/204. - -### Versionnement des modules NPM - -La publication des nouvelles versions de modules npm du dépôt est automatique et est inclus dans le flux de travail de création d'une nouvelle version. Il analyse les numéros de version présents dans les différents fichiers `package.json` pour déterminer si une nouvelle version du module doit être créée et publiée. - -> Il est possible de créer une version de pré-release d'un module npm en modifiant la clé `publishConfig.tag` dans le `package.json` avec par exemple `beta` pour générer une version beta. +Se référer à [./RELEASE.md](./RELEASE.md). ## Gestion des dépendances diff --git a/RELEASE.md b/RELEASE.md new file mode 100644 index 000000000..e6bdc102a --- /dev/null +++ b/RELEASE.md @@ -0,0 +1,30 @@ +# Gestion des versions + +Ce document décrit comment est géré le versionnement de `console`, c'est-à-dire les différents aspects qui nous permettent de : + +- Préparer la création d'une nouvelle version de `console` au fur et à mesure des ajouts +- Créer effectivement la nouvelle version +- Mettre à jour le chart Helm concerné +- Publier les nouvelles versions de modules NPM concernés + +## Versionnement de Console + +Le flux de travail qui créé les nouvelles versions s'intitule `create-or-update-release` et est déclenché à chaque nouveau commit sur `main` (soit lorsqu'on fusionne une requête de fusion, soit un commit poussé en outrepassant l'interdiction de pousser sur `main`). + +Le flux de travail utilise [release-please-action](https://github.com/googleapis/release-please-action) pour automatiquement générer les tags Git ainsi que les nouvelles versions sur GitHub. À chaque fois que du code est poussé dans la branche `main`, une requête de fusion de version est créée en analysant les messages de commits pour déterminer le numéro de version à créer (patch/mineur/majeur). Si une requête de fusion de nouvelle version existe déjà, elle est mise à jour afin de refléter les nouveaux changements ajoutés à la future nouvelle version. + +Les types de commits qui déclenchent une nouvelle version (ou mettent à jour la MR de la prochaine version) sont décrit dans la configuration de release-please, [`./release-please-config.json`](./release-please-config.json) + +À chaque fois qu'une requête de fusion de version est fusionnée, les images de conteneur des applications (`client`, `server`, etc.) sont alors créées et hébergées dans la [registry Github associée au dépôt](https://github.com/orgs/cloud-pi-native/packages?repo_name=console). + +## Versionnement du chart Helm `dso-console` + +Le déploiement de `console` se fait préférablement à l'aide de son chart Helm, nommé [`dso-console`](https://github.com/cloud-pi-native/helm-charts/tree/main/charts/dso-console). + +La dernière étape du flux de travail de création de nouvelles versions (cf. section ci-dessus) est la création automatique d'une requête de fusion dans le dépôt `helm-charts` pour la mise à jour du chart Helm `dso-console`. Une fusion manuelle sur ce dépôt est alors nécessaire pour déclencher la publication de la nouvelle version du chart Helm (embarquant donc la nouvelle version de `console`). Exemple d'une telle requête de fusion de nouvelle version du chart Helm : https://github.com/cloud-pi-native/helm-charts/pull/204. + +## Versionnement des modules NPM + +La publication des nouvelles versions de modules npm du dépôt est automatique et est inclus dans le flux de travail de création d'une nouvelle version. Il analyse les numéros de version présents dans les différents fichiers `package.json` pour déterminer si une nouvelle version du module doit être créée et publiée. + +> Il est possible de créer une version de pré-release d'un module npm en modifiant la clé `publishConfig.tag` dans le `package.json` avec par exemple `beta` pour générer une version beta. From 11d01bc6afae29b1a49c0447dc6be82d06f5784e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Thu, 29 Jan 2026 11:14:28 +0100 Subject: [PATCH 15/16] docs(RELEASE): document hotfixes creation workflow --- RELEASE.md | 17 +++++++++++++++++ 1 file changed, 17 insertions(+) diff --git a/RELEASE.md b/RELEASE.md index e6bdc102a..8fcfe9470 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -28,3 +28,20 @@ La dernière étape du flux de travail de création de nouvelles versions (cf. s La publication des nouvelles versions de modules npm du dépôt est automatique et est inclus dans le flux de travail de création d'une nouvelle version. Il analyse les numéros de version présents dans les différents fichiers `package.json` pour déterminer si une nouvelle version du module doit être créée et publiée. > Il est possible de créer une version de pré-release d'un module npm en modifiant la clé `publishConfig.tag` dans le `package.json` avec par exemple `beta` pour générer une version beta. + +## Hotfixes + +Autant que faire se peut il vaut mieux privilégier le "Fix Forward" avec de nouvelles releases. + +Ceci étant dit, il arrivera, hélas, qu'un hotfix soit nécessaire sur une version livrée. + +Voici donc le processus compatible avec l'utilisation de `release-please`: + +- Se placer localement sur le tag de la version concernée: `$ git checkout v1.2.3` (`v1.2.3` est ici la version à hotfixer) +- En tirer une branche dédiée au hotfix: `$ git checkout -b hotfix/my-urgent-hotfix-for-v1.2.3` (Note: Il n'est pas nécessaire de spécifier la version dans le nom de la branche, mais ça peut aider à la lecture et ainsi confirmer la version concernée) +- Faire les modifications nécessaires, committer, etc. +- Pousser la nouvelle branche sur le dépôt Github +- Une fois la nouvelle branche poussée, `release-please` va être déclenché par le flux de travail Github `create-or-update-release` afin de créer une requête de fusion pour la nouvelle version hotfixée (avec comme cible la branche de hotfix). Il est d'ailleurs à noter que dans le cas d'un hotfix **on ne fait qu'une montée du "patch"** quelque soit les commits (donc même un `feat!` ne fera pas de montée majeure) +- Valider la MR de version hotfixée (créée donc par `release-please`) à l'aide du flux de travail Github `Continuous Integration` +- Une fois la MR de version hotfixée validée et fusionnée, la nouvelle version est créée et, comme pour les versions traditionnelles, une requête de fusion est crée dans le dépôt `helm-charts` pour avoir là aussi une version hotfixée (mais, pour le chart Helm, c'est considéré comme une version classique) +- Il faudra ensuite faire des picorages (`git cherry-pick`) ou une MR de la branche de hotfix vers `main` afin d'intégrer le ou les commits de hotfix dans la prochaine version officielle From b157e947028097fa1c191d2970805d06d8d3ec9a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?St=C3=A9phane=20TR=C3=89BEL=20=28Perso=29?= Date: Thu, 29 Jan 2026 16:13:47 +0100 Subject: [PATCH 16/16] docs(RELEASE): add mermaidjs schema --- RELEASE.md | 47 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) diff --git a/RELEASE.md b/RELEASE.md index 8fcfe9470..5f205a59d 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -7,6 +7,53 @@ Ce document décrit comment est géré le versionnement de `console`, c'est-à-d - Mettre à jour le chart Helm concerné - Publier les nouvelles versions de modules NPM concernés +## Schéma récapitulatif + +Les sections suivantes vont expliciter ce schéma: + +```mermaid +gitGraph + commit id: "…previous commits" + commit id: "Add basic features" + + branch release-please-main + checkout release-please-main + commit id:"bump to v1.2.0" tag: "v1.2.0" + + checkout main + merge release-please-main + checkout release-please-main + branch "hotfix/v1.2.0" + commit id: "Fix stuff" + branch release-please-hotfix_v1.2.3 + commit id:"bump to v1.2.1" tag: "v1.2.1" + checkout "hotfix/v1.2.0" + merge release-please-hotfix_v1.2.3 + + checkout main + commit id: "Add features" + checkout release-please-main + commit id:"bump to v1.3.0" tag: "v1.3.0" + merge main + commit id:"bump to v1.3.0" tag: "v1.3.0" + checkout main + commit id: "More features" + checkout release-please-main + merge main + commit id:"bump to v1.3.0 (recreated)" tag: "v1.3.0 (recreated)" + checkout main + merge release-please-main + + checkout main + merge "hotfix/v1.2.0" + checkout release-please-main + commit id:"bump to v1.4.0" tag: "v1.4.0" + merge main + commit id:"bump to v1.4.0" tag: "v1.4.0" + checkout main + merge release-please-main +``` + ## Versionnement de Console Le flux de travail qui créé les nouvelles versions s'intitule `create-or-update-release` et est déclenché à chaque nouveau commit sur `main` (soit lorsqu'on fusionne une requête de fusion, soit un commit poussé en outrepassant l'interdiction de pousser sur `main`).