Depuis !227 (merged), unit-test est beaucoup plus long : certains font plus de 13 minutes alors qu'on était à moins de 3 minutes. (Pas vérifié pour les fonctionnels).
Mettre cela plus loin, vers les tests valgrind / prepare-release. (Ou même les mettre en manuel ?)
Edited
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Child items
0
Show closed items
GraphQL error: The resource that you are attempting to access does not exist or you don't have permission to perform this action
No child items are currently open.
Linked items
0
Link issues together to show that they're related.
Learn more.
Plus généralement, on peut essayer de classer les stages du plus rapide au plus long (c'est à peu près le cas), pour être prévenu le plus rapidement possible quand il y a un soucis.
Je ne pense pas que ce soit souhaitable. Si on a toujours la couverture, au moins elle est affichée. On la connaît et on se rend compte si ça baisse ou si ça monte. En manuel on ne le lancera que rarement et on ne saura pas pourquoi ça a baissé (ou monté).
Si tu veux te peux le remettre en automatique... mais cela veut aussi dire qu'il faut qu'on fasse plus souvent "merge when pipeline succeeds" et ne pas se sentir bloqué par le temps de build.
On peut sinon déjà le re-mettre en automatique au moins sur release, comme pour valgrind (et c'est pareil, on serait content d'avoir un valgrind à chaque fois, c'est juste que c'est un compromis pour que cela aille vite).