Revoir les pipelines pour permettre des hotfixes #1860
Conversation
StephaneTrebel
force-pushed
the
permettre-les-hotfixes
branch
from
3617fea to
c36a596
Compare
|
🤖 Hey ! The @cpn-console/argocd-plugin (v2.3.0) package already exists on npm but the source code has changed, you should consider updating the package version. The version update warning should be ignored in the case of modifications that do not affect the code once it has been built, such as code formatting, etc... |
StephaneTrebel
force-pushed
the
permettre-les-hotfixes
branch
from
7ade00a to
c91bae7
Compare
|
This pull request sets up GitHub code scanning for this repository. Once the scans have completed and the checks have passed, the analysis results for this pull request branch will appear on this overview. Once you merge this pull request, the 'Security' tab will show more code scanning analysis results (for example, for the default branch). Depending on your configuration and choice of analysis tool, future pull requests will be annotated with code scanning analysis results. For more information about GitHub code scanning, check out the documentation. |
|
🤖 Hey ! The security scan report for the current pull request is available here. |
StephaneTrebel
changed the title
This will allow us to to mix up workflows and the jobs they are using internally.
Again to avoid confusion between workflows, and the jobs that are used by them
…igger new releases
StephaneTrebel
force-pushed
the
permettre-les-hotfixes
branch
from
2165809 to
1624142
Compare
|
imho, la documentation sur le flux de travail, release, conventions; devrait etre au niveau d'un contribution.md ou release.md. Le readme.md doit etre simple et presenter uniquement le "pourquoi" du projet. |
Oui tu as raison, c'est vrai que c'est trop lourd, je vais splitter le README.md sur cette partie 👍 |
|
@StephaneTrebel Est-ce que tu pourrais rajouter une description de comment lancer une hotfix ? |
StephaneTrebel
changed the title
|
|
||
| ## Hotfixes | ||
|
|
||
| Autant que faire se peut il vaut mieux privilégier le "Fix Forward" avec de nouvelles releases. |
There was a problem hiding this comment.
J'ai pas compris ce que tu veux dire :)
There was a problem hiding this comment.
Faire des hotfix doit être la dernière solution envisagée. C'est trop prescriptif, selon toi ?
There was a problem hiding this comment.
Principalement la tournure de phrase que j'ai pas compris.
Apres, les hotfixes devraient etre une partie integrante d'un release. D'ou le branching systematique des releases LTS defini dans l'ADR.
Dans le cas actuellement on aura juste une branche release n-1 pour maintenir la prod. Avec de l'outillage pour backport automatiquement de LTS vers main ou inversement.
There was a problem hiding this comment.
Typiquement les etapes sont:
- campagne de 0 CI fail sur main
- creation d'une branch release-1.0
- tag version v1.0.0-rc.1 -> staging
- tag version v1.0.0 -> production
- pr hotfix sur release-1.0
- ouverture d'une pr backport main si besoin
- tag version v1.0.1 ou v1.0.1-rc.1 si non critique -> production
StephaneTrebel
force-pushed
the
permettre-les-hotfixes
branch
from
a095ad5 to
b157e94
Compare
|
0 New Issues
0 Fixed Issues
0 Accepted Issues
No data about coverage (71.70% Estimated after merge)
Issues liées
Issues numéro: #1845 et #1858
workflows. On ne devrait pas utiliser des noms aussi peu clairs queCDworkflowde ce qui ne l'est pas (lesjobsappelés par les `workflows', par exemple)hotfixavecrelease-pleasesans casser le versionnement existantREADME.mdracine pour détailler/clarifier les changements (et notamment le flux de travail pour les hotfixes)