Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Labels:None
-
Story Points:8
-
Epic Link:
-
Sprint:AP S22-6 (May)
-
Team:Alert Production
-
Urgent?:No
Description
Currently, ApPipe.yaml is considered the "base" AP pipeline; it is included by ApVerify.yaml, which is in turn included by ApVerifyWithFakes.yaml. However, this design causes problems for ApVerifyWithFakes, which has a significantly different structure (in particular, a distinction between steps done with and without fakes) and its own rules for which metrics instrument which tasks.
The problem can be mitigated by splitting ApPipe.yaml into two pipelines: one which is a dependency of ApVerify.yaml, and a new ApPipeWithFakes.yaml that is a dependency of ApVerifyWithFakes.yaml. ApPipe.yaml and ApPipeWithFakes.yaml will not depend on each other, allowing each to have the labels, contracts, and other elements that are appropriate for that pipeline.
Configurations that should be shared between the two pipelines should be factored out into their own configs, consistent with RFC-775 guidelines.
Attachments
Issue Links
Activity
See also DM-32988, which formalizes the question of multi-tract processing and will do some pipeline cleanup of its own.
Krzysztof Findeisen
added a comment - - edited See also DM-32988 , which formalizes the question of multi-tract processing and will do some pipeline cleanup of its own. Ian Sullivan asked that this issue be merged at least one day after DM-34254, as both have changes that could affect completeness metrics.
Krzysztof Findeisen
added a comment - Ian Sullivan asked that this issue be merged at least one day after DM-34254 , as both have changes that could affect completeness metrics. Thanks for agreeing to look at this, Meredith Rawls! The biggest changes ended up being in ap_pipe; I recommend looking at those and ap_verify by individual commits.
Krzysztof Findeisen
added a comment - Thanks for agreeing to look at this, Meredith Rawls ! The biggest changes ended up being in ap_pipe ; I recommend looking at those and ap_verify by individual commits. Thank you for fixing this up to be much more self-consistent, and to implement a less onerous DM-30210 workaround. Most of the GitHub comments are minor, and provided you can please convince me the camera-specific ApPipeWithFakes pipelines are importing all the right things from all the right places, I am very happy to have you merge this.
Krzysztof Findeisen
added a comment - Ok, everything's merged. This should unblock DM-34710 and DM-34623 . 
DM-32245added a ApPipeMultiTractFakes.yaml; use this as the basis instead of ApVerifyWithFakes.yaml (there's still some work to do on this ticket, as the current file depends on ApPipe, and ApPipe is not yet multi-tract).