Yannick DAYER (f51463f1) at 03 Nov 15:51
meta(CI): specify the master branch as the default
Yannick DAYER (876c8690) at 02 Nov 12:37
meta(CI): switch back to the sub-pipeline variant.
Yannick DAYER (4b8eeb8f) at 31 Oct 16:39
Yannick DAYER (ff148324) at 30 Oct 15:56
Revert "meta(CI): switch to develop branch of each package"
Yannick DAYER (4b8eeb8f) at 30 Oct 13:15
meta(CI): add the 'file' field in the triggers.
Yannick DAYER (7aadf38e) at 30 Oct 13:11
meta(CI): add missing include statement in config.
Yannick DAYER (4cc69f3f) at 30 Oct 13:08
meta(CI): fix syntax to specify branch downstream.
Yannick DAYER (866dfd28) at 30 Oct 13:03
meta(CI): fix syntax to specify branch downstream.
Yannick DAYER (8fa48f4b) at 30 Oct 11:45
meta(CI): remove bob.extension; change the order.
... and 2 more commits
Yannick DAYER (a63ed24a) at 23 Jun 14:22
order: bob.fusion.base now depends on bob.pad.base
Samuel GAIST (03c362d4) at 11 May 09:47
When the bob.bio.face pipeline fails (e.g. on May the 4th), the nightlies pipeline does not care that it failed (it even marks it as succeeded), and continues executing.
I'm expecting the nightlies' pipeline to stop (or at least show that one job failed).
This is not critical as we receive a notification anyway, at the level of the package (here bob.bio.face).
Yannick DAYER (760c83be) at 11 May 09:47
Merge branch '64_fix_unexpected_successful_pipline' into 'master'
... and 1 more commit
The default strategy for downward pipeline does not trigger failure of the whole pipeline. Using the depend strategy does.
Fixes #64
Thank you for the fix!
Yes, it makes sense to me.
In that case, bob.bio.video
will not be built if bob.bio.face
fails but that's a valid concern as we don't want to have successful builds based on "outdated" packages.
Oh, I thought the change was for all groups, sorry.
This is fine, then.
Those packages are not a leaf, no. bob.bio.video
depends on bob.bio.face
.
I might be wrong here but isn't that set of package a "leaf" of the pipeline ? If so I would expect that the failure of any of them would not stop the rest of the jobs as no others depends on them.
So this goes against #62. Would there be a way to make the pipeline report the failure (fixing #64 (closed)), but continue executing following package pipelines anyway?