diff --git a/.github/hotfix-release-please-config.json b/.github/hotfix-release-please-config.json index 5be3afede4..27875528e6 100644 --- a/.github/hotfix-release-please-config.json +++ b/.github/hotfix-release-please-config.json @@ -1,6 +1,7 @@ { "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", "release-type": "node", + "skip-changelog": true, "versioning": "always-bump-patch", "prerelease": false, diff --git a/.github/prerelease-please-config.json b/.github/prerelease-please-config.json index e1151dcbd5..a8a3097a5d 100644 --- a/.github/prerelease-please-config.json +++ b/.github/prerelease-please-config.json @@ -1,6 +1,7 @@ { "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", "release-type": "node", + "skip-changelog": true, "versioning": "prerelease", "prerelease": true, diff --git a/.github/release-please-config.json b/.github/release-please-config.json index 2eb752e199..0a989d32eb 100644 --- a/.github/release-please-config.json +++ b/.github/release-please-config.json @@ -1,6 +1,7 @@ { "$schema": "https://raw.githubusercontent.com/googleapis/release-please/main/schemas/config.json", "release-type": "node", + "skip-changelog": true, "versioning": "always-bump-minor", "prerelease": false, diff --git a/.github/workflows/job-release-please-hotfixes.yml b/.github/workflows/job-release-please-hotfixes.yml index c085ddac2a..26aad5dcb8 100644 --- a/.github/workflows/job-release-please-hotfixes.yml +++ b/.github/workflows/job-release-please-hotfixes.yml @@ -56,8 +56,7 @@ jobs: # - Upsert a hotfix release MR after a commit has been added to the target branch that triggerd this workflow (e.g: `hotfix/my-urgent-hotfix`) # - Create a hotfix release, if this workflow has been triggered by the related MR merge (release-please-hotfit -> hotfix/my-urgent-hotfix) # - In both cases "Create" means: - # - Updating the CHANGLOG accordingly (with the related commits) - # - Updating the apps package.json versions + # - Updating the release manifest and application package.json versions # - Generating and push the git tag # - Creating the related GitHub Release prepare: diff --git a/.github/workflows/job-release-please.yml b/.github/workflows/job-release-please.yml index 4beb8032e1..fe3608474d 100644 --- a/.github/workflows/job-release-please.yml +++ b/.github/workflows/job-release-please.yml @@ -61,8 +61,7 @@ jobs: # - Create a prerelease (`X.Y.Z-rc`, `X.Y.Z-rc.1`, `X.Y.Z-rc.2`, etc.), if this workflow has been triggered by the related MR merge # - Create a release (`X.Y.Z`), if this workflow has been triggered by the related MR merge # - In both cases "Create" means: - # - Updating the CHANGLOG accordingly (with the related commits) - # - Updating the apps package.json versions + # - Updating the release manifest and application package.json versions # - Generating and push the git tag # - Creating the related GitHub Release prepare: diff --git a/CHANGELOGS/9.27.0.anomalies.md b/CHANGELOGS/9.27.0.anomalies.md new file mode 100644 index 0000000000..77fb2b721c --- /dev/null +++ b/CHANGELOGS/9.27.0.anomalies.md @@ -0,0 +1,25 @@ +# Audit de la Release Note 9.27.0 + +- Plage examinée : `v9.26.2...v9.27.0` (137 commits) +- Milestone : https://github.com/cloud-pi-native/console/milestone/37 +- MR Helm : https://github.com/cloud-pi-native/helm-charts/pull/297 + +## Prévus mais non livrés + +- #2655 : la migration des tests vers MSW n’a pas de PR ni d’implémentation livrée dans la plage examinée. + +## Livrés sans milestone ou avec mauvais milestone + +- #2820 / PR #2820 : correction du rattrapage des rôles système, fusionnée après le tag stable `v9.26.2`, mais rattachée au milestone `9.26.2`. Inclusion exceptionnelle confirmée précédemment et présente dans la source. + +## Rattachements tardifs (travail livré avant la stable précédente) + +- #2778 / PR #2779 : livré le 1er octobre, rattaché au milestone `9.27.0` le 7 octobre. Inclusion exceptionnelle confirmée précédemment et présente dans la source. +- #2792 / PRs #2793 et #2795 : livré avant `v9.26.2`, puis rattaché à `9.27.0` le 7 octobre (après avoir été associé à `10.0.0`). Inclusion exceptionnelle confirmée précédemment et présente dans la source. +- #1672 : milestone `9.27.0` attribué le 11 septembre, avant la livraison ; pas un rattachement tardif. +- #2838 : rattaché au milestone `9.27.0` avant la fusion de la PR #2848 ; inclus comme livraison attribuée. + +## Changements techniques exclus + +- Tests, documentation, skills, templates, refactorings et migrations de routes vers NestJS sans effet utilisateur distinct. +- PR #2814 : backport de migrations sans milestone, fusionné avant `v9.26.2` et déjà présent dans la livraison stable ; exclu. diff --git a/CHANGELOGS/9.27.0.md b/CHANGELOGS/9.27.0.md new file mode 100644 index 0000000000..abf2e9af64 --- /dev/null +++ b/CHANGELOGS/9.27.0.md @@ -0,0 +1,34 @@ +--- +consoleVersion: 9.27.0 +candidateTag: v9.27.0 +appVersion: v9.27.0 +chartVersion: 2.4.47 +milestone: https://github.com/cloud-pi-native/console/milestone/37 +status: published +--- + +# dso-console 9.27.0 + +## Objectif(s) de cette version + +- Fiabiliser les opérations d’administration, de synchronisation et de gestion des projets. +- Renforcer la cohérence des rôles et des synchronisations avec les outils connectés. + +## Changements livrés + +- La branche choisie pour synchroniser un dépôt est mémorisée et proposée lors des synchronisations suivantes. [#1672](https://github.com/cloud-pi-native/console/issues/1672) +- Les administrateurs de la console et des projets peuvent consulter les déploiements selon leurs droits. [#2764](https://github.com/cloud-pi-native/console/issues/2764) +- Une nouvelle demande d’archivage d’un projet déjà archivé est refusée. [#2757](https://github.com/cloud-pi-native/console/issues/2757) +- Les synchronisations Vault réutilisent le secret-id AppRole existant au lieu d’en créer un nouveau à chaque passage. [#2622](https://github.com/cloud-pi-native/console/issues/2622) +- La réconciliation des mounts Vault ne journalise plus le cas nominal comme une erreur. [#2762](https://github.com/cloud-pi-native/console/issues/2762) +- La modification des paramètres système est protégée par le droit d’administration requis. [#2722](https://github.com/cloud-pi-native/console/issues/2722) +- Les changements de rôles d’administration sont propagés à Keycloak et GitLab ; la session et l’écran des rôles reflètent correctement les rôles concernés. [#2204](https://github.com/cloud-pi-native/console/issues/2204) [#2835](https://github.com/cloud-pi-native/console/issues/2835) [#2833](https://github.com/cloud-pi-native/console/issues/2833) +- Le décompte des membres des rôles d’administration fonctionne aussi lorsque des rôles sont portés par des groupes OIDC. [#2781](https://github.com/cloud-pi-native/console/issues/2781) +- La réconciliation SonarQube adopte les entités déjà existantes au lieu d’échouer lors d’une collision de création. [#2778](https://github.com/cloud-pi-native/console/issues/2778) +- Le rôle d’administration « Sécurité Plateforme » est disponible et les groupes GitLab multi-chemins sont correctement reconnus pour les rôles admin et auditor. [#2792](https://github.com/cloud-pi-native/console/issues/2792) +- Les projets existants reçoivent individuellement les rôles système manquants, sans modifier ceux déjà présents. [#2819](https://github.com/cloud-pi-native/console/issues/2819) +- La modification d’un cluster dédié conserve les projets qui lui sont rattachés. [#2838](https://github.com/cloud-pi-native/console/issues/2838) + +## Autres changements + +- L’indicateur de santé identifie correctement GitLab lorsqu’il est indisponible. [PR #2780](https://github.com/cloud-pi-native/console/pull/2780) diff --git a/CHANGELOG.md b/CHANGELOGS/CHANGELOG_ARCHIVE.md similarity index 100% rename from CHANGELOG.md rename to CHANGELOGS/CHANGELOG_ARCHIVE.md diff --git a/README.md b/README.md index e056034066..5eda2efb68 100644 --- a/README.md +++ b/README.md @@ -388,7 +388,7 @@ Il est possible d'ajouter l'[extension VSCode](https://github.com/vivaxy/vscode- ## Gestion des versions -Se référer à [./RELEASE.md](./RELEASE.md). +La gestion des versions, des tags et des releases GitHub est décrite dans [RELEASE.md](./RELEASE.md). Les notes de version validées destinées aux utilisateurs sont stockées dans [`CHANGELOGS/`](./CHANGELOGS/) et préparées avec le skill [`cpn-release-notes`](./.agents/skills/cpn-release-notes/SKILL.md). ## Gestion des dépendances diff --git a/RELEASE.md b/RELEASE.md index 91ba22d4d4..1cfbd85fed 100644 --- a/RELEASE.md +++ b/RELEASE.md @@ -112,7 +112,13 @@ Plus concrètement, le cycle est le suivant : **⚠️NOTE⚠️**: Si jamais, après l'étape `3` (création de la MR pour la version stable) des commits "classiques" sont poussés sur `main` alors **la MR de la version stable sera automatiquement "convertie" en MR de préversion**. Dit autrement: **On ne peut créer une version "stable" qu'à partir d'une préversion**. Tout commit en plus empêche d'avoir une version stable, il faut forcément qu'il y ait ZERO commit après une préversion pour avoir une MR de version stable. -Les différents types de commits (`chore:`, `feat:`, `fix:`, etc.) alimentent les sections du `CHANGELOG.md` selon les deux configurations release-please ci-dessus. +## Notes de version + +`release-please` gère les incréments de version, les requêtes de fusion de release, les tags immuables et les GitHub Releases. Il ne génère pas de fichier `CHANGELOG.md`. + +L’historique généré avant cette bascule est conservé, sans modification, dans [`CHANGELOGS/CHANGELOG_ARCHIVE.md`](./CHANGELOGS/CHANGELOG_ARCHIVE.md). Les notes destinées aux utilisateurs sont préparées manuellement avec le skill [`cpn-release-notes`](./.agents/skills/cpn-release-notes/SKILL.md) : il produit `CHANGELOGS/.md` et son audit non publiable `CHANGELOGS/.anomalies.md`. + +La procédure collecte la version stable cible, le tag candidat, le milestone exact et la MR Helm. Elle réconcilie ces preuves, présente une prévisualisation et n’écrit les fichiers qu’après validation humaine. L’absence de tag, de milestone ou de MR Helm bloque la préparation. Cette bascule n’ajoute ni contrôle CI ni automatisation par agent. Lorsqu'une préversion ou une version stable est créée, les images de conteneur des applications (`client`, `server`, etc.) sont publiées dans la [registry GitHub du dépôt](https://github.com/orgs/cloud-pi-native/packages?repo_name=console) avec le tag complet correspondant. Une version stable met aussi à jour les tags partiels `vX` et `vX.Y` ; ⚠️ Les RC ne touchent **jamais** à ces tags "mouvants". Ils sont là explicitement pour traquer la dernière version stable, majeure ou mineure. @@ -219,12 +225,12 @@ Exemple : corriger la version de production `v9.24.5`. 2. Implémenter et valider le correctif, puis pousser la branche. -3. Vérifier que le workflow `Handle next hotfix` crée une MR `release-please` ciblant `hotfix/urgent-` et proposant exactement `v9.24.6`. En cas de version, branche cible, ou liste de changement ("changelog") inattendus, **ne pas fusionner la MR**. +3. Vérifier que le workflow `Handle next hotfix` crée une MR `release-please` ciblant `hotfix/urgent-` et proposant exactement `v9.24.6`. En cas de version, branche cible ou tag proposé inattendus, **ne pas fusionner la MR**. 4. Fusionner la MR `release-please` après validation. Cela crée le tag et la GitHub Release `v9.24.6`, publie les images OCI taguées `v9.24.6` et déclenche la demande de mise à jour du chart `dso-console` avec `appVersion: 9.24.6`. 5. Déployer le chart mis à jour, puis vérifier que la version déployée est bien `9.24.6`. -6. Créer une MR vers `main` en picorant ("cherry-picking") exclusivement le ou les commits applicatif du correctif d'urgence. Exclure les commits automatiques `release-please`, le `CHANGELOG.md`, les manifestes et les fichiers de version. Le correctif intègre alors normalement le cycle préversion/version stable en cours sur `main`. +6. Créer une MR vers `main` en picorant ("cherry-picking") exclusivement le ou les commits applicatif du correctif d'urgence. Exclure les commits automatiques `release-please`, les manifestes et les fichiers de version. Le correctif intègre alors normalement le cycle préversion/version stable en cours sur `main`. > Une préversion en cours sur `main` reste indépendante d'un correctif d'urgence. Par exemple, un correctif d'urgence `9.24.6` ne modifie ni la cible ni le compteur des RC `9.25.0-rc.*`.