capturing conditional logic in build #5913
Unanswered
TomWoodward
asked this question in
Q&A
Replies: 1 comment 4 replies
-
The Concoursey way is for How much time are you intending to optimize away? Bear in mind that sometimes folks re-trigger builds to suss out flakes and other nondeterministic behavior even in parts that have already 'succeeded.' The general guidance is to avoid premature optimization and make the build entirely idempotent; it'll pay off someday when it fails halfway through or when the build plan has to be modified and re-run. |
Beta Was this translation helpful? Give feedback.
4 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I have a build job where the result may or may not exist already, i'm trying to check if it does and either get/put the resource to make it available for downstream jobs. i could put my noop logic in the resource's out script, but i feel like that is less explicit and the build has multiple steps and i'd really prefer to skip a bunch of them.
currently i've made a task that checks if the result exists already and use on_success to
get
it and on_failure to build and thenput
. then to make the job actually succeed and move onto downstream jobs i have to wrap the whole thing inattempts: 2
. this works but is obviously gross, without some kind of conditional steps i'm not sure how to do it better though.i would prefer not to store arbitrary state in git or s3 to trigger separate jobs for each condition as discussed here, but even if i did i'm not sure how i could fan in the resulting resource for downstream logic, since only one of the jobs will ever pass for a given version i think i would need something like optional passed logic.
there may be a way to accomplish what i'm trying to do in a more "concoursey" way, but i'm struggling with the issue, does anyone have any feedback?
Beta Was this translation helpful? Give feedback.
All reactions