Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
vidjil
vidjil
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 1,712
    • Issues 1,712
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 87
    • Merge Requests 87
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI / CD
    • Repository
    • Value Stream
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards

Mise à jour terminée. Pour connaître les apports de la version 13.8.4 par rapport à notre ancienne version vous pouvez lire les "Release Notes" suivantes :
https://about.gitlab.com/releases/2021/02/11/security-release-gitlab-13-8-4-released/
https://about.gitlab.com/releases/2021/02/05/gitlab-13-8-3-released/

  • vidjil
  • vidjilvidjil
  • Issues
  • #2158

Closed
Open
Opened Feb 02, 2017 by Mathieu Giraud@magiraudOwner

Mieux gérer les choses à faire avant la prochaine release

Nous avons actuellement un test sur le cpp qui ne passe pas, 88c6e924 lié à #2003.

Ce n'est pas sain d'avoir des tests qui ne passent pas : cela rend difficile le développement d'autres features, et on ne bénéficie pas beaucoup de l'intégration continue. Par définition, notre branche principale doit toujours passer les tests. Et puis une décision à un moment "on doit absolument fixer cela" peut évoluer quelques temps plus tard (je ne parle pas nécessairement de #2003).

Mais c'est fantastique d'identifier des bugs et de faire des tests qui ne vont pas marcher dans un premier temps. Pour les tests should-get, il y a la syntaxe f1 qui permet d'ignorer un tel test, et des choses similaires pour les autres types de tests. Cependant, @mikael-s faisait justement remarquer, il y a quelque temps, qu'on peut oublier de tels tests, d'où 88c6e924 qui casse le build mais qui permet de s'en souvenir.

Proposition de meilleur workflow pour cela, grâce à gitlab : un bug "that should be fixed for the next release" conduit à un test ignoré avec une issue tagguée d'un milestone de la release. Voir par exemple #2157 (closed) et la release %Algo 2017.03. Et le build de dev doit toujours passer.

Pour l'instant cela s'appliquerait au cpp, où l'on fait des releases, mais on pourrait aussi utiliser des milestones pour des déploiements client / serveur, à moins qu'on préfère rester en intégration continue.

@mikael-s @RyanHerb

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: vidjil/vidjil#2158